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:
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!
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.
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!).
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.