Be still our bleeding hearts

Saturday April 5th. It’s a very early hour in the morning and I have just been advised by a reputable contact that there is a potential flaw in OpenSSL. My initial reaction is a somewhat jovial reply in a good Australian manner; “p!ss off, I’m not in the mood to humour OpenXYZ taunts this early in the morning”. I let the comments pass through to the keeper like water off a duck’s back and continue tapping away at the keyboard. As you all know, I am an OpenBSD zealot (when I don’t have my Slackware hat on) and I am all too familiar and accustomed to my circle of acquaintances making the odd joke about OpenBSD’s romantic escapades with the FBI, the rumoured flaunts leading to NSA code injection, or a small pocket book of various other non-substantiated OpenXYZ jokes. The vulnerability details are sketchy at the time, and as such I simply laugh off the discussion. All was well and I was suitably bliss with my perceived ignorance.

As the morning progressed I was more than content in my environment of cutting code and exploring vulnerabilities. That was, until I started to notice even more and more detailed discussion about a potential flaw in OpenSSL. Hmmm? At this point my interest levels rose slightly…. perhaps this is a little more than a playful dig at my distro choice? I make the decision to listen a little closer to this rumour, and as discussions continue to build up momentum, that uneasy feeling is starting to cloud a lot of my colleagues vision. Many keystrokes have taken place and in less than 24 hours later the wheels are more than starting to grind, they are in an uncontrolled motion and threatening to fall off. The rumours have turned from foolish banter into a sense of panic, and discussions had now become a little more heated and panicked. This potential flaw has very quickly escalated from a “distro war dig” to an all out “this could rapidly change things” nervous tug of war. No longer was the bar talk simply chinese whispers… the situation had escalated to a “what the ##@%# is going on!” domino effect involving a small army of dry reaching security folk.

Fast forward another 24 hours to 7th April 2014. CVE-2014-0160, also known as the Heartbleed bug, has officially been released. Sysadmins, opsec folk, and a scurry of other IT monkeys are about to participate in the week from hell. The general public are oblivious to the real impact to the internet as they know it, let alone to back end infrastructure. Fast forward a week later and we start to see uneducated news sites and vendors begin to spread inaccurate information about a new ‘virus’ attacking the internet, as well as public figures throwing around foolish statements like “everyone must change all their passwords now!”. This situation doesn’t happen too often, but when it does it is on for young and old and companies are about to spend billions of dollars worldwide to mitigate risks and upgrade infrastructure!

Now, I am more interested in showing you the ‘fun’ stuff you can do with the vulnerability so I am not going to spend much time on “What is heartbleed and what do I need to do?” questions, as it is very well documented and spammed all over the interwebs. Navigate over to www.heartbleed.com if you want some good understandable information on the issue. Here is the spiel I have been giving in my vulnerability assessment reports or when people ask me what it is all about.

What is heartbleed?

On 07th April 2014 a vulnerability in OpenSSL was publicly announced as CVE-2014-0160, also known as the “Heartbleed” bug. This vulnerability can allow a remote attacker to expose sensitive data, user authentication credentials, SSL secret keys, POST data and cookies, through incorrect memory handling in the TLS heartbeat extension. The attacker can leak up to 64kB of memory contents from a client or server using OpenSSL version 1.0.1 through 1.0.1f.
Exploit code is publicly available for this vulnerability and it is important to note that this can affect a client, as well as a server.
Affected systems should be upgraded to OpenSSL 1.0.1g (preferred mitigation) or recompile OpenSSL with –DOPENSSL_NO_HEARTBEATS to address the vulnerability.

And what do I need to do to fix it?

Should a host be deemed vulnerable all SSL certificates generated by the host should be revoked and reissued after the upgrade or patch, and any associated passwords or other credentials should be reset or changed after the upgrade or patch.

Now that the niceties are over, let’s get our hands dirty with a very simple example of what can be achieved by exploiting the vulnerability.

First step. Acquire the target (testing already approved by the owner of said target) using the ssl-heartbleed.nse NMap script written by Jared Stafford.

# nmap –script ssl-heartbleed -sS -sV hostname.hidden.forobvious.reasons.com -vv

Notice that I did not use -p 443 in the nmap scan? A lot of people are currently misguided and unaware that it is not only port 443 (SSL) that is vulnerable to this heartbleed bug. Any port listening to SSL/TLS traffic and responding to heartbeat requests is vulnerable, and a number of assessments I have performed on various systems show other port traffic to be a little more interesting from a offsec point of view.

Another check you could run is by obviously utilising the openssl_heartbleed scanner module for metasploit.

Next. Let’s take a look at the data the machine currently has stored in memory by using ssltest.py, also written by Jared Stafford.

# ./ssltest.py -p whicheverportwasvuln hostname.hidden.forobvious.reasons.com

Now obviously this output is from my live honeypot, and is meant to be humorous.

But on a serious note, this is the type of information you can actually get back from a target host. Other research that I have been performing shows routers and video bridges giving up authorisation credentials and webpages giving session cookies ready for replay attacks. You know those ‘free wifi’ hotspots that redirect you to a login portal to sign in with a credit card? Yes, they have also been dumping memory with this information intact, and in plain text. No rainbox tables or hashing necessary. Below is an excerpt from one of the above mentioned hosts. For obvious reasons I have not shown all the data.

So where to from here? A lot of vendors have or are in the process of patching their appliances and other systems running the vulnerable OpenSSL. I don’t believe it will be very long before the majority of interesting publicly assessable infrastructure is patched or closed from an SSL point of view. The stragglers that haven’t realised they are vulnerable probably don’t have any really interesting data for researches to look into, and I believe the real value for money for researches is going to be targeting internal infrastructure. The heartbleed bug will realistically just arm penetration testers, researchers, or malicious folk with further arsenal for their box of goodies and CTF tools. When all the panic dies off, which it is starting to happen right now, people will become more blasé in regards to their internal infrastructure and the lazy system owners will change the focus of their efforts onto the next zero day exploit. And what’s wrong with that? We all know too well that internal networks are secure and impenetrable, so why bother being too worried about internal infrastructure. ;)