Broken Hearted? A Practical Look at the Heartbleed Vulnerability
Following on from our previous Heartbleed post, there have been countless reports on the far-reaching scale of this critical security flaw along with numerous discussions as to what 'exactly' an attacker can gain from exploiting the vulnerability.
Given the online and 'connected' nature of modern society, security and trust are the fundamental requirements of any online transaction in which personal or confidential data is transmitted. All of us, both technical and non-technical, have come to rely on the 'padlock in the address bar' - an indication that the website is handling our data securely, be that credentials, emails, financial records or status updates, with protection handled by the SSL or TLS protocols. It comes as no surprise that when the very thing that should be protecting us is compromised, in this case a feature within OpenSSL, that the implications can be far and wide.
Contributors: Abel Toro, Jason Hill, Alex Watson
What does this all mean?
As with any organized attack and as described by our 7 Stages of Advanced Threats, target reconnaissance precedes all other stages and, in this case will commence with determining which sites are (still) vulnerable to this OpenSSL vulnerability. As expected, given the widespread media exposure and severity of this flaw, numerous 'proof-of-concept' (PoC) scripts have been developed and are widely available thus allowing anyone with a command-line and an internet connection to start probing web-servers. Once a vulnerable site has been located, a threat actor can attempt to exploit the vulnerability, in this case by sending a specially crafted heartbeat packet which, rather than the original intended use, requests a larger than expected response which subsequently reveals up-to an additional 64k of memory. Once received, the threat actor can then attempt to sift through the returned data looking for 'interesting' items that can be further leveraged, for example, credentials or session IDs which would allow them to gain unauthorized access to the site in question or even, as widely suggested, private cryptography keys which could be used to compromise or impersonate the identity of a trusted site or person.
In practice - Obtaining Alice's credentials?
Targeting a specific user may prove impractical for a threat actor, especially on larger 'well-used' sites. For example, if our threat actor wanted to steal Alice’s login credentials for a specific site they wouldn't be able to specifically target 'Alice' and would have to keep running the exploit over a protracted period in the hope of harvest credentials which may or may not contain 'Alice's'. On the other hand, if the target site was smaller, less frequented or if it was known when Alice was likely to authenticate, the threat actor may have a higher chance of success although they would still need to be in the right place at the right time.
Given this, if you're thinking of changing your credentials it may be pertinent to ensure that the site is not vulnerable to the exploit.
Grabbing user names and passwords are relatively easy, private keys are more difficult.
Our research has shown that getting usernames, passwords and session IDs is quite feasible for an attacker in a real life scenario. The credentials can be stolen very quickly, without a trace and without much technical expertise.
However, while it is theoretically possible to retrieve the server’s private key using the Heartbleed vulnerability, in the real-world this is much more difficult than the aforementioned compromise of user names and passwords. At the time of writing, we have only seen one known successful PoC which can fully or partially extract the private key which required somewhat perfect conditions (for the threat actor):
- The exploit must account for the specific OS being targeted, in the case of the most widely available PoC: FreeBSD
- The threat actor must be the first one to communicate with the server after it is restarted in order for the private key to be in memory
(If the server has been running for a while the attack is not feasible and therefore a threat actor make seek to 'cause' the server to restart) - In a many cases the private key can only be partially extracted, given this, it may be necessary for the attack to be replayed numerous times in order to attempt to obtain all of the parts
- It is suggested that some fairly standard server configurations will make it much more difficult to get the private key - further reducing the chances of success
As detailed in our previous post, Websense strongly recommends mitigation actions such as regenerating private keys and revoking/reissuing certificates.
Demonstration
In order to demonstrate this vulnerability in a real-life scenario, Websense Security Labs conducted a brief practical analysis of the vulnerability by exploiting a test web-server in our lab environment.
Having scanned our test server and determined that it was vulnerable, it was trivial to start reviewing the returned memory results and arguably took under a minute to harvest credentials and gain access to that user’s account. However, as previously stated we needed to be in the right place at the right time and therefore required our victim to authenticate/interact with the website in order for their credentials to actually be 'in memory'.
Furthermore, confirming our earlier statement, so long as the server remained un-patched, it was possible to monitor password changes. This clearly highlights the need to exercise caution when interacting with vulnerable hosts such as in this example:
User changes an existing password to ‘secret1234’:
Which is subsequently exposed when exploited:
Through the use of session cookies, it is also practical for a threat actor to steal credentials even if the user is never prompted to login. Browsing to a site from an already established session is often common practice for web-based email and social network users:
Given this, is would be wise to avoid even browsing to vulnerable sites and system administrators should invalidate all session cookies. While a WordPress site on a vulnerable platform was used for testing purposes, other vulnerable sites are likely to exhibit similar results, albeit unlikely to be in such as clean and predictable manner. In this scenario we simulated a victim browsing to their favorite site and, as they know about the Heartbleed bug, they go onto change their password. Additionally, the use of sessions can expose your credentials so you're not safe just because a login page wasn't displayed.
Almost universally, the security mechanisms that we depend upon are based around trust in both cryptography and its implementation. This vulnerability has demonstrated the risk that can be associated with such ubiquitous adoption of a single implementation of a cryptography library (in this case, OpenSSL) and demonstrates the value for organizations to utilize a layered defense-in-depth strategy whenever possible.
