Guest post contributed by Ilai Bavati and Gilad Maayan of Agile SEO.
The Heartbleed vulnerability was introduced into the OpenSSL crypto library in 2012. It was discovered and fixed in 2014, yet today—five years later—there are still unpatched systems.
This article will provide IT teams with the necessary information to decide whether or not to apply the Heartbleed vulnerability fix. However, we caution: The latter would continue to leave your users’ data exposed to future attacks.
What is the Heartbleed vulnerability?
Heartbleed is a code flaw in the OpenSSL cryptography library. This is what it looks like:
memcpy(bp, pl, payload);
In 2014, a vulnerability was found in OpenSSL, which is a popular cryptography library. OpenSSL provides developers with tools and resources for the implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols.
Websites, emails, instant messaging (IM) applications, and virtual private networks (VPNs) rely on SSL and TLS protocols for security and privacy of communication over the Internet. Applications with OpenSSL components were exposed to the Heartbleed vulnerability. At the time of discovery, that was 17 percent of all SSL servers.
Upon discovery, the vulnerability was given the official vulnerability identifier CVE-2014-0160, but it’s more commonly known by the name Heartbleed. The latter was invented by an engineer from Codenomicon, who was one of the people that discovered the vulnerability.
The name Heartbleed is derived from the source of the exploit—a buggy implementation of the RFC 6520 Heartbeat Extension, which packed inside it the SSL and TLS protocols for OpenSSL.
Heartbleed vulnerability behavior
The Heartbleed vulnerability weakens the security of the most common Internet communication protocols (SSL and TSL). Websites affected by Heartbleed allow Internet users to read their memory. That means the encryption keys, which are supposed to protect data, are visible for anyone to see.
With the encryption keys exposed, threat actors gain access to the credentials—such as names and passwords—required to hack into systems. From within the system, depending on the authorization level of the stolen credentials, threat actors can initiate more attacks, eavesdrop on communications, impersonate users, and steal data.
How Heartbleed works
The Heartbleed vulnerability damages the security of communication between SSL and TLS servers and clients because it weakens the heartbeat extension.
Ideally, the heartbeat extension is supposed to secure the SSL and TLS protocols by validating requests made to the server. It allows a computer on one end of the communication to send a Heartbeat Request message.
Each message contains a payload—a text string that contains the transmitted information—and a number that represents the memory length of the payload—usually as a 16-bit integer. Before providing the requested information, the heartbeat extension is supposed to do a bounds check that validates the input request and returns the exact payload length that was requested.
The flaw in the OpenSSL heartbeat extension created an exploit in the validation process. Instead of doing a bounds check, the heartbeat extension allocated a memory buffer without going through the validation process. Threat actors could send a request and receive up to 64 kilobytes of any of the information available in the memory buffer.
Memory buffers are temporary memory storage locations, created for the purpose of storing data in transit. They may contain batches of data types, which represent different stores of information. Essentially, a memory buffer keeps information before it’s sent to its designated location.
A memory buffer doesn’t organize data—it stores it in batches. One memory buffer may contain sensitive and financial information, as well as credentials, cookies, website pages and images, digital assets, and any data in transit. When threat actors exploit the Heartbleed vulnerability, they trick the heartbeat extension into providing them with all of the information available within the memory buffer.
The Heartbleed fix
Bodo Moeller and Adam Langley of Google created the fix for Heartbleed. They wrote a code that told the heartbeat extension to ignore any Heartbeat Request message that asks for more data than the payload needs.
Here’s an example of a Heartbleed fix:
if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; /* silently discard per RFC 6520 sec. 4 */
How the Heartbleed vulnerability shaped OpenSSL as we know it
The discovery of the Heartbleed vulnerability created worldwide panic. Once the fixes were applied, idle fingers started looking for the causes of the incident. Close scrutiny at OpenSSL revealed that this widely-popular library was maintained solely by two men with a shockingly low budget.
This finding spurred two positive initiatives that changed the landscape of open-source:
- Organizations realized the importance of supporting open-source projects. There’s only so much two people can do with their personal savings. Organizations, on the other hand, can provide the resources needed to maintain the security of open-source projects.
- To help finance important open-source projects, Linux started the Core Infrastructure Initiative (CII). The CII chooses the most critical open-source projects, which are deemed essential for the vitality of the Internet and other information systems. The CII receives donations from large organizations and offers them to OSS initiatives in the form of programs and grants.
As with any change-leading crisis, the Heartbleed vulnerability also carried a negative side-effect: the rise of vulnerability brands. The Heartbleed vulnerability was discovered at the same time by two entities—Google and Codenomicon.
Google chose to disclose the vulnerability privately, sharing the information only with OpenSSL contributors. Codenomicon, on the other hand, chose to spread the news to the public. They named the vulnerability, created a logo and a website, and approached the announcement like a well-funded marketing event.
In the following years, many of the disclosed vulnerabilities were given an almost celebrity-like treatment, with PR agencies building them up into brands, and marketing agencies deploying branded names, logos, and websites. While this can certainly help warn the public against zero-day vulnerabilities, it can also create massive confusion.
Nowadays, security experts and software developers are dealing with vulnerabilities in the thousands. To properly protect their systems, they need to prioritize vulnerabilities. That means deciding which vulnerability requires patching now, and which could be postponed. Sometimes, branded vulnerabilities are marketed as critical when they aren’t.
When that happens, not all affected parties have the time, skills, and resources to determine the true importance of the vulnerability. Instead of turning vulnerabilities into a buzz word, professionals could better serve the public by creating fixes.
Heartbleed Exploit Kits
Today, five years after the disclosure of the Heartbleed vulnerability, it still exists in many servers and systems. Current versions of OpenSSL, of course, were fixed. However, systems that didn’t upgrade to the patched version of OpenSSL are still affected by the vulnerability and open to attack.
For threat actors, finding the Heartbleed vulnerability is a prize. With today’s automation capabilities, criminals can send bots to do the work for them. These bots are packed into Exploit Kits (EKs) which contain the resources needed to search, find, and then exploit the Heartbleed vulnerability.
Once the threat actor finds a vulnerable system, it’s relatively simple to exploit the vulnerability. When that happens, the threat actor gains access to information and/or launches another attack by delivering malicious payloads, such as spyware, Trojans, and ransomware.
Heartbleed attacks in 2019
The worst thing about Heartbleed is that you can’t always control whether it affects you or not. Many websites and systems now run in public cloud computing environments. The reason why a public cloud is relatively cheaper than a private cloud is that you agree to share resources. And sharing resources means agreeing to let your digital assets roam in different servers.
When you don’t control which server you use, you also don’t control which vulnerabilities you’re exposed to at any given time. For a while, you’ll be allocated a Heartbleed-free server, and then when there’s another rotation of resources, you might get a server with the Heartbleed vulnerability.
Once you’re vulnerable, you’ll be subjected to attacks such as malvertising and phishing schemes, which will try to trick you into downloading malicious payloads. If you do, the threat actors won’t be restricted only to the Heartbleed memory—they’ll get your session information and anything else you have stored on your system.
To patch or not to patch
The Heartbleed vulnerability is a security bug that was introduced into OpenSSL due to human error. Due to the popularity of OpenSSL, many applications were impacted, and threat actors were able to obtain a huge amount of data.
Following the discovery of the vulnerability, Google employees found a solution and provided OpenSSL contributors with the code that fixed the issue. OpenSSL users were then instructed to upgrade to the latest OpenSSL version.
Today, however, the Heartbleed vulnerability can still be found in applications, systems, and devices, even though it’s a matter of upgrading the OpenSSL version rather than editing the codebase. If you are concerned that you may be affected, you can test your system for the Heartbleed vulnerability and eliminate the risk with relative ease.
The post Everything you need to know about the Heartbleed vulnerability appeared first on Malwarebytes Labs.
Refer Here for Original Post and Source https://blog.malwarebytes.com/exploits-and-vulnerabilities/2019/08/everything-you-need-to-know-about-the-heartbleed-vulnerability/