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.

Vulnerabilities / Threats

8/20/2014
12:00 PM
Steve Riley
Steve Riley
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

Debugging The Myths Of Heartbleed

Does Heartbleed really wreak havoc without a trace? The media and many technical sites seemed convinced of this, but some of us were skeptical.

Now that IT organizations across the globe have had time to recover from the recent Heartbleed flaw, what can we learn from this incident? The vulnerability was discovered in an OpenSSL library used by thousands of websites on public and private networks and had gone unnoticed for years. Attackers could force a web server to reveal data from inside an SSL session, completely bypassing encryption. As if that weren't bad enough, initial reports claimed that the Heartbleed attack on the TLS/DTLS heartbeat extension occurred "without a trace."

It would not be an understatement to characterize Heartbleed as one of the creepiest security vulnerabilities ever to lurk across the Internet. Here's a quick summary of its timeline:

  • 2011 -- A German coder accidently creates a security vulnerability in an OpenSSL extension with a simple line of code
  • 2011 to 2014 -- Years go by and no one notices this vulnerability; despite the code being open source, it will become a problem for millions of users
  • March 21, 2014 -- The vulnerability is discovered independently by Google engineer Neel Mehta and the Finnish security firm Codenomicon
  • March 21 to April 7 -- Google, CloudFlare, Akamai, Red Hat, and Facebook complete unannounced patching of their OpenSSL libraries
  • April 7 -- MITRE Organization officially reports the Heartbleed bug in CVE-2014-0160 and the OpenSSL Project immediately issues version 1.0.1g that fixes the vulnerable code
  • April 7 until now -- Vendors of products that use OpenSSL scramble into a frenzy to identify, diagnose, and update their products.

What's in this bug and what's at stake
Let's be clear: this isn't a flaw in SSL/TLS or in the heartbeat extension (RFC 6520). The vulnerability exists within the OpenSSL implementation of the extension. Heartbleed exploit code allows attackers to force a web server to reveal 64 KB chunks of certain memory regions by overflowing a buffer. While it isn't possible to predict what might be revealed, successful attacks have obtained session keys, passwords, and other information that should normally remain confidential.

Finding the hidden evidence
Does Heartbleed really wreak its havoc while leaving nary a trace? The media and many technical sites seemed convinced of this, but some of us were skeptical. The Heartbleed attacks surely leave some evidence behind: packets. Packets almost always tell a detailed story of what has really happened, including in the case of Heartbleed. The trick, of course, is to have the packets.

It's true that a server attacked with a Heartbleed exploit is unlikely to reveal any evidence. Stored packets, meanwhile, do tell the story of a successful Heartbleed exploit even after the adversary has stopped an active attack.

Detecting a prior Heartbleed exploit
Continuous monitoring of a network can reveal active Heartbleed attacks. But even more importantly, with a sufficiently large rolling buffer of packet capture data, it becomes possible to look back in time, before the public disclosure of the Heartbleed vulnerability. An investigation of this data may reveal whether an actual exploit of vulnerable servers has occurred.

A Berkeley Packet F (BPF) placed in the network can automatically flag larger-than-normal TLS heartbeat responses from servers. Wireshark, tcpdump, and other tools can analyze the captured packets for confirmation of an attack.

Why BPF?  BPF engines are fast -- something of a requirement given the sheer amount of traffic passing through modern networks. Important for the use case here, a BPF capture is a common format for packet processing, understood by the majority of operating systems and packet-analyzing software. The wide availability of BPF is the main reason it can become easy to detect Heartbleed attacks.

BPF engines are available for Linux, for Mac OS, for Windows (via WinPcap), and can be placed on cloud computing instances. BPF and tcpdump are present on most network appliances (such as firewalls, load balancers, and application delivery controllers) and often accessible through an administrative console for troubleshooting purposes. And, of course, packet analysis and storage engines in products designed for supporting network performance management almost all support BPF.

As a result, many individuals in the technical community have responded with plenty of resources to develop a BPF filter appropriate for detecting Heartbleed attacks. Most of these filters examine traffic from port 443/tcp (the default HTTPS port). The usual size threshold is 69 bytes; this can be adjusted upwards or downwards to reduce false positives or false negatives if necessary.

Final thoughts
Having a nimble awareness of the data in your network, a basic understanding of how secure services should normally operate, and the ability to investigate anomalies can inoculate you from the unavoidable hype. Packets do not lie -- but you have to capture them to reveal their truths.

A large rolling buffer of packet capture data establishes an ideal forensics basis. From this, you can determine what has actually occurred during the time when vulnerability exploits run wild. Certainty is always better than mere speculation over hypothetical breaches in security.

Steve actively works to raise awareness of the technical and business benefits of Riverbed's performance optimization solutions, particularly as they relate to accelerating the enterprise adoption of cloud computing. His specialties include information security, compliance, ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Bprince
50%
50%
Bprince,
User Rank: Ninja
8/26/2014 | 10:55:57 PM
Heartbleed
This is a very good rundown of Heartbleed with great information about how to uncover possible breaches. Was surprised to heaer it was used against CHS given the amount of publicity and the fact that they are not some small business.

BP
RoyKelly2
50%
50%
RoyKelly2,
User Rank: Apprentice
8/23/2014 | 12:33:23 AM
Re: Heartbleed and CHS breach
Good points Steve!

Reading a related article about Heartbleed and Community Heath Systems by Sara Peters, "Heartbleed Not Only Reason For Health Systems Breach", also on Dark Reading,  I see many things that added to what was taken through Heartbleed.  According to the detailed anaylysis of the attack one user's credentials were taken through Heartbleed and the patient data was taken using those credentials.

The expanded attack was aided by weaknesses on their security posture, namely;
  • They only watched what came in, and ignored outgoing traffic;
  • Stange behaviour by a user logging in from a new remote location should have raised flag, but did not for the duration of the attack;
  • VPN logins that only use user names and passwords when there are many ways to add security to VPN (like trusted devices information added to user credentials);
  • Monolithic data structure, with the same level of security applied to the entire structure.

To me it appears that they threw a firewall up, installed spyware and virus scanning, and called it secure.  The problem is that once a way is found through the firewall almost all the data is there for the taking.  While no health or payment data was taken this time, I have seen nothing that indicates it was more secure... and personal experience tells me it most likely was not.

I am not the biggest fan of encryption, but it helps secure data at rest and on the fly, especilay when coupled with two-factor authentication - such as user credetnials coupled with trusted device information.  While it is not impossible to emulate a trusted machine, if basic security processes are followed where the machine info is double hashed before it is sent, it becomes much harder.

CHS is not a non-profit, so it seems like they should be abble to afford better security.
Steve Riley
100%
0%
Steve Riley,
User Rank: Author
8/21/2014 | 1:25:11 PM
Re: Heartbleed and CHS breach
Sloppiness? Inattention? Lack of awareness or concern for risk? It perplexes me that people don't take this stuff seriously. Heartbleed was discovered on April 7. Juniper issed security advisory JSA10623 and knowlegebase article KB29004. We don't know when these were first issued -- all we can see are "last updated" dates of April 30 and May 6, respectively. Some reports indicate Juniper issued patches only three days after April 7. But regardless, it's now late August. The hospital didn't update their stuff after more than three (or four) months? That's inexcusable, especially for something like a VPN server, a device intended to deposit users on the inside of a corporate network.

I understand that IT departments have processes and change windows. But when a vendor issues an out-of-band patch for a flaw the vendor labels as critical, it's time to throw the change window, well, out the window. Install the patch right away. Emergency but controlled downtime dealing with a patch is much preferable to the disastrous and devastating downtime caused by an attack!
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
8/21/2014 | 9:08:47 AM
Heartbleed and CHS breach
Thanks for a fascinating perpsective on Heartbleed. What's your reaction to the latest Heartbleed-related breach at Community Health Services? Are there are any takeaways from what happened? 
Charlie Babcock
100%
0%
Charlie Babcock,
User Rank: Ninja
8/20/2014 | 5:03:06 PM
A sober assessment
This is a good, sober assessment of Heartbleed's impact by a veteran security architect. Riley was previously one of the security brains behind Amazon operations.
Data Leak Week: Billions of Sensitive Files Exposed Online
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/10/2019
Intel Issues Fix for 'Plundervolt' SGX Flaw
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-5252
PUBLISHED: 2019-12-14
There is an improper authentication vulnerability in Huawei smartphones (Y9, Honor 8X, Honor 9 Lite, Honor 9i, Y6 Pro). The applock does not perform a sufficient authentication in a rare condition. Successful exploit could allow the attacker to use the application locked by applock in an instant.
CVE-2019-5235
PUBLISHED: 2019-12-14
Some Huawei smart phones have a null pointer dereference vulnerability. An attacker crafts specific packets and sends to the affected product to exploit this vulnerability. Successful exploitation may cause the affected phone to be abnormal.
CVE-2019-5264
PUBLISHED: 2019-12-13
There is an information disclosure vulnerability in certain Huawei smartphones (Mate 10;Mate 10 Pro;Honor V10;Changxiang 7S;P-smart;Changxiang 8 Plus;Y9 2018;Honor 9 Lite;Honor 9i;Mate 9). The software does not properly handle certain information of applications locked by applock in a rare condition...
CVE-2019-5277
PUBLISHED: 2019-12-13
Huawei CloudUSM-EUA V600R006C10;V600R019C00 have an information leak vulnerability. Due to improper configuration, the attacker may cause information leak by successful exploitation.
CVE-2019-5254
PUBLISHED: 2019-12-13
Certain Huawei products (AP2000;IPS Module;NGFW Module;NIP6300;NIP6600;NIP6800;S5700;SVN5600;SVN5800;SVN5800-C;SeMG9811;Secospace AntiDDoS8000;Secospace USG6300;Secospace USG6500;Secospace USG6600;USG6000V;eSpace U1981) have an out-of-bounds read vulnerability. An attacker who logs in to the board m...