|FROM ||Ruben Safir
|SUBJECT ||Re: [NYLXS - HANGOUT] Lenovo Superfish
|From owner-hangout-outgoing-at-mrbrklyn.com Sun Mar 1 21:46:14 2015
Received: by mrbrklyn.com (Postfix)
id C458C161308; Sun, 1 Mar 2015 21:46:13 -0500 (EST)
Received: by mrbrklyn.com (Postfix, from userid 28)
id B225316130A; Sun, 1 Mar 2015 21:46:13 -0500 (EST)
Received: from mailbackend.panix.com (mailbackend.panix.com [18.104.22.168])
by mrbrklyn.com (Postfix) with ESMTP id 2D7DF161308
for ; Sun, 1 Mar 2015 21:46:12 -0500 (EST)
Received: from [10.0.0.19] (unknown [22.214.171.124])
by mailbackend.panix.com (Postfix) with ESMTPSA id A5E3211AB6
for ; Sun, 1 Mar 2015 21:46:12 -0500 (EST)
Date: Sun, 01 Mar 2015 21:46:12 -0500
From: Ruben Safir
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
Subject: Re: [NYLXS - HANGOUT] Lenovo Superfish
References: <20150226172241.GB23384-at-panix.com> <54EF6851.1050101-at-panix.com> <54EF6DD2.3000902-at-panix.com> <54F39C09.9040206-at-panix.com> <20150301232325.5894290.12371.3725-at-gmail.com>
Content-Type: text/plain; charset=utf-8
List-Id: NYLXS General Discussion Forum
BTW - this should be the leading article for the April 1 Edition of the
On 03/01/2015 06:23 PM, prmarino1-at-gmail.com wrote:
> 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 wit?h 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.
> Original Message
> From: Ruben Safir
> Sent: Sunday, March 1, 2015 18:09
> To: hangout-at-nylxs.com
> 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
> without warnings.
> 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
> (same password:
> 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
> it installed*.
> 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 catastrophic.
> 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
> san.filippo.io .
> 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 .