Jan 15, 2019
164 Views
3 0

Heartbleed bug, How it works and how was it fixed?

Written by

The mistake that caused the Heartbleed vulnerability can be traced to a single line of code in OpenSSL, an open source code library. Here’s what you need to know now.

Guys First of all I want To Clear Your One Misconception About It. Is it a Virus Or Bug. Actually, Heartbleed is not a “computer virus”, it is a vulnerability in the OpenSSL cryptographic software library. 
This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).
The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names, and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

In Simple Words We Can Say Heart Bleed Is a Bug In Open SSL/TLS Flow.

The TLS/SSL standards are crucial for modern web encryption, and while the flaw was in the OpenSSL implementation rather than the standards themselves, OpenSSL is so widely used — when the bug was made public, it affected 17% of all SSL servers — that it precipitated a security crisis.

How Heartbleed works

To understand how the Heartbleed vulnerability (CVE-2014-0160) works, you need to know a little bit about how the TLS/SSL protocols operate, and how computers store information in memory.

One important part of the TLS/SSL protocols is what’s called a heartbeat.Essentially, this is how the two computers communicating with one another let each other know that they’re still connected even if the user isn’t downloading or uploading anything at the moment. Occasionally, one of the computers will send an encrypted piece of data, called a heartbeat request, to the other. The second computer will reply back with the exact same encrypted piece of data, proving that the connection is still in place. Crucially, the heartbeat request includes information about its own length.

READ ALSO  Simplifying Kubernetes With Docker Compose and Friends

So, for example, if you’re reading your Yahoo mail but haven’t done anything in a while to load more information, your web browser might send a signal to Yahoo’s servers saying, in essence, “This is a 40 KB message you’re about to get. Repeat it all back to me.” (The requests can be up to 64 KB long.) When Yahoo’s servers receive that message, they allocate a memory buffer — a region of physical memory where it can store information — that’s 40 KB long, based on the reported length of the heartbeat request. Next, it stores the encrypted data from the request into that memory buffer, then reads the data back out of it and sends it back to your web browser.

That’s how it’s supposed to work. The Heartbleed vulnerability arose because OpenSSL’s implementation of the heartbeat functionality was missing a crucial safeguard: the computer that received the heartbeat request never checked to make sure the request was actually as long as it claimed to be. So if a request said it was 40 KB long but was actually only 20 KB, the receiving computer would set aside 40 KB of memory buffer, then store the 20 KB it actually received, then send back that 20 KB plus whatever happened to be in the next 20 KB of memory. That extra 20 KB of data is information that the attacker has now extracted from the web server.

This is the crucial part of the operation. Even when a computer is done with information, it persists in memory buffers until something else comes along to overwrite it. If you’re the attacker, you have no way to know in advance what might be lurking in that 20 KB you just grabbed off the server, but there are a number of possibilities. It could be gibberish or useless cruft. You could get SSL private keys, which would allow for the decryption of secure communication to that server (this is unlikely, but would be the holy grail for an attacker). More commonly, you could get back usernames and passwords that had been submitted to applications and services running on the server, which would allow you to log in and gain access.

READ ALSO  Introduction to Tabnapping - Hacking When The Phishing is Outdated.

Heartbleed code

Remember, This Vulneriblity Is Still Available In Sites Who are Using Free SSL. Use These Codes At Your Own risk. {I Mentioned It Just For Educational Purpuses.

The coding mistake that caused Heartbleed can be traced to a single line of code:

memcpy(bp, pl, payload);

memcpy() is the command that copies data. bp is the place it’s copying it to, pl is where it’s being copied from, and payload is the length of the data being copied. The problem is that there’s never any attempt to check if the amount of data in pl is equal to the value given of payload.

The most ironic thing here is that OpenSSL is open source software. Anyone could look at the code, and presumably hundreds did, but nobody noticed the fairly elementary coding error.

The Heartbleed fix

Patches were rolled out for OpenSSL right away when the vulnerability was announced, and in all likelihood most formerly vulnerable servers have been updated by this point, but it can’t hurt to test if you’re not sure — it’s always possible that some server that’s important to you has been chugging along for years without a proper upgrade. Pentest-tools.com has a free web-based testthat lets you input a URL to discover if a server has been properly patched.

The way to fix the Heartbleed vulnerability is to upgrade to the latest version of OpenSSL. You can find links to all the latest code on the OpenSSL website.

If you’re curious about the code that implements the fix, you can look at it — after all, OpenSSL is open source:

READ ALSO  SQL Injection Attacks: Know How to Prevent Them

* Read type and payload length first */

if (1 + 2 + 16 > s->s3->relent)

return 0;

/* silently discard */

hbtype = *p++;

n2s(p, payload);

if (1 + 2 + payload + 16 > s->s3->rrec.length)

return 0;

/* silently discard per RFC 6520 sec. 4 */

pl = p;

The first part of this code makes sure that the heartbeat request isn’t 0 KB, which can cause problems. The second part makes sure the request is actually as long as it says it is.

If you discover that a server under your control has been left vulnerable for some time, there’s more to do than just update the OpenSSL code. For instance, you should change the SSL certificates used by the servers, since they may have been compromised without leaving a trace. More pedestrian but still important: users who have accounts on the system should change their passwords.

Now Check out, How Non-Tech Guys Are Spreading Wrong Information About “Heart bleed” Bug.

  • As I told Above Its Not a Virus. Its Bug In Programming That Used By Hackers To Get Access To Confidential Data.
  • Red Herring is Not a Device Its a Line Of Codes To Create Loop In Decoy Servers.
  • Red Herring was Failed Experiment.
  • This Vulneriblity/Bug Still Available In Website Those Are Using Free SSL.

Guys There’r Lot’s Of Misleading Lines. As I Explained From Starting.

Guys Just One Like For My Post To Write This Blog.


Article Categories:
In-Depth Concepts · Information
http://techandsecurity.net

CEO & FOUNDER OF" FIVE RIVERS INCORPORATION - LEADING SOFTWARE & CYBER SECURITY DEVELOPMENT COMPANY" || CERTIFIED ETHICAL HACKER || FUTURE TRILLIONAIRE || FUTURISTIC || "DULL SCHOOL STUDENT" || (Follow this link to message me on WhatsApp: https://wa.me/13018426470)

Comments to Heartbleed bug, How it works and how was it fixed?

Leave a Reply

Your email address will not be published. Required fields are marked *

Share