Re: Trustico code injection

[randomsyseng--- via dev-security-policy]

> Trustico have assured us that the private key
> could not have been compromised.  

Did they elaborate on how they came to that "could not have been" conclusion?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[chris--- via dev-security-policy]

That's not what Trustico are saying in their fulfilment emails (received during 
the purchase of a Trustico® certificate through Comodo CA this morning):

'If you chose to have us generate your CSR during the ordering process, you 
will need to contact us for a copy of your corresponding Private Key. Your 
Private Key is not included within this e-mail for security reasons.

If you decided to provide your own CSR, we don't have access to your Private 
Key. It will already reside on your device or server.'

'If you chose to have us generate your CSR during the ordering process, your 
Private Key will only be saved within our systems for the next 14 days.'

On Friday, 2 March 2018 17:29:36 UTC, Rob Stradling  wrote:
> We also asked Trustico to cease offering any tools to generate and/or 
> retain customer private keys.  They have complied with this request and 
> have confirmed that they do not intend to offer any such tools again in 
> the future.
> 
> Trustico have also confirmed to us that they were not, and are not, in 
> possession of the private keys that correspond to any of the 
> certificates that they have requested for their customers through Comodo CA.
> 
> On 02/03/18 15:25, Rich Smith via dev-security-policy wrote:
> > Comodo CA has investigated the reports posted to this list relating to the
> > suspected compromise of the private key corresponding to
> > https://crt.sh/?id=206535041.  Trustico have assured us that the private key
> > could not have been compromised.  However, since it will be hard to convince
> > everyone that this is the case, Trustico have agreed to obtain a replacement
> > certificate with a new keypair.  Once that new certificate has been
> > installed, Comodo CA will revoke https://crt.sh/?id=206535041.
> > 
> > Regards,
> > Rich Smith
> > Sr. Compliance Manager
> > Comodo CA
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> ComodoCA.com

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Ian Carroll via dev-security-policy]

(re-sending to list)

> We also asked Trustico to cease offering any tools to generate and/or
retain customer private keys.

Does Comodo intend to standardize a policy against this? GoGetSSL has a
tool like this in their customer panel and I’m sure there are more.

On Fri, Mar 2, 2018 at 12:29 PM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> We also asked Trustico to cease offering any tools to generate and/or
> retain customer private keys.  They have complied with this request and
> have confirmed that they do not intend to offer any such tools again in
> the future.
>
> Trustico have also confirmed to us that they were not, and are not, in
> possession of the private keys that correspond to any of the
> certificates that they have requested for their customers through Comodo
> CA.
>
> On 02/03/18 15:25, Rich Smith via dev-security-policy wrote:
> > Comodo CA has investigated the reports posted to this list relating to
> the
> > suspected compromise of the private key corresponding to
> > https://crt.sh/?id=206535041.  Trustico have assured us that the
> private key
> > could not have been compromised.  However, since it will be hard to
> convince
> > everyone that this is the case, Trustico have agreed to obtain a
> replacement
> > certificate with a new keypair.  Once that new certificate has been
> > installed, Comodo CA will revoke https://crt.sh/?id=206535041.
> >
> > Regards,
> > Rich Smith
> > Sr. Compliance Manager
> > Comodo CA
> --
> Rob Stradling
> Senior Research & Development Scientist
> ComodoCA.com
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Trustico code injection

[Rich Smith via dev-security-policy]

https://crt.sh/?id=206535041 is now revoked.
Regards,
Rich Smith


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Rob Stradling via dev-security-policy]

We also asked Trustico to cease offering any tools to generate and/or 
retain customer private keys.  They have complied with this request and 
have confirmed that they do not intend to offer any such tools again in 
the future.


Trustico have also confirmed to us that they were not, and are not, in 
possession of the private keys that correspond to any of the 
certificates that they have requested for their customers through Comodo CA.


On 02/03/18 15:25, Rich Smith via dev-security-policy wrote:

Comodo CA has investigated the reports posted to this list relating to the
suspected compromise of the private key corresponding to
https://crt.sh/?id=206535041.  Trustico have assured us that the private key
could not have been compromised.  However, since it will be hard to convince
everyone that this is the case, Trustico have agreed to obtain a replacement
certificate with a new keypair.  Once that new certificate has been
installed, Comodo CA will revoke https://crt.sh/?id=206535041.

Regards,
Rich Smith
Sr. Compliance Manager
Comodo CA

--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Trustico code injection

[Rich Smith via dev-security-policy]

Comodo CA has investigated the reports posted to this list relating to the
suspected compromise of the private key corresponding to
https://crt.sh/?id=206535041.  Trustico have assured us that the private key
could not have been compromised.  However, since it will be hard to convince
everyone that this is the case, Trustico have agreed to obtain a replacement
certificate with a new keypair.  Once that new certificate has been
installed, Comodo CA will revoke https://crt.sh/?id=206535041.

Regards,
Rich Smith
Sr. Compliance Manager
Comodo CA


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Todd Johnson via dev-security-policy]

> The code injection occurred on an interface they had to check the
> certificate of an arbitrary server. When 127.0.0.1 was used, the
> trustico.com certificate was returned. That means the local web server
> was handling TLS, not a remote load balancer solution (unless somehow
> 127.0.0.1 was forwarding to a remote host, which doesn't really make any
> sense).
>
> --
> Hector Martin "marcan" (mar...@marcan.st)
> Public Key: https://mrcn.st/pub


Did *anyone* capture this information in a way that can be proven?

While I personally would not trust any content from either hostname, the
Twitter post referenced earlier is not sufficient proof of key compromise.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Lewis Resmond via dev-security-policy]

Not in my opinion. If my house is burning, I expect someone to call the fire 
department even if I am not aware/convinced that the house is burning.
The fact that they disabled their website is evidence that the Twitter posts 
were no fake.

Am Donnerstag, 1. März 2018 20:53:16 UTC+1 schrieb Tim Shirley:
> That's jumping the gun a bit.  First of all they'd have to be made aware of 
> the suspected compromise before the 24 hour clock would start.  And then 
> they'd need to be convinced that it actually was compromised.  Since the 
> server has apparently been taken down, they wouldn't be able to verify these 
> claims themselves and I would certainly hope a CA wouldn't take such an 
> action based only on unverified claims on Twitter.
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Comodo and Trustico (was Re: Trustico code injection)

[Hanno Böck via dev-security-policy]

On Fri, 2 Mar 2018 16:10:52 +0900
Hector Martin 'marcan' via dev-security-policy
 wrote:

> And what does Comodo think of all of this?

I'd like to second this.

When I wrote the original mail in this thread I considered adding
questions to Comodo, but I thought it's so obvious and Comodo people
will see this anyway that it's not necessary.

But yesterday, hours after the whole Trustico thing was unfolding,
Comodo's Twitter account sent out tweets indicating that they're proud
to be the new partner of Trustico:
https://twitter.com/Comodo_SSL/status/969302576649908226

So hereby I'd like to ask Comodo:
* Do you have any security vetting of your certificate reseller
  partners? Do you expect them to follow good security practice?
* Do you believe - given the events of recent days - that Trustico
  follows good security practice?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Hector Martin 'marcan' via dev-security-policy]

On 2018-03-02 15:24, Todd Johnson wrote:
> Did *anyone* capture this information in a way that can be proven?  
> 
> While I personally would not trust any content from either hostname, the
> Twitter post referenced earlier is not sufficient proof of key compromise.

Unfortunately, the server quickly went down after the vulnerability was
publicly posted (as you might expect when throwing a root shell to
Twitter), and now that it is back up the vulnerable endpoints return
404. I'm not sure if anyone managed to capture further proof of the
extent of the breach. That Twitter thread is pretty damning, though,
even if it may not qualify as proof of key compromise.

I think the more interesting question here will be Trustico's response,
if any. Will they report the potential key compromise to Comodo and
request a revocation and reissuance? Or will they just pretend the
Twitterverse didn't have root on the server almost certainly holding
their private key for a while? Will they be transparent about their
storage of customer private keys, and exactly how it was implemented and
whether this compromise could've further compromised those keys?

And what does Comodo think of all of this?

-- 
Hector Martin "marcan" (mar...@marcan.st)
Public Key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Hector Martin 'marcan' via dev-security-policy]

On 2018-03-02 13:32, grandamp--- via dev-security-policy wrote:
> The web site is back up, with the same certificate being used.  That said, it 
> *is* possible that the certificate was managed by their load balancing 
> solution, and the private key for (trustico.com) was not exposed.
> 
> trustico.co.uk appears to be the same web site, yet it has a *different* 
> certificate.

The code injection occurred on an interface they had to check the
certificate of an arbitrary server. When 127.0.0.1 was used, the
trustico.com certificate was returned. That means the local web server
was handling TLS, not a remote load balancer solution (unless somehow
127.0.0.1 was forwarding to a remote host, which doesn't really make any
sense).

-- 
Hector Martin "marcan" (mar...@marcan.st)
Public Key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[grandamp--- via dev-security-policy]

The web site is back up, with the same certificate being used.  That said, it 
*is* possible that the certificate was managed by their load balancing 
solution, and the private key for (trustico.com) was not exposed.

trustico.co.uk appears to be the same web site, yet it has a *different* 
certificate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Tim Shirley via dev-security-policy]

That's jumping the gun a bit.  First of all they'd have to be made aware of the 
suspected compromise before the 24 hour clock would start.  And then they'd 
need to be convinced that it actually was compromised.  Since the server has 
apparently been taken down, they wouldn't be able to verify these claims 
themselves and I would certainly hope a CA wouldn't take such an action based 
only on unverified claims on Twitter.

On 3/1/18, 1:13 PM, "dev-security-policy on behalf of Hector Martin 'marcan' 
via dev-security-policy" 
 wrote:

At this point I would expect Comodo should revoke this certificate due
to key compromise within the next 24 hours.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[RS Tyler Schroder via dev-security-policy]

On Thursday, March 1, 2018 at 2:43:05 PM UTC-5, Tom wrote:
> > Therefore, it is not unreasonable to assume that this key has been
>  > compromised.
> 
> 
> So it means that any private keys generated on that website could be 
> compromised:
> - If any third-party JS were compromised (and we know how insecure 
> js-based ads are - last time it was a crypto miner on youtube)
> - If they were stored on the compromised server
> - If a trojan were installed on the compromised server
> - If somebody MitM the server
> 
> Or am I missing something ?

That seems rather comprehensive. Any number of vectors could have caused a key 
leak.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Tom via dev-security-policy]

> Therefore, it is not unreasonable to assume that this key has been
> compromised.


So it means that any private keys generated on that website could be 
compromised:
- If any third-party JS were compromised (and we know how insecure 
js-based ads are - last time it was a crypto miner on youtube)

- If they were stored on the compromised server
- If a trojan were installed on the compromised server
- If somebody MitM the server

Or am I missing something ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[RS Tyler Schroder via dev-security-policy]

On Thursday, March 1, 2018 at 12:59:17 PM UTC-5, Matthew Hardeman wrote:
> By this point, one would imagine that reputational risks would prevent any
> CA from working with Trustico.
> 
> On Thu, Mar 1, 2018 at 11:56 AM, Hector Martin 'marcan' via
> dev-security-policy  wrote:
> 
> > On 2018-03-02 00:28, Hanno Böck via dev-security-policy wrote:
> > > Hi,
> > >
> > > On twitter there are currently some people poking Trustico's web
> > > interface and found trivial script injections:
> > > https://twitter.com/svblxyz/status/969220402768736258
> > >
> > > Which seem to run as root:
> > > https://twitter.com/cujanovic/status/969229397508153350
> > >
> > > I haven't tried to reproduce it, but it sounds legit.
> >
> > Unsurprisingly, the entire server is now down. If Trustico are lucky,
> > someone just `rm -rf /`ed the whole thing. If they aren't, they now have
> > a bunch of persistent backdoors in their network.
> >
> > Now the interesting question is whether this vector could've been used
> > to recover any/all archived private keys.
> >
> > As I understand it, Trustico is in the process of terminating their
> > relationship with Digicert and switching to Comodo for issuance. I have
> > a question for Digicert, Comodo, and other CAs: do you do any vetting of
> > resellers for best practices? While clearly most of the security burden
> > rests with the CA, this example shows that resellers with poor security
> > practices (archiving subscriber public keys, e-mailing them to trigger
> > revocation, trivial command injection vulnerabilities, running a PHP
> > frontend directly as root) can have a significant impact on the security
> > of the WebPKI for a large number of certificate holders. Are there any
> > concerns that the reputability of a CA might be impacted if they
> > willingly choose to partner with resellers which have demonstrated such
> > problems?
> >
> > --
> > Hector Martin "marcan" (x...@x.st)
> > Public Key: https://mrcn.st/pub
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >

I posted about this issue in the other thread on Trustico's debacle after 
seeing the twitter explosion over here: 
https://groups.google.com/d/msg/mozilla.dev.security.policy/wxX4Yv0E3Mk/q6P8oE3pAQAJ

Agreeing with Hector, I think that would be reasonable grounds to assume 
compromise.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Hector Martin 'marcan' via dev-security-policy]

On 2018-03-02 02:56, Hector Martin 'marcan' via dev-security-policy wrote:
> On 2018-03-02 00:28, Hanno Böck via dev-security-policy wrote:
>> Hi,
>>
>> On twitter there are currently some people poking Trustico's web
>> interface and found trivial script injections:
>> https://twitter.com/svblxyz/status/969220402768736258
>>
>> Which seem to run as root:
>> https://twitter.com/cujanovic/status/969229397508153350
>>
>> I haven't tried to reproduce it, but it sounds legit.
> 
> Unsurprisingly, the entire server is now down. If Trustico are lucky,
> someone just `rm -rf /`ed the whole thing. If they aren't, they now have
> a bunch of persistent backdoors in their network.
> 
> Now the interesting question is whether this vector could've been used
> to recover any/all archived private keys.
> 
> As I understand it, Trustico is in the process of terminating their
> relationship with Digicert and switching to Comodo for issuance. I have
> a question for Digicert, Comodo, and other CAs: do you do any vetting of
> resellers for best practices? While clearly most of the security burden
> rests with the CA, this example shows that resellers with poor security
> practices (archiving subscriber public keys, e-mailing them to trigger
> revocation, trivial command injection vulnerabilities, running a PHP
> frontend directly as root) can have a significant impact on the security
> of the WebPKI for a large number of certificate holders. Are there any
> concerns that the reputability of a CA might be impacted if they
> willingly choose to partner with resellers which have demonstrated such
> problems?

According to this report, 127.0.0.1 returned the SSL certificate of the
Trustico server itself. This is evidence that no reverse proxy was in
use, and thus, the private key of trustico.com was directly exposed to
the code execution vector and could've been trivially exfiltrated:
https://twitter.com/ebuildy/status/969230182295982080

Therefore, it is not unreasonable to assume that this key has been
compromised.

The certificate in use is this one:
https://crt.sh/?id=206535041

At this point I would expect Comodo should revoke this certificate due
to key compromise within the next 24 hours.

-- 
Hector Martin "marcan" (mar...@marcan.st)
Public Key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Matthew Hardeman via dev-security-policy]

By this point, one would imagine that reputational risks would prevent any
CA from working with Trustico.

On Thu, Mar 1, 2018 at 11:56 AM, Hector Martin 'marcan' via
dev-security-policy  wrote:

> On 2018-03-02 00:28, Hanno Böck via dev-security-policy wrote:
> > Hi,
> >
> > On twitter there are currently some people poking Trustico's web
> > interface and found trivial script injections:
> > https://twitter.com/svblxyz/status/969220402768736258
> >
> > Which seem to run as root:
> > https://twitter.com/cujanovic/status/969229397508153350
> >
> > I haven't tried to reproduce it, but it sounds legit.
>
> Unsurprisingly, the entire server is now down. If Trustico are lucky,
> someone just `rm -rf /`ed the whole thing. If they aren't, they now have
> a bunch of persistent backdoors in their network.
>
> Now the interesting question is whether this vector could've been used
> to recover any/all archived private keys.
>
> As I understand it, Trustico is in the process of terminating their
> relationship with Digicert and switching to Comodo for issuance. I have
> a question for Digicert, Comodo, and other CAs: do you do any vetting of
> resellers for best practices? While clearly most of the security burden
> rests with the CA, this example shows that resellers with poor security
> practices (archiving subscriber public keys, e-mailing them to trigger
> revocation, trivial command injection vulnerabilities, running a PHP
> frontend directly as root) can have a significant impact on the security
> of the WebPKI for a large number of certificate holders. Are there any
> concerns that the reputability of a CA might be impacted if they
> willingly choose to partner with resellers which have demonstrated such
> problems?
>
> --
> Hector Martin "marcan" (mar...@marcan.st)
> Public Key: https://mrcn.st/pub
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Hector Martin 'marcan' via dev-security-policy]

On 2018-03-02 00:28, Hanno Böck via dev-security-policy wrote:
> Hi,
> 
> On twitter there are currently some people poking Trustico's web
> interface and found trivial script injections:
> https://twitter.com/svblxyz/status/969220402768736258
> 
> Which seem to run as root:
> https://twitter.com/cujanovic/status/969229397508153350
> 
> I haven't tried to reproduce it, but it sounds legit.

Unsurprisingly, the entire server is now down. If Trustico are lucky,
someone just `rm -rf /`ed the whole thing. If they aren't, they now have
a bunch of persistent backdoors in their network.

Now the interesting question is whether this vector could've been used
to recover any/all archived private keys.

As I understand it, Trustico is in the process of terminating their
relationship with Digicert and switching to Comodo for issuance. I have
a question for Digicert, Comodo, and other CAs: do you do any vetting of
resellers for best practices? While clearly most of the security burden
rests with the CA, this example shows that resellers with poor security
practices (archiving subscriber public keys, e-mailing them to trigger
revocation, trivial command injection vulnerabilities, running a PHP
frontend directly as root) can have a significant impact on the security
of the WebPKI for a large number of certificate holders. Are there any
concerns that the reputability of a CA might be impacted if they
willingly choose to partner with resellers which have demonstrated such
problems?

-- 
Hector Martin "marcan" (mar...@marcan.st)
Public Key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Trustico code injection

[Alex Gaynor via dev-security-policy]

For the Trustico folks:

While I imagine you're quite busy remediating this serious issue: Can you
state whether it would be possible to access any of the private keys you
store using this root shell?

Alex


On Thu, Mar 1, 2018 at 10:28 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi,
>
> On twitter there are currently some people poking Trustico's web
> interface and found trivial script injections:
> https://twitter.com/svblxyz/status/969220402768736258
>
> Which seem to run as root:
> https://twitter.com/cujanovic/status/969229397508153350
>
> I haven't tried to reproduce it, but it sounds legit.
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy