Ticketbleed is a software vulnerability in the TLS/SSL stack of F5 BIG-IP appliances allowing a remote attacker to extract up to 31 bytes of uninitialized memory at a time.
This memory can potentially contain key material or sensitive data from other connections.
It is similar in spirit and implications to the well known Heartbleed vulnerability. It is different in that it exposes 31 bytes at a time instead of 64k, requiring more rounds to carry out an attack, and in that it affects the proprietary F5 TLS stack, not OpenSSL.
F5 published article K05121675 addressing this vulnerability. You can read the story of how Ticketbleed was found and a complete technical walkthrough on the Filippo.io blog.Test
Enter a hostname below to test the server for Ticketbleed.
All good,seems fixed or unaffected!
Uh-oh, something went wrong:
You can specify a port like this example.com:4433 . 443 by default.
You can test for Ticketbleed yourself with a Go script like this .Technical Details
The vulnerability lies in the implementation of Session Tickets, a resumption technique used to speed up repeated connections.
When a client supplies a Session ID together with a Session Ticket, the server is supposed to echo back the Session ID to signal acceptance of the ticket. Session IDs can be anywhere between 1 and 31 bytes in length.
The F5 stack always echoes back 32 bytes of memory, even if the Session ID was shorter. An attacker providing a 1-byte Session ID would then receive 31 bytes of uninitialized memory.Fixes and mitigation
The full list of affected versions is available on the F5 website . At the time of this public disclosure not all releases have upgrade candidates available.
Disabling Session Tickets is a complete mitigation, which will only cause a performance degradation in the set-up phase of resumed connections.
Reproduced here are the instructions provided by F5 and available at the link above.Log in to the Configuration utility Navigate on the menu to Local Traffic > Profiles > SSL > Client Toggle the option for Configuration from Basic to Advanced Uncheck the Session Ticket option to disable the feature Click Update to save the changes Internet scan results
Internet scans were performed using a modified version of zgrab, by obtaining and immediately using a Session Ticket with a 31-byte Session ID.Alexa top 1m Vulnerable Accepted Rejected Top 1k 3 449 50 Top 10k 15 4277 310 100k 102 43925 1764 All 949 466275 18702 Cisco Umbrella top 1m Vulnerable Accepted Rejected Top 1k 1 441 52 Top 10k 20 4224 611 100k 255 45498 4739 All 1602 431652 32695
Vulnerable means the host replied with unexpected memory, Accepted means that the host correctly accepted the Session Ticket, Rejected means the host offered a Session Ticket but then rejected it when the client tried to use it. All remaining hosts didn't offer Session Tickets.
All wide scans originated from IP address 126.96.36.199. I'd like to thank BHost for offering the stable VPS and the bandwidth necessary to perform the scan, and for taking care of the inbound abuse letters.Detection and IDS
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.Discovery and timeline
The issue was identified by Filippo Valsorda of the Cloudflare Crypto Team in collaboration with other Cloudflare employees, while debugging a customer issue. You can readthe full story on the Filippo.io blog.
It was reported on October 26, 2016 and subject to a 90 + 15 days disclosure policy . I'd like to thank the F5 SIRT for their professionalism, transparency and collaboration.October 20 ― issue identified October 20 ― first attempt at contacting F5 October 25 ― contact established with F5 Security Engineer October 26 ― report submitted October 28 ― report acknowledged by F5 November 13 ― issue confirmed by F5, security impact yet unconfirmed November 14 ― Alexa top 1000 scan reveals two vulnerable hosts, 90 days deadline issued November 16 ― version and configuration details provided to F5 November 16 ― security issue reproduced and confirmed by F5 F5 shares release timeline, a series of back and forth sets disclosure for the day of the first HotFix release in late January January 17 ― F5 shares CVE and K article draft January 26 ― release pushed back to February 8 due to issues February 7 ― Internet scan from 188.8.131.52 February 8 ― last day within disclosure policy February 8 ― release delayed February 9 01:25 UTC ― coordinated public disclosure
Logo based on Ticket by Diego Naive from the Noun Project.