The Lenovo and SSL/TLS Nightmare

In under a year, two horrible incidents (that I can recall) involving SSL/TLS have made the news (I’ll place a link to the older one in the comments). As a cryptography nerd, that makes me happy.

SSL/TLS is a protocol that protects online communication. It ensures that your communications are encrypted end-to-end (e.g., only you and your bank’s computer can read it, and no one can modify it in transit without you knowing), and it authenticates one end of the communication (e.g., you know it’s actually your bank to whom you’re talking).

This week’s emerging story was clearly a deliberate decision by someone(s) to sabotage to the functioning of SSL/TLS on Lenovo computers. And it’s making the news.

The very high-level version: both end-to-end encryption and (more importantly) authentication are broken because of malicious software installed by default on certain Lenovo computers.

I’ll try to keep the details below high-level. If anyone wants to geek out on a more technical explanation, please feel free to ask in the comments section.

Fundamentally, SSL/TLS requires you to trust someone in order to work. That someone is called a certification authority (“CA”). For example, when I connect to the UBC Connect eLearning Site, I trust that I’m actually talking to UBC Connect, because a company called thawte has issued some electronic credentials to UBC, which the UBC Connect server presents to me when I connect to it. So, the whole system only works if I actually trust thawte not to irresponsibly (or maliciously!) issue fake UBC credentials to other people. Which CAs you trust matters.

Lenovo computers come, by default, trusting an extra CA. That CA is a malicious program running on the Lenovo itself. When that malicious software detects you attempting to make an outbound SSL/TLS connection (say, to UBC Connect), the malicious software quickly issues itself credentials signed by that additional CA (i.e., the software issues itself credentials) claiming to be UBC Connect, and intercepts your connection attempt. You trust the CA, so you think you’re talking to UBC Connect. In fact, you’re talking to the malicious software on your own computer.

The malicious software then starts a second, independent connection between itself and the real UBC Connect.

You think you’re talking to UBC Connect, and UBC Connect (once you log in) thinks it’s talking to you. But both you and UBC Connect are wrong: you’re both talking to the malicious software.

Why? So that the malicious software can modify the data flowing from UBC Connect to you, to insert ads into it (i.e., end-to-end encryption is broken, because the communication is modified in-transit).

Here’s the real kicker, though. Because of how the software can instantly issue new credentials to itself, combined with some flaws in the malicious software itself, other people’s computers can issue credentials that the malicious software will trust.

So, when the malicious software tries to connect to UBC Connect, it might actually be connecting to Dr. Evil’s computer, and never realize it’s not connecting to UBC Connect (i.e., authentication is broken). So, the connection now looks like:

You <-> Malicious software inserting ads <-> Dr. Evil <-> UBC Connect

Now you have two problems, both of which affect your ability to communicate safely (Dr. Evil) and effectively (ad-inserting malware) online.

Here is the CERT disclosure, for anyone who wants more technical details.

Cheers!