Category Archives: Computer Security

How does the Heartbleed Bug Affect You?

Heartbleed Logo
Most of you have probably heard by now about the Heartbleed Bug that has breached the heart of network security across the internet. The vulnerability, discovered by a team of security engineers from Codenomicon Defensics, affects encryption technology that protects online accounts for emails, instant messaging, and a wide range of electronic commerce such as internet banking.

The flaw is in the open source implementation of SLL, the encryption standard used by a majority of sites on the internet to provide a secure way of transmitting sensitive data via email or instant messaging. Essentially, the encryption standard works by allowing two parties to authenticate and establish a session key that is used to cryptographically protect the remainder of the session. It does so by using a reliable stream service provided by TCP (that is, the network transport layer), which it partitions into records with headers and cryptographic content.

Quick History

SSL (Secure Sockets Layer) version 2 was originally deployed in Netscape Navigator by Netscape in 1995 (version 1 was never deployed). Microsoft improved version 2 of SSL (or SSLv2 for short) by fixing some security problems, and introduced a similar protocol known as Private Communications Technology (PCT). Netscape then substantially overhauled the protocol as SSLv3 in 1996.

The Internet Engineering Task Force (IETF), realizing it was bad for the industry to have three similar, but incompatible, protocols, introduced a fourth similar but incompatible protocol called Transport Layer Security (TLS). The differences between this protocol and SSLv3 were not dramatic, but significant enough to preclude interoperability between the two.

TLS tweaked the encryption algorithms for key expansion and authentication which, consequently, made it incompatible with SSLv3. TLS also mandated the unencumbered Diffie-Hellman key exchange (DH) or Digital Signature Algorithm (DSA) developed by the National Institute of Standards and Technology (NIST) as part of their Digital Signature Standard (or DSS as it was commonly known), rather than the RSA encryption algorithm (used by SSL) which was developed by Ron Rivest, Adi Shamir and Leonard Adleman at MIT.

Nevertheless, for historical reasons, and in order to avoid an extravagant or wasteful consumption of resources, TLSv1.0 was made backward compatible with SSLv3 and SSLv2, since all frequently shared the same connection ports. For example, the https protocol (that is, the HTTP protocol secured by either SSL or TLS) uses port 443 regardless of which security protocol is chosen.  Furthermore, since TLSv1.0 and SSLv3 are very similar, supporting both was easy.  All TLS versions were refined in March 2011, which phased out support for SSLv2 of the protocol.  This, however, was not a sufficient enough reason to migrate many implementations away from the widely deployed SSLv3.

SSL/TLS Basic Protocol

In the basic protocol, if a client computer wishes to establish a connection with a server, for example to download email messages, it must first initiate contact with the server. The server responds by sending its certificate, which the client verifies and extracts from it the server’s public key. The client computer then selects a random number S from which the session keys will be computed, and sends it to the server encrypted using the server’s public key. The remainder of the session is then encrypted and integrity protected with those session keys.

Note that, as the session keys are derived from S, the client is able to authenticate the server since the server requires its private key in order to extract S. The server, however, is not able to authenticate the client unless, of course, it requests a username and password that is encrypted using the session keys. In theory, SSLv3 could be used for mutual authentication, and the protocol does allow for optional authentication by the client if it has a certificate and, is appropriate for the encryption scheme agreed to by both client and server. To this date, however, authentication is seldom mutual – that is, the client authenticates the server, but the server does not authenticate the client.

This, however, is not the vulnerability that was discovered. On the contrary, SLLv3 assumes that a session is relatively long-lived, and from it many short lived “connections” can be cheaply derived. This is also true for all versions of the TLS protocol. This is because they were designed to work with HTTP 1.0, which has a tendancy to open a lot of TCP connections between the same client and server.

The Heartbleed Bug

The vulnerability was introduced in the software implementation of SSLv3 in December 2011, and released in March 2012. Dubbed the Heartbleed bug, it exposes 64 kilobytes of memory from the server to the client or from the client to the server (whichever is trying to ascertain whether or not a connection or an active session still exists). For example, if the client attempts to ascertain whether or not an active session still exists with the server, the bug has the potential of exposing up to 64 kilobyes of server memory with every heartbeat request. Conversely so, if the server attempts to ascertain an active session with the client. This can happen if the session has been idle for a prescribed amount of time, and is a feature that has been added as an extension to the TLS protocol to keep connections alive without continuous data transfer.

This is achieved by sending a heartbeat request that can only be initiated (by the client or server) during an active session. The client or server (whichever receives the request) has the option of responding to the request with a heartbeat response message which, if sent, should contain an exact copy of the (arbitrary) data that was sent in the heartbeat request, and must not exceed 16 kilobytes.

To complicate matters, heartbeat requests are also used to establish connections between two peers (i.e. client and server) that minimises fragmentation of IP datagram records. Referred to as Path MTU Discovery (PMTUD), the process attempts to maximise the size of the transmission units (i.e. datagrams) by transmitting datagram records containing heartbeat requests of various lengths not to exceed 16 kilobytes. Note that, since this process does not require authentication, it is done prior to the SSL/TLS handshake (i.e. prior to encryption).

Either way, when a heartbeat request is received, and sending a heartbeat response is not prohibited, the receiver must send a corresponding heartbeat response message containing an exact copy of the payload (or message) in the heartbeat request. Unfortunately, a missing bounds check in the handling of the heartbeat, if exploited, can be used to return more than the 16 kilobyte limit specified by the protocol. Hence, the name of the bug, “heartbleed”.

According to Codemodicon, there is no 64 kilobyte limit to the attack – that limit only applies to a single heartbeat request. The attacker can keep requesting an arbitrary number of 64 kilobyte chunks of memory until enough secrets are exposed. For an active SSL session, this happens once per cycle of a prescribed time limit. When used to establish a session, however, the heartbeat request can be sent a number of times till an appropriate path that minimises fragmentation of datagram records is discovered.

What is being revealed?

Exploitation can allow an attacker to retrieve portions of sensitive data that is stored in the memory of the client or server at the time of the heartbeat request. This can include, but is not limited to, personal or financial details, private communications such as emails or instant messages, or any other documents worth protecting by encryption. It could also include details like the private or primary keys used in establishing a secure session!

In order to coordinate recovery from this bug, Codemonicon have classified the compromised secrets into four categories:

  1. primary key material
  2. secondary key material
  3. protected content
  4. collateral

The following sections discuss the (security) impacts of each category, including methods/strategies on how to recover from them. It elaborates on those discussed on the web site.

Compromised Primary Key Material

These are the private or primary keys used to establish a secure session. With them, attackers are able to decrypt any past and future traffic to and from the protected service, provided they (at least) capture the handshake messages that initiate those sessions. This is because the handshake signals, as noted earlier, contain the shared secret, S, between the client and server needed to encrypt/decrypt the remainder of the session.  Trying to determine the shared secret is difficult since no efficient (classical) algorithm for computing general discrete logarithms (the complexity category that this problem is classified under) is known.

This, however, does not prevent the attacker from impersonating the protected service.  That is, with the private or primary keys revealed, the attacker would be able to establish a shared secret between itself and the victim (typically a client), thereby tricking the peer (client or server) into revealing more personal/sensitive information.

Recovery from this sort of leak requires patching the vulnerability either by disabling the heartbeat extension, or updating the version of OpenSSL. Note that not all versions of OpenSSL contain this vulnerability. It also involves revoking the compromised keys and, reissuing and redistributing new keys. This is done by requesting a new X.509 certificate for each affected service from a Certificate Authority, examples of which include DigiCert, and Thawte, just to name a few. All of this needs to be done by the owners of the affected service(s).

Compromised Secondary Key Material

This, for example, includes user credentials such as the user ID and passwords that access the service. While this may not seem like a real concern, especially if there are no credentials, personal details, files or documents worth protecting, it should be of real concern to (at least) those who choose the same user ID and password across many internet services. This is because of security breaches similar to those experienced by Facebook users when sophisticated attacks on Adobe’s network revealed between 38 to 150 million names, encrypted credit/debit card numbers, poorly secured passwords, expiration dates, and information relating to customer orders. Knowing that people too often use the same user ID (typically an email address) and passwords to access different website accounts resulted in many breaches of user accounts on social network sites like Facebook. More information can be found on Adobe’s Customer Alert site, and The Register online in the UK.

For this reason, it is strongly advised that subscribers of website accounts avoid using the same passwords (at least) to access different services on the internet. Resetting the password, however, may not be enough to protect against further breaches. On the contrary, unless the service provider has patched the leak and reissued new certificates, subscribers of the affected service are still susceptible, especially if private or primary key material has been exposed.

Recovery from this type leak, therefore, requires the owners of the service to first patch the vulnerability, and reissue new certificates according to the steps described above, prior to subscribers of the service resetting their passwords. As a precaution, all session keys and session cookies are considered compromised, and therefore should be invalidated or deleted by the subscriber according to the instructions provided by the affected service. As a further precaution, and to mitigate against similar breaches in the future, it is strongly recommended that subscribers of internet services also regularly change their passwords (at most) every 90 days.

Compromised Protected Content

This is the actual content handled by the vulnerable services. It can include, but is not limited to, personal or financial details, private communications such as emails or instant messages, or any other documents worth protecting by encryption. There is very little that one can do to mitigate against such a leak, except for contacting the service provider to determine whether or not they were affected, and to determine the likelihood and extent of what has been compromised.

Only owners of the service will be able to determine the extent and likelihood of what has been leaked since they are typically aware of the record structures used to store the data in memory. For example, instant message records consist of the fields for content type, metadata headers (examples of which include the To: and From: address fields) and the encapsulated MIME message body. In this case, the most that has been revealed are the (email) addresses and message content. Either way, the owners of the affected service should notify their customers accordingly.

Recovery from this type of leak entails invalidating and/or deleting all session keys and cookies (as above), and resetting the password only after X.509 certificates have been reissued. This, however, will only secure future communication with the affected service. Any previous interaction with the affected service should be considered compromised in the off chance it has been captured.


This includes all other details that have been exposed to the attacker. For example, this may contain technical details such as memory addresses and/or security measures taken to protect against buffer overflow attacks. In other words, depending on the computer architecture and/or operating system, this has the potential of allowing the attacker to inject malicious code into portions of the operating system kernel stored in memory, thereby enabling them to seize control of the affected system. This information, however, will lose its value when OpenSSL has been patched either by disabling the extension, or upgrading it to a fixed version. Therefore, the onus to rectify this problem is on the owner of the affected service(s).


There is no doubt that Codemonicon have discovered a very serious vulnerability in the open source software implementation of the RFC 6520 standard describing the TLS heartbeat extension for keeping active sessions alive without the need of continuously transmitting data. This is not to say that there is a flaw in the SSL/TLS protocol. On the contrary, not all versions of OpenSSL are affected by this vulnerability. It is clear that all implementations prior to the introduction of the hearbeat extension do not contain this vulnerability. This is why disabling the extension on affected versions of the software will resolve the problem. Furthermore, this does not mean that there is a flaw in the standard describing the TLS heartbeat extension. Version 1.0.1g of OpenSSL, which fixes the bug, does not contain the vulnerability.

How many internet/online services have been affected has yet to be determined, although there are already reports of some major Australian financial institutions such as GE Money recommending to their customers to change their password. Also, some major Australian retail websites such as those for the Myer Visa Card and Myer Card, as well as the website for the Coles Mastercard, also appeared to be vulnerable. For further details, read Aussie Sites affected by Hearbleed Bug on Yahoo 7 News.

The main concern about the Heartbleed Bug is that it does not leave any trace or evidence of a service being compromised. Therefore, statements issued by financial institutions claiming that they have “…no reason to believe that any customer data has been compromised”, is simply not true. The only true indicator that they would have is an integrity check on the data (which may take months to verify), and/or the number of customer complaints of the service (or a lack thereof) relating to inconsistencies or mismatches in their (financial) details. In their defense, however, one can argue the fact that many financial institutes terminate active sessions that have been idle for a prescribed period of time. This would imply that the heartbeat extension has been disabled by the service, and therfore exploitation of the bug is not possible. This is probably why other financial institutes which shall not be named are advising concerned customers that it is not necessary to change their internet banking passwords.

It seems that web services such as email, instant messaging and electronic commerce are not the only entities affected by the bug. According to Codemonicon and the 7 News article (above), it would appear that equipment such as routers, switches and firewalls, that connect homes and businesses to the internet could also be affected by the vulnerability. This is because of the firmware software driving these devices could also be using the version(s) of OpenSSL known to contain the vulnerability. This means that attackers could potentially exploit the bug in a similar manner to web services.

Although web services can be fixed relatively quickly by either disabling the heartbeat extension, or updating the software to a (fixed) secure version of OpenSSL, this is not so easily achieved on hardware devices. Device makers would have to check each product to determine whether or not it is affected by the bug, and update the firmware software accordingly. The onus then is on the end consumer to consult with the manufacturer and, if affected, download and install the firmware version containing the fix (if possible). Till then, attackers could continue exploiting the bug.

Vulnerabilities in software are discovered almost every day. One need only visit the MITRE website (who is the authority responsible for maintaining the Standard for Information Security Vulnerability Names) to see a whole list of them. Like any other software bug, some are easily fixed and deployed, while others require a workaround till the problem is solved. Classic examples include the vulnerabilities discovered in Java Runtime Environments affecting web browsers. One specific example includes that identified by CVE-2013-0422, which has the potential to impact the availability, integrity and confidentiality of the user’s system, according to Oracle.

Albeit not as serious as the one uncovered by the security engineers of Codemonicon, Oracle strongly recommended that customers apply the updates provided by the security alert that they had issued as soon as possible. The other alternatives are to disable the Java Runtime Environment under the web browsers’ options, enable it only for trusted web sites, or not install it at all.

Generally, it is left to the diligence/discretion of the consumer to keep up to date with the latest versions of the software to avoid exploitation of vulnerabilities discovered in older versions. The same principle applies to the versions of OpenSSL that contain the vulnerability. This, however, is no comfort to the majority that are/were indirectly affected. In this case, the best that they can do is avoid using the (online) service till a level of trust has been re-established.

Nevertheless, to secure against similar breaches in the future, it is always good practice to change or reset one’s password (at most) every 90 days. Some organisations force their employees to do it sooner. This, in all likelihood, has the potential to secure against any past traffic that could have been captured and deciphered from being used to fraudulently access online services. In all likelihood, and has the potential because of the weak passwords that are most commonly being selected; also because of the potential for attackers to exploit bugs (in the wild) that have not yet been discovered. Most importantly, because nothing is 100% bullet proof when it comes to computer security. The best that cryptologists can do is make the problem of deciphering the transmission of encrypted communication so difficult that it will take months if not years to crack. By then, the usefulness or practicality of the information uncovered would more than likely be obsolete.


In conclusion, one can only guess whether or not the Heartbleed bug has been exploited, and to what degree. The fact that it does not leave behind any distinct footprints does not provide the consumer with any degree of confidence for security or privacy. The fact that it has existed in OpenSSL implementations of modern operating systems for over two years makes it even more disturbing. What’s worse is that, now that the threat has been revealed, there’s a good chance that attackers will try to exploit the bug prior to it being fixed. This is especially true for affected hardware devices linked to the internet, since a solution to resolve the problem is not readily available.

Otherwise, this is a good opportunity for service providers affected by the bug to strengthen their security and renew the private or primary keys used to establish secure communication. Although this is a painful task, it prevents cyber criminals from further taking advantage of this bug. Resetting passwords on a regular basis, however, can help circumvent similar breaches in the future. Ultimately, the onus is on the consumer to keep up to date with the latest version of software to avoid exploitation of vulnerabilities discovered in earlier versions. This is especially true for OpenSSL. For those that are indirectly affected by the Hearbleed bug, however, the best that they can do is to avoid using the (online) service till a level of trust has been re-established.