Exploiting the Superfish certificate | Hacker News Reader

Exploiting the Superfish certificate

blog.erratasec.com

129 pointsvippy17 comments

That's a nice little MITM box. Note that he didn't have to do any coding at all. He just loaded off the shelf open source software onto a Raspberry Pi. That's how easy this is to exploit. You could also take an existing router that runs Linux and put it on that, so it would look just like an commercial router.

This Raspberry Pi version isn't doing all it could to conceal its attack. The screenshots of the the Bank of America connection show a connection to a site with an Extended Validation certificate, but the MITM software hasn't bothered to create a fake EV cert for Bank of America. So the browser UI hasn't turned the address bar green.

If the fake cert generator were a little better, it could hide this from even experienced users. The fake certs signed by the Superfish cert display as "Verified by Superfish". But if the attacker created a certificate chain with a fake intermediate certificate authority, they could have the "Verified by" be anything they want. (Look at the certificate for "news.ycombinator.com". Firefox says "Verified by COMODO CA Limited". That name is not from the root certificate installed on the machine; it's from the previous certificate on the chain. The root cert is 3 steps down, and is from "UTN Datacorp SGC", which is UserTrust.) An attacker could copy all the information from the correct certificate for the site, so everything would look completely normal in the user interface. The software on the Raspberry Pi isn't doing this, but it certainly could.

This is such an easy attack, and applicable to so many laptops, that there's probably a real attacker out there who's been using it for a while. If you have a Lenovo machine, change your passwords on everything and check all your accounts for fraud.

This is cool and all but if the victim has Superfish installed there's no need to use the private to MitM the connection. The Superfish software is not properly passing the validation state of the public cert when it connects to a website like Bank of America as an example.

The software is simply not triggering appropriate warnings in the browser when provided an obviously fake certificate that has been generated in a way to bypass browser warnings. It's also not properly validating revoked certs. Both of these situations are very bad. Allowing any self-signed cert would lead me to believe that this could have easily been exploited in the wild without prior knowledge of this vulnerability.

I've notified the software vendor of the impacted software and they are working diligently to patch all of their software. As such, I not going to provide a how-to guide on how to exploit users here. I also notified both Superfish and Lenovo of this issue on Thursday (US), neither of which have responded.

Anyway, the following is an example of the improper status pass through based on doing something that might be quite obvious to those who understand how the browser validates a public against the fully qualified domain name.

This is what the browser should do when it encounters a self-signed cert delivered by an SSL/TLS MitM solution:

http://defaultstore.com/six.png

However, it's not doing this for this self-signed public cert:

http://defaultstore.com/four.png

Note both certs show "verify_fail." at the beginning and those who know how browser cryptography works will understand what has likely gone wrong with their implementation.

The ramifications of this are fairly significant. An attacker running sslsplit as example, configured like many instances are that we actually see in the wild can MitM Superfish software connected HTTPS sessions without the Superfish private. This means that a bad guy didn't actually need to know about this software and reverse it to compromise connections.

The thing is, if you put any arbitrary DNS name in the subject, Superfish will tag it as verify_fail. as you show, but it also passes through Subject Alternative Name untouched; if you just put the host you want to spoof in the SAN instead of the subject, Superfish will pass it through and the certificate will appear valid to the browser.

So, no need to chain to the "real" Superfish root cert, you just need to craft the SAN properly and chain to anything, or self-sign.

I thought this vulnerability was due to them installing a root CA so if you have that CA key you can always generate self-signed certificates for all websites on the fly? A software update wouldn't change that, unless it removed the root CA certificate, but this defeats how superfish works. That was my understanding, I'd be interested to learn how I'm wrong!

There are multiple issues, the fact that it's not properly passing validation state being the worst, IMHO.

Filippo Valsorda from CloudFlare has done a write up on it:

https://blog.filippo.io/komodia-superfish-ssl-validation-is-...

I found the flaw early on the 19th and attempted to contact Lenovo and Superfish to disclose. My mail bounced to their security e-mail boxes and I never heard back from anyone at the e-mail addresses that were sucessfull so I then reached out to Komodia directly and have been in communication with them since. They understand the flaw and are working to patch all of their software.

I've really been torn on this one. With the private in the wild it's not necessarily irresponsible disclosure at this point to go public, but I wanted to at least give the software vendor a chance, whether the community views them as deserving of that or not before publishing all the details of my own findings.

Ah that link explains it, thanks. Very interesting. What a mess!

The SuperFish certificate is still necessary to MitM a (probably relatively small) population of targets - those that have run the uninstaller for the SuperFish software, but not separately removed the certificate from the Windows cert store. Turns out the uninstaller doesn't perform this step (whoops!).

Very nice (Tldr - practical demonstration of an invisible MitM attack on anyone with silverfish installed)

And important too - the knowledge of how to do this should not be "secret" - and the simplicity is worrying.

> (These Kingston chips are the ones I'm using, but they are kinda crappy. They sometimes connect as 'read-only'; I don't know why).

They're not crappy, Kingston cards are fine. You've accidentally moved the "lock" slider and put the card into read-only mode.

It would be interesting if there is a way to detect Silverfish (e.g. by recognizing some specific HTTP requests being made). Because that would allow the MitM to only run a MitM on devices that you know are vulnerable and thus decrease the changes of discovery immensely.

If you combine that with configuring your proxy not to MitM any of the sites that browsers have certificate-pinning for (e.g. Google sites with Chrome) you can probably have this running for a very long time without anybody noticing.

Google Chrome defers to the local PC for installed certificates. So, cert pinning didn't protect users at all in this instance.

It's a 'feature' of Chrome so that it will use an installed corporate SSL and allow intentional MitM of all HTTPS traffic for purposes of institutional eavesdropping.

There are some very important uses of such institutional eavesdropping, such as running an intrusion detection system on a corporate network; I'd argue that this is a worthy tradeoff between employee privacy and good information security.

You've undermined both if your proxy is powered by Komodia or another product with similar flaws. What if you've hardened your workstations, but your proxy client supports inferior ciphers? All that work is undone. What if your proxy is easily fingerprinted? That's valuable information to an attacker. There are so many details to get right, and it can take years to discover the flaws that can be exploited by an attacker poking in the right places.

It's not necessarily for institutional purposes.

I use it to view my own https traffic in Fiddler.

Financial services should employ a second JS-based PKI layer. BofA has no excuse.

"... log into the BofA website using the AccountID of "barry123457". While this transaction went over SSL, you can see clearly that sslsplit was able to intercept it. AS you can see, in the middle of the post information is the string "barry123457".

You realize that anything the real BofA site adds to increase security can be removed by the proxy? Once your CA trust-store is compromised there really is no way to do anything secure without asking the user to use another channel to verify things.

> You realize that anything the real BofA site adds to increase security can be removed by the proxy?

This is true for targeted attacks only. A second JS layer doing crypto can at least prevent firesheep-class untargeted mass snooping of auth data.

Reply on news.ycombinator.com