SSL & TLS Attacks for the Layman: Bad Implementation

Posted by Arvind Doraiswamy on December 6, 2016 at 2:08 PM

Issues with SSL and TLS are seemingly commonplace these days. In my previous post, I discussed many of the vulnerabilities that I've come across in the last few years conducting software security assessments for our clients. In this four part blog series, my focus is on covering some of the attacks that have exploited various features in the SSL/TLS mechanism including:

  • Part 1: Bad Implementation
  • Part 2: Oracles
  • Part 3: Repeated Plain Text
  • Part 4: MITM Downgrade Attacks

Let's start with bad implementation.

Heartbleed

Heartbleed is one of the most well-known attacks simply for the fact of how damaging the impact is. An attacker could, with no user intervention of any sort, connect to a server and extract secrets from the server's memory: passwords, private keys, PII, pretty much anything. Once that information is stolen, what can be done with the stolen information depends on if there are other mitigations in place to protect users. For example, it might be possible steal a root password for some server, but if you have no way to reach that server due to a properly implemented mitigation control like a firewall, no damage can be done. The only fix is to apply the relevant patches for OpenSSL running on your OS. Hopefully it’s all seamless and the libraries on your system will be patched during your "automatic update" process.

Berserk

This was a Mozilla NSS library specific bug. In this case, Alice can bypass signature verification for TLS certificates issued for specific websites. If the signature isn't verified properly, Alice can construct a certificate (i.e. another certificate for mail.google.com) that looks exactly like the original one without having the private TLS key for mail.google.com. Once she has the malicious certificate, she can install that on a website somewhere and it will look just like mail.google.com. Leveraging phishing techniques, she would get victims to visit that website. However, this attack isn’t as simple as it sounds.  If you tell everyone to go to mail.google.com, they'll end up going to the real site and not Alice's fake site. So, Alice then has to perform other MITM attacks like ARP poisoning, DNS cache poisoning, and BGP route hijacking and somehow tell users to go to Alice's site when they type in mail.google.com in their browsers. The fix really is to ensure you have the latest security patches in place for all the software that uses the NSS libraries.

Read the next post in this series.

Topics: developer guidance, crypto

Arvind Doraiswamy

Written by Arvind Doraiswamy

Arvind is a Senior Security Engineer who focuses on conducting security assessments for clients, contributing articles to our secure coding knowledgebase, and writing tools to improve our company's security testing efficiency for clients.