News
4/24/2014
08:00 AM
Chris Chapman
Chris Chapman
Commentary
Connect Directly
Facebook
Twitter
LinkedIn
RSS
E-Mail
50%
50%

How To Detect Heartbleed Mutations

The nightmare of Heartbleed is not the chaos of fixing the bug. It's identifying hundreds, possibly thousands, of small mutations still hiding in the network.

By now, most of you must have started to implement or have already implemented the Heartbleed security patches on to your servers. Heartbleed, one of the biggest security exploits that the industry has experienced so far, exists in OpenSSL and affects the way TLS/DTLS Heartbeat packets are handled. This weakness allows the access to the memory contents of a connected client or server. This means that any web server using OpenSSL is a potential target -- roughly 66% of all websites.

The biggest nightmare for security managers and infrastructure vendors is not the chaos of trying to fix the vulnerability exposed by Heartbleed, but variations of the bug that are already in the network unbeknownst to them. The Heartbleed vulnerability will follow the classic pattern of mutation. There will be hundreds and possibly thousands of small but critically different variants, so patching the root attack will not stop the threat, and could lead to a false sense of security.

A security patch, by definition, closes a discrete set of security holes in a product. Attack mutations, may or may not fall within the scope of the patch. The point is you are never sure and will always play catch up. The key is to proactively and progressively test to defend against the Heatbleed mutations.

First step: Fuzzing analysis
The first step in testing for Heartbleed mutation is to perform a full fuzzing analysis of the server SSL stack. This will narrow down an infinite number of possibilities to a finite list of candidate breech points. In the case of the root vulnerability, the SSL client had the ability in the Heartbeat response to request greater than 64k bytes of data. A fuzzer would directly test this scenario and would find the vulnerability by using an OutofBounds method (which is automatically generated by the fuzzer). Once you identify the holes and patch them, you need to rerun fuzzing in conjunction with your specific mix of application protocols to measure if loading opens more holes, or patch mitigation lowers quality of experience.

The best approaches to gain assurance, is one-arm stateful SSL/TLS exhaustivel testing and with full realism. Two arm 'simulations' will not test your network's vulnerability to attack. SSL/TLS fuzzing will recursively test mutation holes exhaustively. True one-arm HTTPS with support for keys and certs, and stateful peering with your network allows you to test "what if" scenarios under deep realistic scale. Exhaustive testing treats the device under test (DUT) as a system which allows stately interaction with the system in a one-arm mode, providing the ability to peer into the protocol in question (i.e., SSL/TLS). In the case of fuzzing, it automatically walks thought the finite state machine of the protocol. No testing system is perfect, but one-arm exhaustive testing exposes the DUT to far more measured coverage and reduces the chance of exploitation.

Finding, fixing, and scanning for vulnerabilities needs to be an iterative process that cannot be left to vendors. IT teams can easily take control of their network security destiny with proactive and progressive testing.

Chris Chapman has more than 20 years of experience with multiprotocol and cloud networking technologies, with emphasis on systems root-cause analysis, quality of experience, performance, and scale realism testing for both IPv4 and IPv6. He has written and deployed ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
0xtero
50%
50%
0xtero,
User Rank: Apprentice
4/25/2014 | 11:07:57 AM
Re: Testing for Heartbleed mutations, anyone?
No because there is no such thing as Heatbleed mutation.

The Heartbleed bug is a missing boundary check in OpenSSL code - a library that implements TLS, it's not a flaw in the TLS protocol. 

Moving on to servers to test for "advanced mutations" makes no sense at all. Either the patch is applied or it isn't - there are no variants of it. The bug doesn't magially mutate to something else on it's own. There are no other attack vectors. It's not a protocol level flaw, it's flaw in one library that implements the protocol. Other SSL libraries are not vulnerable. This is OpenSSL bug only.

The article uses terminology (mutation, spreading) that also plays on the "heartbleed is a virus" fallacy and as such is not only inaccurate but also dangerously close to being pure FUD.

OpenSSL and other libraries most likely contain other bugs - and more rigorous testing is a very good idea, especially for components that are widely used(/embedded) in core infrastructure products. But that has nothing to do with Heartbleed, it's just common sense.

Heartbleed has caused a lot of panic and misinformation, let's not create any more of it.

 
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
4/24/2014 | 4:15:01 PM
Testing for Heartbleed mutations, anyone?
Curious to know if anyone in the Dark Reading Community has moved beyond Heartbleed security patches on to servers to advanced testing for mutations....
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading, January 2015
To find and fix exploits aimed directly at your business, stop waiting for alerts and become a proactive hunter.
Flash Poll
10 Recommendations for Outsourcing Security
10 Recommendations for Outsourcing Security
Enterprises today have a wide range of third-party options to help improve their defenses, including MSSPs, auditing and penetration testing, and DDoS protection. But are there situations in which a service provider might actually increase risk?
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3580
Published: 2014-12-18
The mod_dav_svn Apache HTTPD server module in Apache Subversion 1.x before 1.7.19 and 1.8.x before 1.8.11 allows remote attackers to cause a denial of service (NULL pointer dereference and server crash) via a REPORT request for a resource that does not exist.

CVE-2014-6076
Published: 2014-12-18
IBM Security Access Manager for Mobile 8.x before 8.0.1 and Security Access Manager for Web 7.x before 7.0.0 FP10 and 8.x before 8.0.1 allow remote attackers to conduct clickjacking attacks via a crafted web site.

CVE-2014-6077
Published: 2014-12-18
Cross-site request forgery (CSRF) vulnerability in IBM Security Access Manager for Mobile 8.x before 8.0.1 and Security Access Manager for Web 7.x before 7.0.0 FP10 and 8.x before 8.0.1 allows remote attackers to hijack the authentication of arbitrary users for requests that insert XSS sequences.

CVE-2014-6078
Published: 2014-12-18
IBM Security Access Manager for Mobile 8.x before 8.0.1 and Security Access Manager for Web 7.x before 7.0.0 FP10 and 8.x before 8.0.1 do not have a lockout period after invalid login attempts, which makes it easier for remote attackers to obtain admin access via a brute-force attack.

CVE-2014-6080
Published: 2014-12-18
SQL injection vulnerability in IBM Security Access Manager for Mobile 8.x before 8.0.1 and Security Access Manager for Web 7.x before 7.0.0 FP10 and 8.x before 8.0.1 allows remote authenticated users to execute arbitrary SQL commands via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Join us Wednesday, Dec. 17 at 1 p.m. Eastern Time to hear what employers are really looking for in a chief information security officer -- it may not be what you think.