Implementing the Heartbleed Attack

April 9, 2014 by Ixia Blog Team

Without a doubt, Apache and Nginx are the most widely-used web servers, implemented on an estimated 66% of public-facing websites.1 In enterprise-grade web sites, TLS is one of the most commonly-used schemes of protecting against attackers by achieving confidentiality, integrity, and authenticity between endpoints. The TLS protocol employs public key infrastructure with symmetric and asymmetric cryptography and secure functions to assure secure communication over insecure networks. OpenSSL is the most-used cryptographic library in Apache and Nginx websites.

In December 2011, an extension called Heartbeat was introduced in the TLS/DTLS protocol that serves as a keep-alive function without performing renegotiation. On April 7, 2014, a critical bug in the OpenSSL implementation of the Heartbeat extension was published in CVE-2014-0160.2 The structure of a typical Heartbeat request – response is the following:

Offset Length Content
0x00 1 Heartbeat Type
0x01 2 Payload Length (x)
0x03 x Payload
0x03+x var Padding











The vulnerability stems from a memory management flaw when handling Heartbeat requests. If the payload is smaller than the payload length, the payload in the response will be filled up to 64Kb of random system memory. The implications are devastating for confidentiality, an attacker could effectively glean directly from memory all the necessary information to decrypt all the communications to the vulnerable service and impersonate it at will.3

According to the CVE, all versions of OpenSSL between 1.0.1 and 1.0.1f are affected by this attack, meaning that an estimated half a million trusted websites (17.5%) are vulnerable.4 Several scripts have been made available to assess a web service’s status,5 and it is advised that users upgrade to version 1.0.1g of the OpenSSL library or use an alternative encryption method to secure their sites.

It is rare that security flaws with such a high degree of exploitability get released, and the Ixia Application Threat Intelligence (ATI) team always takes special care to support our customers in times like these. It is possible that multiple deployments cannot be upgraded due to software compatibility constraints, and the only possible countermeasure remains intercepting traffic via IPS. As such, we have already isolated the key elements that make the attack possible and a strike will be available in the next ATI release. Our implementation is meant to serve as a benchmark for your perimeter security to evaluate your security posture against the real-world threat and assure that your critical services are protected against attacks.

Leverage Subscription Service to Stay Ahead of Attacks

The Ixia BreakingPoint Application and Threat Intelligence (ATI) program provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.

Additional Resources:

View Ixia’s Full ATI Protocol List