A bug has been identified in OpenSSL, all details can be found at heartbleed.com. The bug has been assigned CVE-2014-0160. OpenSSL versions 1.0.1 – 1.0.1f are vulnerable. We advise to upgrade OpenSSL to version 1.0.1g or higher
Test if you are vulnerable
You can test if you are vulnerable by requesting a heartbeat response with a large response. If the server replies your SSL service is probably vulnerable. You can use any of the tests below:
- http://filippo.io/Heartbleed/ : a web based test
- http://s3.jspenguin.org/ssltest.py : a python script to test for the vulnerability from the command line. If you want to scan multiple sites you can use a modified version with easily parseable output.
- If you use Chrome you can install the Chromebleed checker that alerts you when visiting a vulnerable site.
This vulnerability only applies to OpenSSL versions 1.0.1-1.0.1f. Other SSL libraries, such as PolarSSL, are not vulnerable. OpenVPN-NL, which is depending on PolarSSL, is not affected.
We advise to perform the following steps for every vulnerable SSL service
- Upgrade the OpenSSL version to 1.0.1g
- Request revocation of the current SSL certificate
- Regenerate your private key
- Request and replace the SSL certificate
Indicator of Compromise
It is possible to detect successful exploitation of this vulnerability by inspecting the network traffic. We have developed 2 sets of Snort signatures to detect succesful exploitation of the ‘heartbleed bug’. The first set has a higher detection rate but also quite a few false positives:
alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - Possible SSLv3 Large Heartbeat Response"; flow:established; ssl_version:sslv3; content:"|18 03 00|"; depth:3; byte_test:2,>,200,3; byte_test:2,<,17000,3; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 21001126; rev:8;)
alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - Possible TLSv1 Large Heartbeat Response"; flow:established; ssl_version:tls1.0; content:"|18 03 01|"; depth:3; byte_test:2,>,200,3; byte_test:2,<,17000,3; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 21001127; rev:8;)
alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - Possible TLSv1.1 Large Heartbeat Response"; flow:established; ssl_version:tls1.1; content:"|18 03 02|"; depth:3; byte_test:2,>,200,3; byte_test:2,<,17000,3; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 21001128; rev:8;)
alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - Possible TLSv1.2 Large Heartbeat Response"; flow:established; ssl_version:tls1.2; content:"|18 03 03|"; depth:3; byte_test:2,>,200,3; byte_test:2,<,17000,3; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 21001129; rev:8;)
The second set has a lower false positive ratio but might also have a slightly lower detection rate:
alert tcp any any -> any any (msg:"FOX-SRT - Flowbit - TLS-SSL Client Hello"; flow:established; dsize:< 500; content:"|16 03|"; depth:2; byte_test:1, <=, 2, 3; byte_test:1, !=, 2, 1; content:"|01|"; offset:5; depth:1; content:"|03|"; offset:9; byte_test:1, <=, 3, 10; byte_test:1, !=, 2, 9; content:"|00 0f 00|"; flowbits:set,foxsslsession; flowbits:noalert; threshold:type limit, track by_src, count 1, seconds 60; reference:cve,2014-0160; classtype:bad-unknown; sid: 21001130; rev:10;)
alert_testing tcp any any -> any any (msg:"FOX-SRT - Suspicious - TLS-SSL Large Heartbeat Response"; flow:established; flowbits:isset,foxsslsession; content:"|18 03|"; depth: 2; byte_test:1, <=, 3, 2; byte_test:1, !=, 2, 1; byte_test:2, >, 200, 3; byte_test:2,<,16409,3; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 21001131; rev:6;)
Note: if you want to detect vulnerable SMTP servers that are being exploited via STARTTLS, make sure that you do not have “ignore_tls_data” enabled on your SMTP preprocessor.
An attacker can retrieve a block of memory of the server up to 64kb. There is no limit on the number of attacks that can be performed. The attacker has no control over the memory region where the block is read from. Sensitive information that can be obtained is:
- SSL private keys
- Basic authorization strings (username / password combinations)
- Source code
This bug affects both sides of the connection. Not only will client certificates not save you from having to update your server certificate, they can be read from the client (along with your username, password etc.) by any server you connect to. DNS poisoning, MitM etc. can be used to direct clients to a malicious server – it seems that this vulnerability can be exploited before the server has to authenticate itself.
According to http://www.openssl.org/news/openssl-1.0.1-notes.html the heartbeat extension was introduced in March 2012 with the release of version 1.0.1 of OpenSSL. This implies the vulnerability has been around for 2 years.
OpenSSL has provided an updated version (1.0.1g) of OpenSSL at https://www.openssl.org/source/.
Linux distributions are providing updates right now, so check your system for updates. Some Linux distributions have backported the fix to previous versions, ie Debian’s OpenSSL 1.0.1e-2+deb7u5 package has incorporated the fix.
When running the ssltest.py script against yahoo.com we were presented with this (censored) output. It shows clearly that the ‘heartbleed bug’ has serious consequences.
114 thoughts on “OpenSSL ‘heartbleed’ bug live blog”
Joost, hoe verhoudt deze vulnerability zich tot OpenVPN-NL?
Ha Hans. OpenVPN-NL maakt gebruik van PolarSSL als backend. PolarSSL is niet kwetsbaar voor deze aanval en dus OpenVPN-NL ook niet.
Beware admins: OpenSSL update does not restart services! You have to restart your web & mail to fix heartbleed. *service apache2 restart*
Please don’t use grey letters on white (or – in the snort-rules – even light grey!) backgrounds for sites with important information.
what the heck are you talking about?
He’s talking about the color scheme for the website. You might disagree with him, but it’s pretty obvious that’s what he’s talking about.
He’s talking about the color scheme of the website – you might disagree with him, but that seems pretty obvious.
the highlight is also a hideous green which really just defeats the purpose.
The Script gives me the following error on connection refused:
Traceback (most recent call last):
File “./script.py”, line 132, in
File “./script.py”, line 120, in main
typ, ver, pay = recvmsg(s)
File “./script.py”, line 75, in recvmsg
hdr = recvall(s, 5)
File “./script.py”, line 65, in recvall
data = s.recv(remain)
socket.error: [Errno 104] Connection reset by peer
Vulnerability can also be tested only through http://submeet.net/tools/heartbleed.php
any idea why the script would just stop after 8th or 9th host?
any idea why the script just stops working and exits after the 8th or 9th hosts?
f = open(args)
for host in f:
host = host.strip()
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
except socket.error, e:
print host + ‘|’ + str(e)
All, after some testing I found out the test tools test your Apache vulnerable when you have the SPDY module enabled even when you have disabled heartbeats or are running a correct version of OpenSSL. I contacted the developer of the original test tool to see why this happens, but until then to be safe, better disable SPDY.
Just got an update from Filippo, and he pointed me out that SPDY is statically linked in most cases (I totally
missed that). So you are indeed vulnerable if the test tool says so! But next to upgrading openssl, you also need to rebuild/update mod_spdy or disable it until it’s fixed up-stream.
To whom it may concern. the problem lies in mod_ssl_with_npn.so in the spdy package. Just checked out the code, only built the mod_ssl_with_npn.so against a fixed openssl version, replaced it and the problem is solved.
Just run the fox py-script against our pfsense with openssl 0.9.8y: It says it is VULNERABLE. Seems to be a false positive isn’t it?
The ssltest.py script is not accessible for me (the error code below):
Sorry for the unreadable output, but it was formatted in XML 🙂
This site does a better test:
Here’s another one to test at : http://rehmann.co/projects/heartbeat/
What *precisely* could be leaked when a vulnerable client (e.g. Debian stable or unstable) connected to a not vulnerable server (e.g. MirBSD or Debian oldstable)?
Reblogged this on Deep In Rails and commented:
OpenSSL ‘heartbleed’: what?, check if you are affected, impact and advice…
How about advicing users to change their passwords for affected sites after having verified that the OpenSSL library has been patched and that the certificates have been renewed?
Thanks for sharing these Snort rules.
As I understand them, you’re only testing the first 5 bytes of the TLS records, hence they should also detect encrypted heartbeat records. Correct?
To trigger the rule, a heartbeat record has to have more than 200 bytes of data and less than 16385.
Why do you need this second condition (smaller than 16385)? Isn’t 16384 the maximum size of a TLS record?
If I purchased my SSL certificate from VeriSign am I vulnerable to HeartBleed?