Why Heartbleed is dangerous? Exploiting CVE-2014-0160

2014-04-08 00:00:00 +0100

8 April 2014 is a busy day for sysadmins. Everyone is patching CVE-2014-0160 and I can actually see this in realtime — servers that were vulnerable in the morning, no longer expose their data in the afternoon. This is not really frequent that a vulnerability is treated so seriously, but in this case it’s fully justified. I will not repeat the description of the attack itself, as it’s very well covered at HeartBleed.com, with sanity check for websites at filippo.io (command line version) and technical description by Sean Cassidy.

If you want to repeat this exercise you’re probably too late to find any high-profile servers leaking data. But if you wonder what could leak this way, here’s results of my testing of a few vulnerable websites (I’ve used ssltest.py mentioned above). A typical memory dump from HeartBleed is a lot of random-looking data with pieces of ASCII text (more on this further down).

Let’s start with the ASCII pieces, as they are so obvious — first, we have a session cookie of some user, which is already pretty scary as in most cases it would allow you to enter his logged-in session on the website:

Cookie: JSESSIONID=3B5EEBFBB79F18BD4799ABD4E909C1DD; incap_ses_151_72853=wc8oUfRJslCCJzqGjH0YAoDhQ1MAAaAAVtq1PO6Xox9TW/yElHXTZQ==; visid_incap_72853=v6u3KeY+QpMsSXtAowIOqoDhQ1MAAAAAQUIPAAAAAADXYEYOUmidLy5QPlxBQAyU; nlbi_72853=LzmaBAfmXwXnGOpfajjRQQAAAACBiey0VqrEtsqTC9yszb5M; ___utmvc=navigator%3Dobject,navigator.vendor%3DApple%20Computer%2C%20Inc.,opera%3DReferenceError%3A%20Can't%20find%20variable%3A%20opera,ActiveXObject%3DReferenceError%3A%20Can't%20find%20variable%3A%20ActiveXObject,navigator.appName%3DNetscape,plugin%3DTypeError%3A%20Result%20of%20expression%20'a%5Bi%5D%5B%22filename%22%5D'%20%5Bundefined%5D%20is%20not%20an%20object.,webkitURL%3DReferenceError%3A%20Can't%20find%20variable%3A%20webkitURL,navigator.plugins.length%3D%3D0%3Dtrue,digest=44339

Further on in the dump we can see JSON block that looks like a AJAX update sent to or from some live-trading system:


In another dump you can quite precisely see what was the previous website the user visited along with his session identifier there. Initially I had no idea why these cookies was present in memory of that website, because it was completely unrelated to cryptocurrencies (a bank, basically), but read on…

Referer: https://www.wemineltc.com/userStatsAuth Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Cookie: (snip) wemineltc=REMOVED; wemineltc-forums=REMOVED; (snip) __utmz=140470837.1394494465.5.2.utmcsr=litecoin.info|utmccn=(referral)|utmcmd=referral|utmcct=/Mining_pool_comparison

Another cryptocurrency exchange (or wallet) updates:

{"success":"1","return":{"balances_available":{"42":"0.00000000","ALF":"0.00000000","AMC":"0.00000000","ADT":"0.00000025","ANC":"22.16853523","ARG":"0.00000000","ASC":"0.00000000","AUR":"0.44243491","BAT":"0.00000000","BCX":"0.00000000","BQC":"0.00000000","BEN":"0.00000000","BET":"0.00000000","BTB":"0.00000000","BTC":"0.71951108", REMOVED ,"balances_hold":{"LTC":"0.42366167"},"balances_hold_btc": "LTC":"0.00000000"},"servertimestamp":1316962140,"servertimezone":"EST","serverdatetime":"2014-04-08 08:29:00","openordercount":3}}

In general, you can find pretty scary things in these dumps — session cookies, user agents, third party cookies, tracking cookies, AJAX data and much more. But here’s something even better…

Load balancers leak via Heartbleed

When I wondered why cryptocurrencty data was present in memory dumps of a bank, I came up with one hypothesis which I tested… and it was successful:

$ host BANK.WEBSITE BANK.WEBSITE is an alias for l4idp.x.incapdns.net. l4idp.x.incapdns.net has address $ host www.wemineltc.com www.wemineltc.com is an alias for b8x4t.x.incapdns.net. b8x4t.x.incapdns.net has address

Both websites — cryptocurrency and the bank — share the same cloud based content distribution provider Incapsula. This setup has several important consequences. First, both were vulnerable and couldn’t do anything about it until the provider fixed their load balancers or web servers. Second, content of sessions to both websites gets mixed on the provider's servers</strong>. Third, when the provider fixed the vulnerability both websites became secure immediately.

Private keys

Codenomicon explicitly mentions that they were able to extract private keys this way, while Sean Cassidy doubts it. Searching for RSA private keys, as used in SSL configuration, is rather simple — just search for bytes 30 82 which mark start of RSA key in DER encoding.

I haven’t found any, but I did not collect much data. Lots of the dump data looks like pseudo-random and they are separated by blocks of ASCII, so I guess the leaked pieces of data come from memory actively used for encryption and decryption of incoming SSL sessions. Majority of the data seen might be ciphertext and plaintext prepared to be sent out to SSL tunnel, or received from one. The actual assymetric SSL keys are unlikely to be found there, but user passwords and session cookies absolutely will be there. Another likely finding would be the session keys generated for encryption and authentication in SSL, and this is actually something that the original Codenomicon authors mention in their article (“1) primary key material, 2) secondary key material and 3) protected content and 4) collateral.”).