The other week, after OpenSSL released their latest security advisory, I went to work creating an ASPL check to heuristically identify servers which may be vulnerable to the man-in-the-middle attack described in CVE-2014-0224. After that was done, I decided to create a secondary Python script for free distribution through the Tripwire web site.
The response to this was overwhelming, with many writing that the tool had helped them identify and fix vulnerable servers in their environments. A few, however, reported some hiccups and confusion about what exactly the tool is testing for. As a result, I have made a series of updates to the code.
The main problem with creating an SSL vulnerability detection script is that there are many SSL/TLS implementations and a variety of variables to account for regarding how the SSL was deployed. My initial vulnerability check was written for Tripwire’s IP360 ,which leverages our internal ASPL scripting API to handle packet manipulation.
This makes it easy to write TLS record processing logic since TCP segments are cleanly accessible compared to direct access of a Python socket which relies on the developer requesting specific byte counts from a socket.
Although my initial Python implementation worked for most environments, the receive buffer sizes I had initially chosen led to a situation where long certificate messages could be mistaken as separate TLS records leading to an unexpected state.
The core logic for detecting unpatched OpenSSL servers relies on identifying servers which do not alert a problem when a change cipher spec (CCS) is received too early so proper record processing is a necessity. The long certificate issue was easily addressed by increasing the receive buffer size and a slight tweak to the algorithm for parsing TLS alerts.
With this change in place, I was advised that servers were consistently and accurately detected as patched.
Several days passed and I heard nothing but good news about the tool, until Friday when I was reminded of another important reality. The TLS protocol is defined by RFC2246 which states in section 7.2.1 (Closure Alerts) that “Each party is required to send a close_notify alert before closing the write side of the connection.”
Unfortunately this is not how all TLS implementations have been implemented – some will respond to certain error conditions by tearing down the TCP connection rather than sending the appropriate TLS alert record. Additionally some network protection appliances and proxy deployments can also affect what messages are exchanged over a TLS session.
Normally this isn’t such a big deal, but it means that a CVE-2014-0224 detection script cannot simply assume that a server permitted an early CCS message because no alert was received. Of course the easy fix for this is to simply confirm that the connection is still active before deciding that a scan target is vulnerable. This logic has been implemented and updated on Tripwire’s GitHub.
Please remember to only use this tool on systems you have permission to scan, and note that a server reported as ‘potentially vulnerable’ is exactly that – potentially vulnerable. If the tool indicates that your server may allow early CCS, you must still confirm that the target is in fact OpenSSL in the affected range as outlined in the OpenSSL security advisory.
- Mitigating the Latest Internet Explorer Zero-Day Vulnerability (CVE-2014-1776)
- Heartbleed and Your SOHO Wireless Systems
- Stopping the Heartbleed
- Detecting Heartbleed Exploits in Real-Time
The Executive’s Guide to the Top 20 Critical Security Controls
Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].