|SUBJECT ||Re: [NYLXS - HANGOUT] Lenovo Superfish
Ah the dangers of free as in beer applications.
Get ready every one once all of these are discovered we are going to be hearing about and possibly dealing with a mess that will make heartbleed seem like a pleasant memory.
Smiles :) :) :) every one you will need them while your carrying a sledge hammer around the office to handle those pesky desktops lol.
No but seriously this one will be bad and every one should be checking their smartphones too. I did and all my devices are clean.
Sent from my BlackBerry 10 smartphone.
From: Ruben Safir
Sent: Sunday, March 1, 2015 18:09
Reply To: hangout-at-nylxs.com
Subject: Re: [NYLXS - HANGOUT] Lenovo Superfish
On 03/01/2015 02:26 PM, Paul Robert Marino wrote:
> Hey every one bad news about this.
> Any one on my Facebook feed would have noticed this on day1 of the story.
> I did some research and SuperFish is a 3rd party company which has
> contracts with several Android and IPhone app developers.
> there have been several unconfirmed reports on non-Lenovo Android
> devices failing on the test pages, in other words they were infected
Filippo Valsorda , 20 Feb 2015
Komodia/Superfish SSL Validation is broken
/If you are on the ball already and just want the new vulnerability,
scroll to the "client side SSL verification" section./ tl;dr The
Komodia/Superfish proxy can be made to allow self-signed certificates
Some Lenovo laptops shipped
with Superfish preinstalled - an ad
injecting software. How it performs ad injection is by using a SSL
interception engine by Komodia
The software is spectacularly bad, and uses the same key on all
computers, which was extracted easily
allowing hackers to intercept the secure connections of anyone who has
Superfish installed. I made a online test, Badfish
*But Superfish is not the only one
using the Komodia engine.* All softwares that do share the same problem,
and their keys can be extracted easily
However, that's not even necessary, because Komodia is horribly broken.
How Komodia works
A brief step back to understand how Komodia does SSL/TLS interception
and what that means.
On installation the Komodia software will *install a root CA
certificate* in the system trust store.
Then when a user tries to visit a HTTPS website, the software will
intercept the connection and place itself between the browser and the
It will then connect to the server as a client, and relay data between
the two. As a certificate to the client it will present *a copy of the
server certificate, with a different public key and signed by the root
In short, a Man in the Middle attack.
What we all realized in horror is that *the root private key is the same
on all machines*, so anyone can take that and sign fake certificates to
use in MitM attacks.
(For the record, this could have been a bit less bad if the proxy client
rejected its own certificate, but whatever.)
Note that this also means that the actual HTTPS connection is handled by
the Komodia proxy client - that is, *it's the Komodia software that will
connect to the server over the Internet*. And it's not that good at it:
it will use obsolete cryptography, for example
Anyway, we thought things couldn't get worse. But.
Komodia client side SSL verification
At this point a legit doubt is: *what will the Komodia proxy client do
when it sees a invalid/untrusted/self-signed certificate?* Because
copying it, changing its public key and signing it would /turn it into a
valid one without warnings/.
Turns out that if a certificate fails validation the Komodia proxy *will
still re-sign it* (making it trusted), but *change the domain name* so
that a warning is triggered in the browser.
See in the picture below how the certificate name became
|verify_fail.events.ccc.de| to "propagate" the failure to the browser.
Hm, still bad since the user/browser will receive fake information on
why the certificate is invalid, but clever.
The Komodia proxy copies the server certificate almost entirely... What
will it do with *alternative names*?
Alternative names are a X509 extension that allows to specify in a
special field other domains for which the certificate is valid.
Boom. *The Komodia proxy will take a self-signed certificate, leave the
alternate names untouched and sign it with their root.* The browser will
think it's a completely valid certificate.
So all you need to do to bypass verification is put the target domain in
the alternate field, instead of in the main one that will be changed on
An attacker can intercept any https connection, present a self-signed
certificate to the client and browsers will show a green lock because
Komodia will sign it for them.
This means that whoever has Komodia software running on their system
will accept ANY certificate that has the domain name in the alternates.
No need to extract root keys from each software, this allows MitM
against all Komodia-using software at the same time.
It's the only way all this mess could have been even worse.*
They can change the keys, or start doing the sane thing and generate a
keypair for each device, but /this bug will still allow MitM attacks/.
And with this *attackers don't even need to know what software you are
running*, it's a catch-all against the Komodia engine itself.
So all the users out there with Komodia-powered Parental Control
software or adware have their banking connections easily intercepted.
Well, good job.
Yes, a online test is coming. Meanwhile, I serve such a cert at
UPDATE: my online test now checks for all
Komodia-powered software with the trick above.
First, don't make intercepting proxies. They are impossible to write
correctly, and by their very nature lower the security of the whole
Second, the Komodia one is a particularly bad one, and they should feel
Third, Komodia should be punished for jeopardizing the users, like
probably all the companies that didn't do due diligence here.
More rants on Twitter .