Yet Another HeartBleed.
This Heartbleed Information Disclosure Vulnerability has pretty much been covered all over the internet today (8th April 2014). As a one-page-stop summary, please read below:
An online site exists to check vulnerabilities: http://filippo.io/Heartbleed/
Source Code available at: https://github.com/FiloSottile/Heartbleed
A python script (thats much better): http://s3.jspenguin.org/ssltest.py
A second version of above code with STARTTLS Support: https://gist.github.com/takeshixx/10107280
A good breakout of why the bug exists is here: http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
Watching twitter has been entertaining, login.yahoo.com has been leaking user credentials, aswell as several forums, a security competitor was vulnerable leaking their SSL certificates private key, many darknets have been hosting competitions for the most collected credentials / private keys.
What is affected?
Anything using a vulnerable version of openssl:
- Web services (HTTPS)
- Mail Services (STARTTLS)
- SSL based VPNs
- OpenSSL based Authentication Mechanisms
From the OpenSSL advisory http://www.openssl.org/news/secadv_20140407.txt the following versions are vulnerable:
- 1.0.1 through to 1.0.1f
- 1.0.2-beta & 1.0.2-beta1.
All other versions are unaffected.
How about operating systems?
Some operating system distributions that have shipped with potentially vulnerable OpenSSL version:
- Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
- Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
- CentOS 6.5, OpenSSL 1.0.1e-15
- Fedora 18, OpenSSL 1.0.1e-4
- OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
- FreeBSD 10.0 – OpenSSL 1.0.1e 11 Feb 2013
- NetBSD 5.0.2 (OpenSSL 1.0.1e)
- OpenSUSE 12.2 (OpenSSL 1.0.1c)
Operating system distribution with versions that are not vulnerable:
- Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14
- SUSE Linux Enterprise Server
- FreeBSD 8.4 – OpenSSL 0.9.8y 5 Feb 2013
- FreeBSD 9.2 – OpenSSL 0.9.8y 5 Feb 2013
- FreeBSD Ports – OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)
Workarounds, incase you can’t Upgrade OpenSSL
Even though the actual code fix may appear trivial, OpenSSL team is the expert in fixing it properly so latest fixed version 1.0.1g or newer should be used. If this is not possible software developers can recompile OpenSSL with the handshake removed from the code by compile time option
CVE-2014-0160 is the official reference to this bug. CVE (Common Vulnerabilities and Exposures) is the Standard for Information Security Vulnerability Names maintained by the MITRE.
I’m on a Network without Direct Internet Access. How can I Test for This Bug?
We understand that strict controls on some of our clients networks, mean no internet access and new scripts/tools can not be introduced until an authorised maintenance window. You can actually still test for this vulnerability using openssl:
openssl s_client -connect <ip>:<port>
then at the prompt type:
If you receive an error – your service is not vulnerable, anything else your service is potentially vulnerable!
Example Vulnerable Service:
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : AES256-GCM-SHA384 Session-ID: 1907E866C9EA711CBCC79990A42A3397F42C18187E134C1D45F127D2892D038B Session-ID-ctx: Master-Key: 1879E87ED22A69961A769C09CC7BBD920CD274D26D4856AD21A162DA5B9754415204E737F3AD6D1C658E486D6F1FDB17 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - db cb 01 bb d5 55 70 90-0a 23 3e 5c 21 e1 f1 f6 .....Up..#>!... 0010 - 7f 84 fe b3 1a f3 6f f7-82 ea b3 be ff b2 8d 14 ......o......... 0020 - dc 9c e6 d4 fc ed 8a 0d-f9 64 59 1d 2e e3 5b 25 .........dY...[% 0030 - a0 cb 45 c7 bd fd 74 8e-a3 1d 4e 9f 03 2f 30 b9 ..E...t...N../0. 0040 - 1e fa 84 36 bd ba 36 21-5c cc 18 00 18 bb 0a 1a ...6..6!....... 0050 - b2 01 87 d1 bc cd 11 cb-2e 64 62 36 50 51 89 57 .........db6PQ.W 0060 - e6 d3 19 a8 5e 01 2e 3d-6d ec bc 13 ce fb ee 52 ....^..=m......R 0070 - bc b4 5c 16 92 93 8a a5-bd d7 01 9d 5e a9 84 1e ...........^... 0080 - 37 d2 15 93 bf 9d 22 93-06 fb e6 b9 16 18 61 f8 7.....".......a. 0090 - 3b b8 df 77 f9 2e 8c 81-e4 10 e2 3c 07 40 c7 81 ;..w.......<.@.. 00a0 - 13 e2 91 1f 69 a6 7e 64-93 28 30 78 55 34 6b 5e ....i.~d.(0xU4k^ 00b0 - f6 99 78 ba 7c 9f 13 51-d8 2b b3 1f bc e5 7e b1 ..x.|..Q.+....~. Start Time: 1396986311 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- B HEARTBEATING read R BLOCK
How Much Data is Leaked?
There is a total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed. Eventually, credentials or even private-keys, x509 certificates can be leaked.
Are my Private Keys Safe?
I’m frequently receiving the Question “Hey, so and so from company XXX claim it is not possible to get critical information like keys, why are you saying its possible?“
Well we looked into this, and it mainly comes down to the Heap management of the OS, and the amount of RAM that you have allocated to the server. In our testing, by continuously hammering the SSL affected service we did eventually obtain critical information like passwords and private keys. We admit this is a lot easier on a server with a smaller amount of memory, will many active connections. On the other hand, with the same server, but only a very small amount of connections it is very hard to obtain the same key material; in this case the more popular your service is the more vulnerable you are! When it came to testing BSD variants, the private keys were only accessible after a server reboot.
Lastly and Most Importantly…
Don’t rush to change all your passwords! You might be revealing the clear-text of your new credentials. Wait for the affected service to update their SSL certificate (you’ll usually get an email from them) and once your sure the patch/fix has been applied, only then change your password.
…for Affected Services
After the applying the workaround or upgrading Openssl don’t forget to change your certificate as the private key might have already been compromised. Additionally, inform your users/customer about the vulnerability, we also suggest that you warn all users/customers that their credentials might have been compromised and that they should change their passwords.
Gather Server API calls, and possibly source code…