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?
"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
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).
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.
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.
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.