Tuesday, 9 September 2014

How exactly does the Heartbleed exploit work?


The Heartbleed Bug

The Heartbleed Bug is a serious vulnerability in the popular 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.




This is not a flaw in TLS; it is a simple memory safety bug in OpenSSL.
The best explanations I've run across so far are the blog posts Diagnosis of the OpenSSL Heartbleed Bug by Sean Cassidy and Attack of the week: OpenSSL Heartbleed by Matthew Green.
In short, Heartbeat allows one endpoint to go "I'm sending you some data, echo it back to me". You send both a length figure and the data itself. The length figure can be up to 64 KiB. Unfortunately, if you use the length figure to claim "I'm sending 64 KiB of data" (for example) and then only really send, say, one byte, OpenSSL would send you back your one byte -- and 64 KiB (minus one) of other data from RAM.
Whoops!
This allows the other endpoint to get random portions of memory from the process using OpenSSL. An attacker cannot choose which memory, but if they try enough times, their request's data structure is likely to wind up next to something interesting, such as your private keys, or users' cookies or passwords.
None of this activity will be logged anywhere, unless you record, like, all your raw TLS connection data.
Not good.
http://xkcd.com/1354/
The above xkcd comic does a nice job illustrating the issue.

Edit: I wrote in a comment below that the heartbeat messages are encrypted. This is not always true. You can send a heartbeat early in the TLS handshake, before encryption has been turned on (though you're not supposed to). In this case, both the request and response will be unencrypted. In normal usage, heartbeats ought to always be sent later, encrypted, but most exploit tools will probably not bother to complete the handshake and wait for encryption.

Related Posts:

  • BECOMING A PENETRATION TESTER WHERE TO BEGIN ON THE PATH TO BECOMING A PENETRATION TESTER What you will need: 1) Books2) Virtual Machines (or physical machines)3) Operating Systems4) Hardware5) Software6) Basics So, let us begin with the most im… Read More
  • Penetration Testing What is the advantage of Penetration Testing Distribution?All Required application for security test are gathered in a single Operating system. You don't need to search for application, Save your time. Penetration Testing Di… Read More
  • Scanning backtrack tutorials Scanning The scanning process can be divided into three steps: Determining if a system is active. Port scanning the system. Scanning the system for vulnerabilities. Step 1 is the process of determining whether a targ… Read More
  • nmap tutorial Beginner's Guide to Nmap hi,readersGetting Nmap and Basic Use You'll find Nmap packaged for most major Linux distros. [backtrack] The basic syntax for Nmap is Nmap Scan Type Options targe… Read More
  • DNSMap Tutorial DNSMap Tutorial DNSMap Tutorial This tutorial will show you how to use DNSMap Background: Dnsmap is a small C based tool that perform brute-forcing of domains. The tool can use an int… Read More

1 comment:

  1. I to have hacking guides check them off my blog https://www.letstalk786.blogspot.com

    ReplyDelete