Hotmail MITM attack preventable with ~100 lines of code.

A week ago I read a story on GreatFire about a Man-in-the-Middle (MITM) attack against Hotmail customers in China. For me this is really an assault on basic human rights and simple technology can make this problem go away. For corporations with overseas employees, how do you know their SSL traffic is not suffering from the same MITM attacks right now as those who visited Hotmail? For those who are up to speed on SSL and MITM, you can go to the “Trust but Verify” section of the article.

SSL refresh:

For those who are not fully up to speed on SSL, let's review how SSL works. SSL to users provides three capabilities. The first is how long a site should be trusted. The second is the encryption of data between the user and site. Encryption takes data that you and I can read and through wonders of mathematics, transforms the data as to make it almost impossible for anyone to understand, except the user and site.

The third valuable capability of SSL from the user's perspective is validating the identity of the site. After all, you don’t really know if it is the real site, even if the site looks the same as yesterday. The issuance of an SSL certificate usually involves the business/human validation of the domain owner. Once this is done and the certificate is issued, this technically ties the owner of the site to the certificate and the CA.

The way your computer can tell if the site should or not be trusted is because of trusted Certificate Authorities (CA) certificates that were pre-installed from your operating system vendor or by your company. These exist in something on your computer called a root store. On Macs it is called "System Roots". These Certificate Authorities are “Trust Anchors” and are the basis of user to site security on the public Internet.

When you visit a site, your system sends a "client hello" to the site. The site then responds with a "server hello" and the certificate. The code on the user's computer that validates the site's certificate utilizes an attribute of the certificate called the “issuer” to look up the root CA. There are more checks that are done, but this is the critical one. If the CA’s certificate is in the local root store then once again because of the wonder of mathematics that CA certificate can be utilized to validate the certificate of the site the user is visiting.

Now the Certificate Authorities certificate is not what makes the math fully work. It also requires something called the private key, which is not on your system but was utilized to create the CA certificate. The importance of this is similar to the combination to the vault at Social Security Administration. So the private key by most trusted Certificate Authorities are locked away in a safe place, otherwise the whole chain of trust is violated if the private key is disclosed.

MITM Attack:

For a successful Man-in-the-Middle attack for SSL communications there needs to be a couple of requirements met. The attacker must be in the communications path to proxy the connection and have the means to pass the appropriate messages from and to the server and client. In countries like China with full censorship this criteria can be met easily.

Another is having a "trusted" CA certificate on the user's computer. So how does a hacker get the cert onto the user's system and is able to be in the communication path? Well, if they don't have physical access to the user's computer, then malware is a common method. However, the attacker sometimes is closer to home than you think. By setting up a hotspot that appears legitimate, the attacker could utilize a number of methods to try to install the Trusted Certificate. One double whammy is getting your credit card stolen by paying for internet and requires a user to install software. Some legitimate hotspot providers require an agent be installed. In the case of an attacker, the software could install a Trusted Root CA in the process of the install. The hotspot could also leak malware targeting vulnerabilities on the user's system or injecting malware into the user's communications channel for non-encrypted sites. You typically will find these types of hotspots at hotels or your favorite coffee hang out the attackers enjoy too. The attacker could even be the good looking barista smiling at you from behind the counter. Tourist areas especially frequented by foreign visitors might be a prime location to setup these hotspots.

After the attacker puts the CA certificate on your system, the attacker must have code that creates certificates on the fly that are signed by the "trusted" CA to impersonate the site you want to visit. The entity who has the private key of a Trusted CA on the user's system can create any certificate for all the websites in the world. Because the CA certificate is trusted on your system you will not know if your bank's website is forged or not. During the attack the data is no longer encrypted and sensitive information can be disclosed.

If this compromise is discovered by the OS vendor or your IT staff, then a security update should remove or block the Certificate Authorities certificate. There are many systems that have certificates installed of CAs that have been compromised. Because many systems are not up to date with security patches those CAs are not updated and remain trusted. The possessor of the private key can potentially target specific classes of users. In the case where you are visiting a foreign country and the government of that country requires certificates authorities based in those countries to hand over the key, anyone with the CA can be target for MITM attacks.

A potential example of this is the Hotmail MITM attack that was reported by GreatFire to be carried out by the Chinese Government.

Trust But Verify:

So let's assume that a bad CA is on your system and a MITM attack is going on; how can you prevent this? Well, there is cert pinning which is only valid if you are sure the identity of the host is valid. With technologies such as GSLB and cloud where resources are always moving this could be problematic over time. There is the ability to embed a certificate in an application but this is not practical for all browsers. You can have a list of trusted CA’s that the browser supports. However, with malware this can be dealt a blow.

This is where a simple out-of-band check can be leveraged by corporations for their remote workers or those traveling abroad. Many mobile applications have specific validation build into the application that can help against MITM attacks. However, for laptops on the go, sometimes that level of security is not available. As a result of this and other MITM attacks that occur, I decided to put together a simple POC that could help detect when SSL communication channel is being eavesdropped on. The POC code can be located at: https://github.com/actus10/mitm_detection.

The detection server can be located in your corporate data-center or in multiple locations on the Internet. When a client wants to test to see if the path is being intercepted, they can run the client and enter the site information that they want to go to. The client retrieves the site's certificate over the path. Then over another connection sends the certificate it received from the site to the detection server for validation. The server then retrieves the certificate from the site and evaluates it against the one received from the user. The detection server will send back a message notifying if the channel is clear from an MITM or there is a potential for eavesdropping.

For those who try the demo keep in mind the code is limited in functionality. It is assumed the detection server is not on same path as the client in relation to the site. If the detection server is in California and the user is in China, there is an extremely low chance the detection server is in the same path as the client. Below two results with the POC code. The first is over a path that is compromised and eavesdropping is occurring. The second is from a path is free of eavesdropping.

In this first image you can see the results on a Microsoft OS utilizing a channel that has a MITM attack being performed.

The second image shows a communications path that is free of eavesdropping.

In the sample code this process is done over clear text and is not intended for production use. This could also be adapted start_TLS for other protocols. The client could be embedded with the certificate of the web service for internal validation in case all sites and ports are vulnerable to MITM.

Disclaimer: This article does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.