Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

4/10/2014
02:10 PM
Tim Sapio
Tim Sapio
Commentary
100%
0%

Heartbleed: Examining The Impact

With Heartbleed, there's little hope of knowing if an asset was breached, if a breach can be identified, or what, if any, data was leaked. Here's how to defend against future attacks.

Yesterday saw the beginning of the most significant breaches in Internet security to date. I’m talking, of course, about the vulnerability that was discovered in OpenSSL (CVE-2014-0160), commonly known as Heartbleed.

This was not a breach like the ones we’ve grown accustomed to hearing about in recent months, such as Target, Drupal, or the California DMV, wherein customers' personal data or login credentials were leaked. Instead, this breach strikes at the heart of encrypted transfers to the servers we all use in our day-to-day lives.

The Heartbleed vulnerability exists in all default versions of OpenSSL going back to March 2012. Among the products that use OpenSSL are Apache, IIS, Nginx, Cisco AnyConnect, your home router -- it’s harder to come up with a list of Web products that don't use OpenSSL than a list of those that do.

What exactly does this vulnerability do, and why is it so bad? Basically, Heartbleed allows an attacker to abuse a normal function of SSL, known as the heartbeat. The vulnerability permits an attacker to read bits of memory on an affected server to which he or she should not have access. Since the bug occurs at such a low level, merely connecting to a vulnerable system and sending it a specially formed request is enough to trigger the vulnerability. No authentication with the server is required. In practice, this means that attackers can connect to a vulnerable server, keep the connection alive, and wait for something interesting to come to their way. 

This may sound like an ineffective attack, since the attacker has no control over which specific parts of memory can be read, and no ability to change what is stored in the accessible locations. However, the consequences could not be more serious. The contents of the compromised memory include portions of all transactions the server has serviced. This includes private encryption keys, unencrypted traffic received or transmitted by the server, login credentials, pieces of your database, and pieces of confidential documents transferred through the application. Essentially, anything that the vulnerable application has in its own memory has a chance to end up in the tiny window the attacker can read.

What you need to know
So what does this mean, exactly? Here are the critical factors:

  • Heartbleed-vulnerable applications are those applications that use the default build of the OpenSSL library to build their connections, and are using any vulnerable versions of the library.
  • There are no reasonable limits on what information can be compromised. As long as it gets read by the application process, it is vulnerable.
  • Attacks can be easily automated and distributed in order to make identifying possible attackers extraordinarily difficult.
  • The attack has potentially been in the wild now for two years.

Starting to understand the full impact of this breach now? For other recent breaches, extreme though they were, we were able to put an upper limit on what may have been compromised, and who was to blame for those compromises. Here, however, everyone who was vulnerable could have potentially been leaking everything those applications saw for the past two years. There is also little hope of determining if an asset was breached in this way, or if a breach can be identified. You simply have no idea what sensitive data, if any, was leaked.

One thing is certain: If you do not take measures now against this bug, you will be hacked sooner rather than later. The attack is simply too easy to perform, and too widespread for it not to become one of the most widespread automated attacks ever.

The patched version is available from OpenSSL’s website, and from all major vendors through their own respective software update systems. For those of you who include OpenSSL in your own software, build using the patched version and push out your own patches! For those of you who are still waiting for patches or will not be able to patch the applications about which you are concerned, there are packet filters available that will filter out any heartbeat requests before they reach your vulnerable devices. Not sure if you are vulnerable? Run the Python script linked to below on your own server.

Other resources:

Tim Sapio is a Security Analyst at Bishop Fox (formerly Stach & Liu), a security consulting firm providing IT security services to the Fortune 500, global financial institutions, and high-tech startups. In this role, he focuses on penetration testing and network security. Tim ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
macker490
50%
50%
macker490,
User Rank: Ninja
4/13/2014 | 9:12:33 AM
Secure Computing in a Compromised World
the impact is less than you might think:   we all live in a heavilly compromised world due to years of poor practice.

 

i posted some notes on this here:

 

https://www.schneier.com/blog/archives/2014/04/friday_squid_bl_419.html#c5430516
tsapio
50%
50%
tsapio,
User Rank: Author
4/12/2014 | 8:35:59 AM
Re: Assessing damage
For maximum security assurance, you should patch all your servers, change all passwords, revoke and reissue all certificates, and consider the impact of everything served by vulnerable systems being compromised. Each company will have to make their own decisions in this regard. As I stated above, there is no way of telling what (if anything) has actually been compromised. It is one of the worst features of this attack, and there is no way to find out retroactively. If it passed through a vulnerable web server, it is potentially compromised.
tsapio
50%
50%
tsapio,
User Rank: Author
4/12/2014 | 8:32:38 AM
Re: Assessing damage
It is theoretically possible to determine by examining server logs that a possible attack has occurred. However, what has been compromised is still going to be almost impossible to determine since what is being compromised is contents of memory adjacent to the buffer that holds the normal heartbeat response. This information is not going to be logged under normal circumstances. It would be extremely memory intensive to do so, and very time consuming to analyze. My recommendation is to close off this hole because it is the easiest and safest course of action.
Thomas Claburn
100%
0%
Thomas Claburn,
User Rank: Ninja
4/10/2014 | 6:59:53 PM
Re: Assessing damage
Is there any consensus on the need to change passwords? I keep reading differing opinions.
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
4/10/2014 | 4:27:47 PM
Assessing damage
Thanks for a fascinating article Tim.  Now that the bug has been identified, going forward I assume it will be easier to tell when a breach has occurred. Or not? 

 
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
US Counterintelligence Director & Fmr. Europol Leader Talk Election Security
Kelly Sheridan, Staff Editor, Dark Reading,  10/16/2020
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-5790
PUBLISHED: 2020-10-20
Cross-site request forgery in Nagios XI 5.7.3 allows a remote attacker to perform sensitive application actions by tricking legitimate users into clicking a crafted link.
CVE-2020-5791
PUBLISHED: 2020-10-20
Improper neutralization of special elements used in an OS command in Nagios XI 5.7.3 allows a remote, authenticated admin user to execute operating system commands with the privileges of the apache user.
CVE-2020-5792
PUBLISHED: 2020-10-20
Improper neutralization of argument delimiters in a command in Nagios XI 5.7.3 allows a remote, authenticated admin user to write to arbitrary files and ultimately execute code with the privileges of the apache user.
CVE-2020-25157
PUBLISHED: 2020-10-20
The R-SeeNet webpage (1.5.1 through 2.4.10) suffers from SQL injection, which allows a remote attacker to invoke queries on the database and retrieve sensitive information.
CVE-2020-25648
PUBLISHED: 2020-10-20
A flaw was found in the way NSS handled CCS (ChangeCipherSpec) messages in TLS 1.3. This flaw allows a remote attacker to send multiple CCS messages, causing a denial of service for servers compiled with the NSS library. The highest threat from this vulnerability is to system availability. This flaw...