Skip a heartbeat: OpenSSL Heartbleed Vulnerability & Prediction of Exploitation by Mehak Bashir - HTML preview

PLEASE NOTE: This is an HTML preview only and some elements such as links or page numbers may be incorrect.
Download the book in PDF, ePub, Kindle for a complete version.

CHAPTER 2

LITERATURE SURVEY

 

2.1 Introduction to Survey Report

In April 7, 2014 The Heartbleed Bug was independently discovered by a team of security engineers (Riku, Antti, and Matti, 2014) at Codenomicon and Neel Mehta of Google Security, who first reported it to the OpenSSL team. The security engineers did not have an idea of the vulnerability until the team found heartbleed bug while improving the Safeguard features. This was the city Codenomicon’s Defense security testing tools and reported this bug to the NCSC-FI for vulnerability coordination and reporting to OpenSSL team [5].

In addition, Bloomberg (2014) accused the U.S National Security Agency (NSA) of knowing the Heartbleed Bug for the last two years. Although, the report says the NSA was using it to gain information instead of disclosing it to the OpenSSL developer. After the NSA declining to comment to report of knowing about the Heartbleed Bug, NSA also denied that they were aware of Heartbleed Bug until the vulnerability was made public by the private security engineering of Google. Overall, the questions remain about whether anyone from the NSA or U.S government might have exploited the code for their benefits before published to the public.

The Heartbleed Bug is not a virus, it’s not a worm or a malicious code, and it has nothing to do with the Man-in-the-Middle, but it’s a simple programming mistake. However, the Heartbleed Bug is a serious vulnerability in the most popular OpenSSL cryptographic software library. This software allows anyone with little knowledge to steal the information such as the names and passwords of the users and the actual content protected, under normal conditions, by the SSL/TLS encryption used to secure the internet. In addition, the code of the Heartbleed Bug is available to the public and there are several sites that have tutorials to teach the use of the software, therefore this vulnerability is most critical.

The purposes of the SSL/TLS are to provide communication security and privacy over the internet for applications such as web, email, VPNs and social media [5]. Smartphones are the best practical example of client side attack, which lead to Blackberry (Z10) products to be vulnerable to Heartbleed Bug, in contrast of Apple’s iOS devices are not affected by OpenSSL. There are other devices affected by Heartbleed such as; IP Phones, Routers, Medical Devices and Smart TV sets. In addition, about 34 percent of Android devices run on version 4.1.x of the mobile OS, which according to Google millions of Android smartphones never, or only rarely receive available updates that patch dangerous security defects. For that reason, Android users should download Heartbleed Detector, a free application developed by Lookout.

The Heartbleed Bug attack works in several steps: First, the attacker creates a custom Heartbleed. Second, the packet is transmitted to vulnerable OpenSSL web server. Third web server processes packet. Fourth, the code grabs up 64KB of extra memory and hopes of capturing something sensitive from memory. Fifth, web server responds by sending a packet back which knowingly includes this extra sensitive data. Sixth, attacker analyzes packets to see if there is anything interesting, if not reruns attack to capture more memory. Lastly, if web server’s certificates private key is captured, it can be used to decrypt current and historical user data and credentials. Overall, is not complex to use the Heartbleed software. As mentioned before, any Heartbleed based attacks are not traceable, due that the problem has existed for the past 2 years without the knowledge of the public. Most server operators use a vulnerable method of the OpenSSL versions 1.0.1 – 1.0.1f and likely don’t have enough logs/monitoring to determine whether a site was compromised.

The Heartbleed bug reflects one of the most catastrophic vulnerabilities during the OpenSSL history for several reasons: it allowed attackers to retrieve private information and user data, it was easy to exploit and HTTPS and other TLS services have become increasingly popular by the resulting in more affected services [6].In addition, Stephen Solis-Reyes 19 year-old from Canada was arrested for exploiting the Heartbleed Bug to attack the website of the Canada Revenue Agency. As result, of the attack, Mr. Solis-Reyes had stolen 900 social insurances numbers (Elsevier, 2014). According, to Ivan Ristic, director of engineering at Qualys, has claimed that the percentage of websites vulnerable to the flaw had dropped from 25 percent since the bug was discovered. “Assistant Research Scientist Dave Levin and Assistant Professor of Electrical and Computer Engineering Tudor Dumitras were part of a team that analyzed the most popular websites in the United States-more than one million sites were examined-to better understand the extent to which systems administrators followed specific protocols to fix the problem”(NewsRx, 2014) [5].

2.2 General Survey

Who and what caused Heartbleed Bug? This question is answered with two graphics, displaying the bad code and the good code. The programmer Robin Seggelmann, a 31 year old based in Germany, submitted the code. The purpose of the software was to enable a function called “Heartbeat” in OpenSSL. This software package was to be used by nearly half of all web servers to enforce the connections. “In one of the new features, unfortunately, I missed validating a variable containing a length” (Seggelmann, 2012). In addition, the code went undetected by several code reviewers and everyone else for over two years. The graphics below shows the c- language code for the Heartbeat message in the OpenSSL source code. In the first graphic, it shows the data structure and the length of the message is given as payload_length.

As it shows below in the Graphic 1(Figure 0), the incoming data contains a payload length “payload”, the mistake of the code is that it trusts the request without bounds checks. OpenSSL then allocates a buffer for its response, and copies “payload” data bytes from the pointer “pl” into it. As result, there’s no “if statement” to make sure that there are actually “payload” bytes in data, or that this is in bounds. Since, there is no “if statement” the attacker gets a 64KB of data in length from main memory. When the attacker gets the 64KB of data the connection is no longer secure between servers and computers [7].

As stated by (Balon, 2014) “Think of the server’s memory like your mind,“ “Whatever is going through your mind right now, what you see in front of you, my words to you, whatever else you’re thinking about -- maybe a hotdog pops in there -- all that information can be scraped off the server, through the Heartbleed bug,” (Balon, 2014).

On the other hand, Graphic 2(Figure 0) shows the correct code with the “if statement” placed in the correct place. However, by making the correction of the code it does not guarantee that our server is secure and is no longer vulnerable. In order, to have a secure server or routers the security technician must take the following actions; upgrade your server to the latest version of OpenSSL, reissue and then revoke all certificates used with the vulnerable version of OpenSSL, and upgrade your security patches. As social media and online shopping user such as; Facebook, Google, eBay, Instagram and other sites that require user credentials may have to change our password if we haven’t change within the past 6 months.

img3.png

Figure 0: Graphic 1 and 2 shows the Heartbleed code