{"id":16204,"date":"2019-08-30T09:10:04","date_gmt":"2019-08-30T17:10:04","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2019\/08\/30\/news-9946\/"},"modified":"2019-08-30T09:10:04","modified_gmt":"2019-08-30T17:10:04","slug":"news-9946","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2019\/08\/30\/news-9946\/","title":{"rendered":"Everything you need to know about the Heartbleed vulnerability"},"content":{"rendered":"

Credit to Author: Malwarebytes Labs| Date: Fri, 30 Aug 2019 16:16:00 +0000<\/strong><\/p>\n

Guest post contributed by Ilai Bavati and Gilad Maayan of Agile SEO.
<\/em><\/p>\n

The Heartbleed vulnerability was introduced into the OpenSSL crypto library in 2012. It was discovered and fixed in 2014, yet today\u2014five years later\u2014there are still unpatched systems.\u00a0<\/p>\n

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\u2019 data exposed to future attacks. <\/p>\n

What is the Heartbleed vulnerability?<\/h3>\n

Heartbleed is a code flaw in the OpenSSL cryptography library. This is what it looks like:<\/p>\n

memcpy(bp, pl, payload);<\/p>\n

In 2014, a vulnerability was found in OpenSSL<\/a>, 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.\u00a0<\/p>\n

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.<\/p>\n

Upon discovery, the vulnerability was given the official vulnerability identifier CVE-2014-0160, but it\u2019s 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.<\/p>\n

The name Heartbleed is derived from the source of the exploit\u2014a buggy implementation of the RFC 6520 Heartbeat Extension, which packed inside it the SSL and TLS protocols for OpenSSL.<\/p>\n

Heartbleed vulnerability behavior<\/h3>\n

The Heartbleed vulnerability weakens the security of the most common Internet communication protocols (SSL and TSL<\/a>). 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. <\/p>\n

With the encryption keys exposed, threat actors gain access to the credentials\u2014such as names and passwords\u2014required 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.<\/p>\n

How Heartbleed works<\/h3>\n
\"\"\/<\/figure>\n

Image Source<\/a><\/p>\n

The Heartbleed vulnerability damages the security of communication between SSL and TLS servers and clients because it weakens the heartbeat extension. <\/p>\n

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. <\/p>\n

Each message contains a payload\u2014a text string that contains the transmitted information\u2014and a number that represents the memory length of the payload\u2014usually 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.<\/p>\n

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. <\/p>\n

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\u2019s sent to its designated location. <\/p>\n

A memory buffer doesn\u2019t organize data\u2014it 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.<\/p>\n

The Heartbleed fix<\/h3>\n

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. <\/p>\n

Here\u2019s an example of a Heartbleed fix<\/a>:<\/p>\n

if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; \/* silently discard per RFC 6520 sec. 4 *\/<\/p>\n

How the Heartbleed vulnerability shaped OpenSSL as we know it<\/h3>\n

The discovery of the Heartbleed vulnerability<\/a> 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. <\/p>\n

This finding spurred two positive initiatives that changed the landscape of open-source:<\/p>\n