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.
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.
*Note: there exist implementations other than F5 that exhibit a similar bug which might not have security implications.
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.
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.
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|
|Cisco Umbrella top 1m|
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.
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.
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 read the 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.
Logo based on Ticket by Diego Naive from the Noun Project.