OpenSSL ‘heartbleed’ bug live blog


heartbleedA 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:

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.

Advice

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.

Impact

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.

Updates

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.

Examples

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.

heartbleed example

 

 

 

114 thoughts on “OpenSSL ‘heartbleed’ bug live blog

  1. Please don’t use grey letters on white (or – in the snort-rules – even light grey!) backgrounds for sites with important information.

      1. 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.

      2. He’s talking about the color scheme of the website – you might disagree with him, but that seems pretty obvious.

  2. The Script gives me the following error on connection refused:
    Traceback (most recent call last):
    File “./script.py”, line 132, in
    main()
    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

  3. any idea why the script just stops working and exits after the 8th or 9th hosts?

    f = open(args[0])
    for host in f:
    host = host.strip()
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sys.stdout.flush()
    s.settimeout(5)
    try:
    s.connect((host, opts.port))
    except socket.error, e:
    print host + ‘|’ + str(e)
    continue

  4. 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.

    1. 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.

    2. 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.

  5. 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?

  6. The ssltest.py script is not accessible for me (the error code below):

    AccessDeniedAccess DeniedAE8C30D9277A61F9so784tBi6TND0n4gX+ys7TxdvPcZU7G4OuTW0ej2lZW8MUR1v34kXm2oiMsM7HAN

  7. 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)?

  8. 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?

  9. 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?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s