Trustico code injection

[Hanno Böck]

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

[Alex Gaynor]

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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[scott...@gmail.com]

There's a similar report here: https://twitter.com/Manawyrm/status/969230542578348033

[Hector Martin 'marcan']

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

[Matthew Hardeman]

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

[Hector Martin 'marcan']

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.

[RS Tyler Schroder]

> > Hector Martin "marcan" (x...@x.st)

> > Public Key: https://mrcn.st/pub
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@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.

[Tom]

> 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 ?

[RS Tyler Schroder]

That seems rather comprehensive. Any number of vectors could have caused a key leak.

[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.

[gran...@gmail.com]

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.

[Hector Martin 'marcan']

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']

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?

[Hanno Böck]

On Fri, 2 Mar 2018 16:10:52 +0900

Hector Martin 'marcan' via dev-security-policy

<dev-secur...@lists.mozilla.org> 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?

[Lewis Resmond]

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.

[Todd Johnson]

> 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

[Rich Smith]

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]

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.

--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com

[Rich Smith]

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

[Ian Carroll]

(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.

[ch...@minkus.me.uk]

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.'

[random...@gmail.com]

> 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?