
Exploiting the Superfish certificate - vippy
http://blog.erratasec.com/2015/02/exploiting-superfish-certificate.html#.VOgck1PF9k5
======
Animats
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.

------
patcheudor
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](http://defaultstore.com/six.png)

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

[http://defaultstore.com/four.png](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.

~~~
dignick
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!

~~~
patcheudor
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-...](https://blog.filippo.io/komodia-superfish-ssl-validation-is-broken/)

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.

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

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

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

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

~~~
JohnTHaller
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.

~~~
mrbabbage
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.

~~~
wampus
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.

------
MHammond
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".

~~~
t0mas88
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.

~~~
mschuster91
> 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.

