58

There has been quite a bit of concern noted relating to the recent discovery that Lenovo are pre-installing a piece of Adware (Superfish) which has the capability of intercepting SSL traffic from machines on which it is installed.

What are the security risks of having OEMs or other companies installing this kind of software onto customers systems?

AviD
  • 72,138
  • 22
  • 136
  • 218
Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • 7
    There is also a checker which can be used to check to see if the Superfish CA has been installed on your system. The checker is available at https://filippo.io/Badfish – Rory McCune Feb 19 '15 at 13:26
  • 11
    A general solution is to not trust any machine that you didn't personally reinstall; that includes crapware-filled consumer PCs. –  Feb 19 '15 at 17:24
  • 5
    @AndréDaniel indeed that's a good solution for more technical users, unfortunately I guess not everyone will feel competent to install/configure their own OS/drivers/etc – Rory McCune Feb 19 '15 at 22:10
  • It's really not that hard, especially since Windows 7 you have a pretty usable OS right off the bath without extra drivers needed, as they will be installed via Windows Update. –  Feb 19 '15 at 22:21
  • Defense level companies control the whole manufacturing chains. This kind of attacks are not new. For organizations, it might make sense to select vendors based on their reputation. This kind of news about Lenovo and others should definitely influence the market at some level. It does not mean your grandmother needs a Chinese-only laptop (assuming you are Chinese). – Aki Feb 20 '15 at 05:10
  • 2
    @aki sure government level attackers might be able to get their own certs issued, but here wr're referring to companies doing it for commercial gain and placing users at risk by doing so. Not quite the same scenario – Rory McCune Feb 20 '15 at 09:57
  • @AndréDaniel for technical people I'd agree but perhaps the challenge is that ordinary users aren't that aufait enough with technology to feel comfortable re-installing operating systems – Rory McCune Feb 20 '15 at 09:58
  • 3
    Related: [How to know which Certificates to leave in my browser, and which to remove](http://superuser.com/questions/818065/how-to-know-which-certificates-to-leave-in-my-browser-and-which-to-remove) – dotancohen Feb 20 '15 at 20:27
  • Avast Antivirus, and likely many other antivirus suites too, does the same thing (presumably to protect you), and people even pay money for that and enable it conciously. – Damon Feb 21 '15 at 12:04
  • After installing [Vuze](http://en.wikipedia.org/wiki/Vuze) on a system in January, I found it carried software, "[Genius Box](http://support.moonpoint.com/network/proxy/GeniusBox/)", which installed similar proxy server software to intercept HTTP and HTTPS traffic as a [MITM](http://en.wikipedia.org/wiki/Man-in-the-middle_attack) in order to serve ads on the system. It installed a "DO_NOT_TRUST_FiddlerRoot" certificate in the root certificates list. – MoonPoint Feb 22 '15 at 21:58
  • @RоryMcCune: Sorry my English is not that great, I did not mean to suggest defense level companies would be a threat. More to compare how they defend against those threat because there is a high value to doing so. For companies, you can try to go as far as them, until the cost/benefit ratio exceeds your budget and strategy. >What are the security risks of having OEMs or other companies installing this kind of software onto customers systems? The risk has always been present in the mind of security professionals, vendors identified as non-secure will be avoided, as always. – Aki Feb 23 '15 at 02:19
  • And adding to that, defense level actors are working together with such firms of course, access to foreign technologies to empower local companies is a day-to-day activity for the spying business. I want to stress that nothing changed, Chinese companies put malware as Cisco and other companies add backdoor and channel out data to others. It is the same, it is a matter of trust and strategy, do not overreact and work on your company strategy would be the best. – Aki Feb 23 '15 at 02:26
  • @RоryMcCune, How does https://filippo.io/Badfish work? – Pacerier May 21 '15 at 21:45

4 Answers4

65

Having a proxy SSL certificate creates some privacy and security implications:

  • Superfish can impersonate any site

    This does not mean that Superfish will do it (or is doing), but they have the power. As they have a Certification Authority Certificate, any certificate they generate will be valid and accepted.

    Certificate pinning does not protect you, either:

    "There are a number of cases where HTTPS connections are intercepted by using local, ephemeral certificates. These certificates are signed by a root certificate that has to be manually installed on the client. Corporate MITM proxies may do this, several anti-virus/parental control products do this and debugging tools like Fiddler can also do this. Since we cannot break in these situations, user installed root CAs are given the authority to override pins. We don't believe that there will be any incompatibility issues."

    If you use Windows and EMET, Certificate Trust can protect you IF you configure it beforehand. But the process is manual and somewhat complicated.

  • Superfish can intercept traffic

    As a trusted CA, Superfish can perform a MiTM attack on any site, and the average user will not detect the attack. Savvy users can see that the certificate was signed by a strange CA, if they know where to look.

  • Superfish can inject code anywhere

    Even if the site is protected by SSL/TLS, Superfish can inject Javascript or HTML on every page. They just proxy the requests, make the request to the intended server, read the response, inject data, and send data to the user. And unless you are looking for it, you will never notice.

  • Superfish can be used to install malware

    Like above, Superfish can add code to Windows updates, alter executables being downloaded, infect Java applets, Flash files and so on. Any download could be silently compromised. They could even change the origin site and put changed checksums on it, so even if you calculate the hash after downloading the files, they would look legit.

  • Superfish can know every site you access

    The software monitors your browser and send data to Superfish. Even without the software, they can inject code on every site and track you everywhere.

  • Anyone on the web can use its certificate

    The private key of the certificate has been compromised, so anyone knowing the key can use Superfish certificate to create valid SSL certificates for anything they want.

Saying that they can does not mean or imply that they will, only that they have the power to do if they want (or are forced to).

mtraceur
  • 115
  • 5
ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • I believe MS use [certificate pinning](http://security.stackexchange.com/questions/29988/what-is-certificate-pinning) for their update sites, so I'm not sure the penultimate point is valid. I'm happy to be corrected though... – Boris the Spider Feb 19 '15 at 14:38
  • 4
    I edit the answer, and added that Certificate Pinning does not protect you as we both tought... – ThoriumBR Feb 19 '15 at 14:48
  • 3
    That's Chrome's pinning. Whilst the same might be true for Window's internal pinning, it also might not be. Here's hoping... – Boris the Spider Feb 19 '15 at 15:00
  • Of course, it can also do all those things without installing a root certificate, theoretically. – user253751 Feb 20 '15 at 00:00
  • All of these except for the last apply to *any* software installed on a machine. No need to forge a certificate in order to manipulate what the browser shows the user. – usr Feb 20 '15 at 09:57
  • 5
    IMO the last point is the most inexcusable one. All the above problems can be hand-waved with "We are good guys, we would never do such a thing", but the fact that they leaked their private key means that any criminal can now sign certificates in their name. – Philipp Feb 20 '15 at 10:42
  • Can an attacker on open WiFi also decrypt your SSL traffic, since they know the private key? – John Feb 20 '15 at 19:44
  • 8
    @Philipp: They didn't "leak" their private key. Sharing the private key was *fundamental to the design* of their "product". If the installed malware didn't have the private key, it couldn't sign forged certificates to intercept connections. They could have generated a separate keypair for each installation to mitigate this, but as it stands, it was security misdesign, not a leak, that exposed users. – R.. GitHub STOP HELPING ICE Feb 20 '15 at 19:47
  • @John: Only if (1) the WiFi link is between the browser and the MITM proxy, which for Superfish I guess it is not, and (2) the key exchange wasn't secure, and the adversary observed it. For example Diffie-Hellman key exchange is secure against eavesdropping. The problem is not eavesdropping, but an adversary with the improperly trusted key spoofing the real server. – Ben Voigt Feb 20 '15 at 19:47
  • @BenVoigt so then couldn't an attacker spoof the server and proxy the client's requests and perform a MITM attack, similar to SSL Strip? Except I think in this case HSTS wouldn't help... – John Feb 20 '15 at 20:11
  • @John: Yes, but for that an attacker needs the ability to redirect the connection at some level (subvert the real gateway to modify traffic, inject a new gateway via rogue DHCP or ARP poisoning, convince the browser to connect to the wrong server via DNS poisoning, etc). Eavesdropping by itself can't break the encryption. – Ben Voigt Feb 20 '15 at 20:27
  • @BenVoigt Gotcha. So the Superfish debacle enables a clandestine *active* MITM attack, but not a passive attack nor offline decryption of captured traffic. – John Feb 20 '15 at 20:58
  • @John yes that's exactly correct – Ben Voigt Feb 20 '15 at 21:02
  • 2
    @John It would be trivial to run an ["Evil Twin AP"](http://null-byte.wonderhowto.com/how-to/hack-wi-fi-creating-evil-twin-wireless-access-point-eavesdrop-data-0147919/) attack - set up an AP with same SSID and key as target, turn up the tx power, and clients will connect to your AP instead. Then use the Superfish private key to [MITM any https web site](https://mitmproxy.org/doc/ssl.html) that a Superfish computer tries to connect to. – bain Feb 21 '15 at 00:37
  • @BenVoigt WPA2 is not secure for shared keys, see [Are WPA2 connections with a shared key secure?](http://security.stackexchange.com/questions/8591/are-wpa2-connections-with-a-shared-key-secure) and [Why does WPA-PSK not use Diffie-Hellman key exchange?](http://crypto.stackexchange.com/questions/5927/why-does-wpa-psk-not-use-diffie-hellman-key-exchange) – bain Feb 21 '15 at 00:42
  • Mind tht the certificate can also serve for signing software installation. Thus an attacker can install malicious software. – johannes Feb 21 '15 at 16:57
  • 1
    if the private key has been compromised, doesn't that mean that anyone can do all of the above? (i.e. not just Superfish?) – user2813274 Feb 21 '15 at 20:09
  • @bain Diffie Helmann assumes the network in between is completely open, so breaking the WiFi encryption doesn't break it. – Ben Voigt Feb 23 '15 at 08:04
12

Here are a few risks that you expose yourself to with this specific software:

  • It uses the same private key for each installation. Since the associated is a root CA and is inserted into your private trust list, it makes it trivial for ANYONE to generate any certificate and have it trusted by the affected client (in this case, even server certificate pinning won't help you).
  • All data is inspected by the software: it is very possible (and even probable) that part of the data that should normally protected by the SSL encryption is being transmitted to the software vendor and analyzed there. even if this vendor was perfectly honest (which, given the nature of their product and the way it is being distributed, it already somewhat doubtful), it makes your data vulnerable to any breach that happens on their side.
  • As with all software, comes bugs. Using it increases the attack surface of your system.
Stephane
  • 18,557
  • 3
  • 61
  • 70
  • 1
    Server certificate pinning will help, in a browser that hasn't intentionally broken their implementation to allow proxy HTTPS intercepts to go unnoticed. And assuming that the pinning database has seen the legitimate certificate at some point, which is probably not the case for a machine configured by the manufacturer with an adware proxy. – Ben Voigt Feb 20 '15 at 19:44
  • "broken", in this matter, is a mater of perception: such functionality is extremely useful to shield internal users and the security trade off is, in many experts opinion, very much acceptable. But in the end, it doesn't matter: over 95% of all potentially affected use a browser that have this functionality. In such a case, arguing the validity of such implementation has no piratical value – Stephane Feb 23 '15 at 07:27
8

As a secondary issue, this type of software hides the true nature of how data was encrypted. Because the software replaces known certs with its own, a user does not know much about the original cert. How does the software convey that to the user? If the original cert was out of date or did not match, how would this be sent to the user? If the site is normally signed by one CA but changed to another, how would one know? Secondarily, the user interface exposes how the data was protected during transit. The user interface has no way of showing that the original connection was insecure (e.g. SSL2, null cert, etc.) as it only shows the level of encryption from the local proxy to the user.

user219861
  • 101
  • 1
2

Based on another major Superfish update: Komodia client side SSL verification is broken!

The major problem with SSL Intercepting proxies (or any in-house crypto software) developed by OEMs or a third party like Komodia is that you can't really trust them (especially after the Superfish buzz)! TLDR of this new update: An attacker does not even need to extract the root keys for an MitM attack against the victims. Since Komodia's way of handling an invalid/untrusted/self-signed certificate is flawed, it is very easy to bypass the SSL cert validation process (by setting alternate names in a certificate). Check out the post linked above for details

Lesson Learned: Implementing crypto software (including intercepting proxies) is not an easy task. Proper design analysis (from multiple crypto experts), rigorous testing and assessments must be performed on such software before being used in production. Quoiting from an awesome answer to the question Why shouldn't we roll our own?:

You can roll your own, but you probably will make a major security mistake if you are not an expert in security/cryptography or have had your scheme analyzed by multiple experts. I'm more willing to bet on an open-source publicly known encryption scheme that's out there for all to see and analyze. More eyes means less likely that the current version doesn't have major vulnerabilities than something developed in-house by non-experts.

Community
  • 1
Rahil Arora
  • 4,259
  • 2
  • 23
  • 41