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?
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).
Here are a few risks that you expose yourself to with this specific software:
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.
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.
