MESSAGE
| DATE | 2015-03-01 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [NYLXS - HANGOUT] Lenovo Superfish
|
On 03/01/2015 06:08 PM, Ruben Safir wrote:
> On 03/01/2015 02:26 PM, Paul Robert Marino wrote:
Superfish Adware is NOT guilty, it is the Jews fault. It was some other
application designed to intercept your data stream and replace it with
some customized version of their own which is at fault.
These people can't even think straight. Up is Down and Left is Right.
>> 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
>> too.
> https://blog.filippo.io/komodia-superfish-ssl-validation-is-broken
>
> Filippo.io
>
> 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.
>
>
> Recap
>
> 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:
> "komodia").
>
> 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
> server.
>
> 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.
>
> *However.*
>
> 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
> failure.
>
> 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.
>
>
> Consequences
>
> 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.
>
>
> Conclusions
>
> First, don't make intercepting proxies. They are impossible to write
> correctly, and by their very nature lower the security of the whole
> Internet.
>
> Second, the Komodia one is a particularly bad one, and they should feel
> bad.
>
> 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 .
>
>
>
>
|
|
