The power of trust: “Superfish” case turns into a worst case scenario


The case of the “Superfish” adware has caused quite a sensation through its association with computer technology company Lenovo. However, the following report shows that “Superfish” is just the tip of the iceberg. It explains the implications of and possibilities for misuse. By way of an example, experts at G DATA SecurityLabs have investigated a piece of update software involved in the case, to illustrate the risks of certificate misuse.

So why is everyone talking about “Superfish”?

“Superfish” is currently synonymous with a security problem that is actually much more widespread. The story spread like wild fire: the “Superfish Visual Discovery” software was supplied pre-installed on many Lenovo notebooks and, ever since, everyone has been talking about this "super fish" that is unfortunately anything but digestible. The “Superfish” software has (now) been classified as adware or even riskware by many AV manufacturers. G DATA security solutions recognise the software as Gen:Variant.Adware.Superfish.1 (Engine A) and Win32.Riskware.Fishbone.A (Engine B).

Even though adware has been an unwelcome guest on the PCs of most users for a long time, in the majority of cases it is not necessarily malicious, as we have already explained in our blog post on the subject of PUPs. However, “Superfish”, which is now the subject of such hot debate, is a bit of an exception, as it contains a technology component called “SSL Digestor” distributed by Komodia. This component contains an element that triggers the actual security problem - a poorly secured yet very powerful master certificate.

As a result, in this discussion, a name needed to be given to the master certificate itself, without just considering the software that it uses. This is especially pertinent considering that the “SSL Digestor” technology and its questionable certificate has now been detected in several other software products as well, as US CERT and IT researcher Marc Rogers report. By the time it was discovered that other products are affected, it was clear that Lenovo customers were the most prominent - but not the only - victims of this problem; the situation is of even greater magnitude.

The fatal thing here is that, even if the user uninstalls the software containing the integrated “SSL Digestor”, in the case of the software products known of to date, the powerful certificate that comes with it remains on the computer, thus leaving the door wide open for abuse of digital trust on the Internet.

The following report by experts at G DATA SecurityLabs focuses on precisely this certificate that is left behind, and the implications and possible risks that are posed by leaving behind this "fishy" residue. The obvious working title for this risk is therefore Fishbone, the stinking remains of a fish you definitely should not swallow!

Security through digital trust on the Internet

Trust between two parties on the Internet is generally regulated by certification authorities. These are used in numerous areas. The two most important are a secure connection between two communication partners and digital signing when delivering software.

Secure communication between two parties

One of the bedrocks of secure communication on the Internet is the encryption of communication on the transport route. This means ensuring that the connection between the two parties can neither be listened in to nor changed without anyone noticing. This technology is used with online banking or web stores, for example.

Technically, TLS (Transport Layer Security) is based on the exchanging of certificates that guarantee the identity of the communication participants. Every certificate consists of two parts: a private part, known only to the owner, and a public part. By means of specific algorithms, the public parts can be exchanged at the start of a communication, thus guaranteeing that each party is in possession of the private key.

Root certificates and their role

Root certificates were created because not every communication partner can know every other directly on the Internet, and so is not able to estimate how trustworthy his or her counterpart is. They form a central element in the chain of trust. A set of root certificates from Root Certificate Authorities (CAs) that are generally considered to be trustworthy is already included in operating systems and browsers.

Warrantors and signatures

It is possible to form chains of certificates that can be used to delegate trust. In the example shown, USERTrust represents the Root Certificate Authority. It has digitally signed that it trusts COMODO Certification Authority. Consequently, COMODO Certification Authority is now classified as trustworthy as well. The chain goes even further at this point. COMODO Certification Authority has in turn vouched for COMODO Extended Validation Secure Server CA via digital signature. This chain can be extended almost at will. This should illustrate the function of Root Certificate Authorities. The basis for the entire chain is the trust in the root certificates.

The digital signature

Besides encrypting Internet communication, certificates have at least one other, equally widespread application purpose. They are used to verify software components in real time. As with secure communication, there is an issuer, who has a certificate that affords him trust by a root Certification Authority. This can be used to sign software digitally, to guarantee it in real time. This function is also used to achieve a position of trust for programs within the concept of protection in the Windows operating system. Valid, digitally signed programs enjoy greater trust than unsigned programs.

How does “Superfish” work?

As already explained, “Superfish” is adware. In order to be able to display its advertising banner inside a web page being visited, “Superfish” must inject content into the current web page. To do this, the software needs to manipulate the Internet traffic coming into the computer from web servers. A local proxy server is installed for this purpose. There are a number of ways of doing this. “Superfish” handles it by installing a proxy server on the computers concerned, via the Windows Filtering Platform (WFP).

The heart of the matter is this: communication with many web servers is secured via TLS nowadays. This means that the Internet traffic between the user's browser and the web page is encrypted. In the browser, the secure connection to the web server is evident, for example, from the fact that the address line starts with "https://" instead of "http://". Such a secure connection should be used for example for shopping on the Internet, online banking and any other activity that involves sensitive data.

But a simple proxy server is not enough for “Superfish”, as advertising banners also need to be incorporated into web pages that are accessed via a TLS-secured connection. And to do this the encryption must first be broken.

How does “Superfish” break the encryption?

To be able to display “Superfish” content to the user among his search results, “Superfish” needs to be able to anticipate the identity of every web page. To do so it needs to switch between the browser that is requesting and receiving the web page and the web server that is sending the web page. This concept is called man-in-the-middle (MitM). To enable this to happen, “Superfish” installs its own root certificate - an element at the highest position in the chain of trust.

When visiting web pages, new certificates are being dynamically generated all the time by the proxy used by “Superfish”. It fakes the certificate of the actual communication partner - in this case the web server - and signs it using the “Superfish” master certificate. At this point the user cannot directly determine that “Superfish” has read and manipulated the data stream, which is in fact securely encrypted.

To achieve all this, the private key for the “Superfish” master certificate needs to be stored on the computer - otherwise it would not be possible for the software to digitally authenticate the newly generated certificates.

"Touching an HTTPS connection should only be done when there is a very good reason for doing so. Showing ads is never a good reason", says Martijn Grooten. Furthermore, with “Superfish”, several serious mistakes have been made, as a result of which security holes have opened up.

Fishbone is not the only problem with “Superfish”

As already explained, not only the “Superfish Visual Discovery” riskware provides an over-powerful certificate - other programs contain Komodia “SSL Digestor” as well. According to @TheWack0lian, there is also a VPN software among them.

In fact, the individual programs each supply their own root certificate secured with its own private key; however, the password for every private key (!) is identical and publicly known. This means, de facto, that all of these private keys are unprotected. @TheWack0lian has listed some of these.

Furthermore, it has been discovered that the Komodia proxy installed on a PC responds very unfavourably when it comes into contact with a primed, invalid certificate, according to Filippo Valsorda. When the certificate is issued by the proxy, it is possible to unwittingly permit any invalid certificate to be supplied by the proxy as a valid certificate. When this happens, it seems to the user that everything is in order - but in fact the chain of trust is not even there.

Another thing worth mentioning is that one “Superfish” set-up investigated by us contains functionality for circumventing a potentially necessary user confirmation during the installation of the required certificate. The corresponding message window that should be displayed to the user is confirmed automatically. Furthermore, the sound is disabled for a short time at that moment, meaning that the audible signal that normally accompanies the message window cannot be heard. The developers must be assumed to have done this deliberately, as information is being actively held back from the user. However, during the investigation, the activation of this built-in functionality could not be reproduced.

Besides the already well-known, principal approach that is mainly focused on the manipulation of secure communication, the experts at G DATA SecurityLabs considered another direction: misuse of the digital signing of software. The effects of this have not yet been adequately described, but they still represent a risk factor that is not to be overlooked.

Why the Fishbone stinks

Let us recap: even if the user uninstalls software that has “SSL Digestor” integrated into it (such as “Superfish Visual Discovery”), the powerful root certificate supplied with it - the Fishbone - remains on the computer.

The first problem is:

the private key is no longer private. The pair of keys required for the root certificate is not generated dynamically for each computer, but is identical on every computer affected. This means therefore that anyone who knows the private key can read and manipulate any communication secured using TLS that is sent to any computer with “Superfish” installed on it. And this private key has already been published, by Robert Graham among others. It means that an attacker can break the encryption if he has access to the data stream.

The second problem is:

there is no restriction on the purpose of use. Certificates, including root certificates, can be restricted to specific purposes. However, the “Superfish” Inc. certificate is completely unrestricted. This means that not only can an attacker read and manipulate encrypted connections to and from websites, as described above - he can also sign programs, for example.

The Fishbone as an attack vector

The fact is that the entire data stream between a browser and any server can be monitored and manipulated via MitM attacks using the Fishbone. This gives rise to various potential attack scenarios:

Scenario 1: Phishing of access data and more

Phishing of login data etc. The options that this enables have already been described in detail by research colleagues and the media. Put briefly, the attacker is firstly capable of reading secure connections to valid servers (e.g. user names, passwords, TANs etc.). However, he can also redirect the data stream to non-valid servers (e.g. hijack a connection and actually access and still make this connection look valid.

Scenario 2: Hard to detect - regular downloads repackaged

As the Fishbone can also be used to sign programs, there is one extremely perfidious attack vector: if the user downloads an executable file, for example a set-up file via a download portal, this file can be replaced by an attacker using man-in-the-middle technology. This is possible even with an encrypted connection.

An exchanged file can be signed using a valid digital signature. For example:

Eine ausgetauschte Datei kann mit einer gültigen digitalen Unterschrift signiert werden. Ein Beispiel:

  1. A user wants to download a provider's digitally signed installation file (File A) from the latter's website.
  2. The MitM proxy downloads File A from the provider's server and reads the provider's valid digital signature.
  3. A new certificate that imitates the provider's valid certificate is dynamically generated by means of the Fishbone. The new file is then signed using the Fishbone.
  4. The attacker enhances File A according to the multi-layer principle, to incorporate the malicious functionality he wants - another layer - and adds a banking Trojan, for example. The multi-layer principle causes the banking Trojan to be installed when the newly generated file is first executed; only then is the original File A launched.
  5. The file generated in the previous step is then digitally signed using the certificate generated in step 3.
  6. Finally, the newly generated and signed file is delivered to the user by the MitM proxy.

Generally, no user would be suspicious at this point and the file would be run for installation as planned. In fact, Microsoft Windows notifies the author of a set-up file (owner of the certificate) prior to any installation. However, this can be manipulated by the attacker so that - at first glance at least - it looks just like the set-up file that should originally be installed. Hence the download has acted as a Trojan Horse for the malware.

Scenario 3: The worst case scenario - updates also have a fishy smell

The attack described in Scenario 2 can often be extended to include update channels as well. These are frequently secured using TLS. As an example of this, experts at G DATA SecurityLabs have taken a look at the “ThinkVantage System Update” from Lenovo. This update software is among those contained in the E series devices that are affected by the “Superfish” problemdevices that are affected by the “Superfish” problem. This software is used to update the system software.

During the update process, an index file with a list of update operations is first downloaded via a connection secured using TLS. One update operation observed in this process is the downloading and launching of an executable file (uts.exe):

Using man-in-the-middle technology, uts.exe could be replaced during the transfer, so that the replaced file would be run after the download. Besides replacing the executable file itself, the checksum within the index file must also be replaced or adjusted, of course.

The checksum is called "CRC" in the XML document shown above, although it is in fact an SHA1 checksum.

Die ausgetauschte uts.exe wurde automatisch ausgeführt. Owned!

It is entirely conceivable that also software contained on other devices has automated updates that can become Trojan Horses when used in conjunction with “Superfish” or a comparable “man-in-the-middle certificate”.

What to do in the event of a Fish(bone) contamination

The critical element of all of the attacks illustrated is the Fishbone, the powerful root certificate installed by the Komodia software. If this is completely removed from the system, the essential part of the attacks mentioned above disappears and the acute problem is resolved.

Removal instructions

It is not complicated to manually remove the “Superfish, Inc.” certificate. However, it has to be removed from every certificate store on the computer - both in Microsoft Windows and the browser's own certificate stores. The following instructions are available: