On Thursday February 9th the vulnerability named ’Ticketbleed’ was made public. The name of this vulnerability does not just sound similar to Heartbleed, but also shares the same implication: remote reading of uninitialized memory. At the time we published Snort IDS detection rules for the Heartbleed vulnerability in OpenSSL, and have now decided to do the same for the F5 vulnerability: Ticketbleed.
About Ticketbleed:
The vulnerability that would later become known as Ticketbleed, was identified by Filippo Valsorda following a support ticket at Cloudflare. The symptoms were failing connections between applications using the TLS Library of the Go programming language and F5 BIG-IP appliances. Filippo identified that SSL resumption requests were failing due to an assumption of the Session Ticket ID length in F5’s TLS stack. This exposes up to 31 bytes of memory per session, a lot less than Hearbleed, which leaked 64k bytes at a time. For more technical details see Finding Ticketbleed post by Filippo.
Mitigation:
Those running vulnerable F5 Appliances have two options to mitigate this vulnerability. One option is to disable Session Tickets entirely on the F5, this should stop the leaking of memory immediately and at virtually no cost. The recommended fix is to upgrade to the latest firmware which plugs this specific problem entirely as described in the following KB article K05121675.
Detection:
At Fox-IT we frequently write IDS detection rules, especially for customers, APTs, hacking tools or new vulnerabilities like Ticketbleed. The Ticketbleed website bears the following warning for those writing IDS signatures to detect the vulnerability:
The issue can be identified by passive traffic monitoring, as the Session ID field is unencrypted.
However, I’d like to strongly discourage IDS vendors from making signatures that simply detect Session IDs shorter than 32 bytes. Any length between 1 and 32 bytes is legal according to the RFC specification.
The Go standard library legitimately uses 16 bytes Session IDs, and browsers considered using 1 byte Session IDs for this purpose. It’s important for security software not to needlessly constrain future decisions in that direction.
Taking this into account, we wrote two signatures for Snort IDS. The first rule searches for ‘Client Hello’ packets that have a session identifier that is shorter than 32 bytes. Using the ‘flowbits’ feature of Snort, the second signature looks for a ‘Server Hello’ packet that does contain a 32 byte session identifier. Writing rules to match binary protocols such as TLS can be challenging and has a higher chance of false positives. While this signature has not resulted in any False Positives on our side, we welcome any feedback as a result of these rules.
Rules:
The two rules can be found on our GitHub Gists:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # IDS Signatures to detect Ticketbleed (CVE-2016-9244) | |
| # https://blog.fox-it.com/2017/02/13/detecting-ticketbleed-cve-2016-9244/ | |
| alert tcp $EXTERNAL_NET any -> $HOME_NET [$HTTP_PORTS,443] (msg:"FOX-SRT – Flowbit – TLS session resumption < 32 byte session id (noalert)"; flow:established,to_server; content:"|1603|"; depth:2; content:"|01|"; distance:3; within:1; byte_test:3,<,3000,0,relative; content:"|03|"; distance:3; within:1; byte_test:1,<,32,33,relative; byte_test:1,>,0,33,relative; flowbits:set,fox.ticketbleed.session; flowbits:noalert; threshold:type limit, track by_src, count 1, seconds 600; classtype:attempted-recon; reference:cve,2016-9244; reference:url,https://ticketbleed.com; reference:url,blog.fox-it.com/2017/02/13/detecting-ticketbleed-cve-2016-9244; sid:21002061; rev:6;) | |
| alert tcp $HOME_NET [$HTTP_PORTS,443] -> $EXTERNAL_NET any (msg:"FOX-SRT – Vulnerability – Possible Succesful F5 Big-IP TLS Ticketbleed"; flow:established,to_client; flowbits:isset,fox.ticketbleed.session; content:"|1603|"; depth:2; byte_extract:2,1,rec_len,relative; content:"|02|"; distance:0; within:1; content:"|03|"; distance:3; within:1; byte_test:1,=,32,33,relative; content:"|1403|"; offset:rec_len; depth:7; content:"|000101|"; distance:1; within:3; threshold:type limit, track by_src, count 1, seconds 600; classtype:successful-recon-limited; reference:srt,1298; reference:cve,2016-9244; reference:url,https://ticketbleed.com; reference:url,blog.fox-it.com/2017/02/13/detecting-ticketbleed-cve-2016-9244; priority:2; sid:21002062; rev:5;) |
https://gist.github.com/fox-srt/bc59eb69dc8f261f97f9623bde885f4b
When trying to verify hits in Wireshark we used the following expression filters:
Identify packets containing SSL session identifiers:
ssl.handshake.session_id_length
Search for session identifiers smaller than 32 bytes and equal to 32 bytes:
(ssl.handshake.session_id_length > 0 && ssl.handshake.session_id_length < 32) || ssl.handshake.session_id_length == 32
If the above filter returns two packets, you are likely dealing with a vulnerable F5 appliance. As can be seen in the following screenshot:
Special thanks to Yun Zheng Hu for writing these rules!