Essential Skills: Man In The Middle Attacks
April 8, 2015
Editor's Note: HP 3000 managers do many jobs, work that often extends outside the MPE realm. In Essential Skills, we cover the non-3000 skillset for such multi-talented MPE experts.
By Steve Hardwick, CISSP
Lenovo recently made news in the security industry, and it was not good news. The PC manufacturer was shipping a copy of the Superfish malware with its machines. The software executes a threat known as “man in the middle.” Once it was discovered, companies were advised to remove it, yes. But what is a man in the middle attack, and why is it so dangerous?
Superfish compromises the HTTPS security protocol. It will intercept HTTPS requests made by a browser. It then uses a program to connect to the target website. At the same time it sends its own public key to the browser, and has it trust it. Instead of data coming back from the website to the browser, it now comes to the Superfish program.
Normally, encryption is viewed as using a password or phrase to generate a key. The key is then used to encrypt a set of data in clear text. The resulting cyphertext is then sent to the recipient, who must have the original key to decode it. This is commonly referred to as symmetric encryption: used just for a session, the same key both encrypts and decrypts the data.
The Superfish malware extracts a symmetric key from the website and passes it on. The browser thinks it has a secure connection to the website, when in fact Superfish is now listening to all of the communication from the PC to and from the website. Superfish was originally used to intercept Web traffic and surreptitiously record where the PC's user went on the Web. In addition, it opens up very nasty holes for hackers to use.
Second, since the Superfish application is the one validating the digital certificates, false certificates can be installed. This allows a hacker to install a false certificate for a banking site. The user would connect to their back, and instead the hacker would use Superfish to connect to their site. The user would feel safe that the HTTPS connection had been made and all of the data was secure. However, the hacker is now collecting all this private information.
This was a bad security hole. Users were initially unaware of the application that was loaded by this PC manufacturer. There are now many sources of instructions on how to remove this piece of malware. How could this have been avoided in the first place? First of all, it is worth checking the installed program list of any new machine. Work through the list of programs and then use a browser to look up ones that do not look like standard applications. Superfish came up as VisualDiscovery for example.
Sometimes programs like this get loaded when other programs are loaded or upgraded. Browser search bars can get in that way. The only certain way to remove Superfish is to completely wipe the hard drive, and then reload the operating system from scratch, only putting in the programs you want. In many corporations, machines are rebuilt like this using an image of a hard drive that was previously configured safely.
But what is a man in the middle attack, and why is it so dangerous? It helps to know how computers encrypt data.
How encryption works
We begin with understanding how computers identify their partners. One of the major challenges of symmetric encryption is how to deliver the symmetric key safely to the recipient.
To overcome this challenge, Whitfield Diffie and Martin Hellman devised a method of exchanging keys called asymmetric encryption. In this approach, one key is used to encrypt the data and a different key is used to decrypt the data. The two keys are created as a pair. The encryption key, since it is not disclosed, is called the Private Key. The second, which can be distributed, is called the Public Key. Additionally, the public key can be used to encrypt data and the private key used to decrypt it. Using the public key to encrypt a symmetric key allows it to be decrypted only by the user that has the corresponding private key.
The next challenge that arises is verifying public keys. For example, Jane sends Bob an email message saying “Attached is my public key.” Bob then sends Jane an email saying “Here is my public key.” So Bob and Jane can now use these asymmetric keys to securely send a symmetric key. The symmetric key can then be used to encrypt and decrypt the file data. However a couple of days later Bob gets another email message from Jane saying ”New public key attached.” What should Bob do? Ironically at the same time Jane has receive an email from Bob saying ”New public key attached.” Let's say they both believe it is real. However, neither sent the keys.
A bad guy, intent on reading their encrypted data, sent these keys out. Jane uses the new Public key from Bob to encrypt the symmetric key and sends it out. The bad guy sees it and uses the fake private key he created for Bob to decrypt the symmetric key from Jane and store it. Then he uses the fake private key for Jane to encrypt the symmetric key and send it to Bob. Bob uses the fake public key from Jane and decodes the symmetric key. Now Jane and Bob think they are the only ones with the symmetric key and start sending encrypted messages. However, the bad guy also has the symmetric key and can also decode the data too.
What was needed was some way of validating that the public key came from the person that claimed it. The concept of a digital certificate resolves this challenge. A company called a Certificate Authority sets up a way to validate user identity. They send out their public key to everyone who trusts them. The users then send their public key to the CA. The CA verifies their identity and encrypts their public key with the CA private key. The resulting file is now sent out in lieu of a public key. When the recipient receives it they decrypt it with the CA public key and get the validated user's public key. The user public key that was encrypted with the CA private key is called a digital certificate. This is used in HTTPS web connections.
A website owner will generate their Public/Private key pair. They will send it, together with the required documentation, to a digital certificate provider. (There are many out there; just search the Internet.) The digital certificate provider, after authentication, sends back the digital certificate. The web site owner can now set up an HTTPS web site. The digital certificate is sent to the web site user. If the public key of the CA is loaded into their browser, then the website Public key is extracted automatically. The website can now use their private key to send symmetric keys to encrypt the data. A secure channel can now be established. Plus, the website user can also use the digital certificate to validate the website address.