Ticketbleed-kwetsbaarheid laat aanvaller geheugen F5-apparaten uitlezen

Filippo Valsorda, beveiligingsonderzoeker bij Cloudflare, heeft een lek in verschillende apparaten van fabrikant F5 Networks ontdekt, waarmee het op afstand uitlezen van geheugen mogelijk is. Daarmee lijkt de kwetsbaarheid enigszins op het Heartbleed-lek in OpenSSL.

Valsorda heeft zijn bevindingen gedetailleerd beschreven in een blogpost. Daarnaast is een speciale website aan het lek gewijd, zoals in het verleden bij andere kwetsbaarheden het geval was. Het lek treft de BIG-IP-lijn van F5-apparatuur, die de taken vervult van load balancer en proxy. Het is aanwezig in de tls-stack van de apparatuur en stelt een aanvaller in staat om steeds 31 bytes aan geheugen uit te lezen. Daardoor is het bijvoorbeeld mogelijk om gevoelige informatie te achterhalen, zoals session id's van andere sessies.

Volgens F5 zelf gaat het om tien kwetsbare apparaten uit de BIG-IP-lijn; een overzicht is te vinden op de website van de fabrikant. Er zijn inmiddels patches voor de getroffen apparaten beschikbaar. Het lek heeft te maken met de implementatie van session tickets en werkt doordat een aanvaller een session id van 1 byte kan versturen, waarop de server een antwoord van 31 byte aan niet-geïnitialiseerd geheugen terugstuurt in plaats van een session-id.

Een scan naar kwetsbare servers van Valsorda laat zien dat er in de duizend populairste sites volgens Alexa drie lekke apparaten te vinden zijn. In de honderdduizend populairste websites stijgt het aantal naar 102. Het installeren van een patch is de beste oplossing. Het uitschakelen van session tickets verhelpt het probleem eveneens, maar leidt tot verminderde prestaties.

Reacties (27)

"Session Ticket
Enables or disables the use of session ticket per RFC 5077. By default, this setting is disabled, which causes the system not to use session tickets."

Deze optie staat dus niet aan by default.

Bovendien zijn session tickets al wel langer een vulnerability geweest op andere implementaties en hebben de meeste test en audits ook checks voor session tickets zodat mensen die het toch aan hebben gezet bij een controle in elk geval gemeld krijgen dat dat vaak niet zo'n goed plan is.

Sterk dat ze, in tegenstelling tot sommige andere partijen, wel direct reageren met een patch die dit oplost. Nu de patch nog installeren natuurlijk, maar ik hoor/lees vaak genoeg dat het eindeloos duurt voordat een gemeld lek gedicht wordt.

Direct is relatief; In de blog heeft hij het erover dat het 90-105 dagen kostte voordat er een patch was. En dat het vrij veel moeite was om met ze in contact te komen.

Klopt, de tijdslijn is als volgt:

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 185.47.61.3
February 8 — last day within disclosure policy
February 8 — release delayed
February 9 01:25 UTC — coordinated public disclosure

Thanks, ik had allicht iets verder moeten kijken dan het t.net artikel

Op basis van dit artikel kan ik niet echt inschatten of dit een big-deal is of niet

Het is een lek van 31 bytes, waar als het goed is al een patch voor is zodat dit niet meer lukt.
Je kunt door dit probleem dus 31 bytes per aanvraag terug krijgen uit het RAM. Hierin kan gevoelige informatie staan.
Ik heb zelf nog niet eerder over F5 Networks gehoord, dus de impact is beperkter dan hearthbleed

F5 is 1 van dé grote spelers op het gebied van load balancing en proxy systemen. Ik denk dat 40% van de datacenters of grote bedrijven wel ergens spullen van F5 hebbens taan, dus onderschat het niet.

Staat in de tekst dat het ca 1 promille is. Big deal dus, helemaal omdat er al een patch is. (LET OP: Sarcastisch)
(Zeker als je het vergelijkt met de miljarden lekke smartphones....)

misschien hadden ze dat in de tekst kunnen opnemen. Ik heb zelf niet met dit soort producten te maken en had dus geen idee wat ik me bij F5 moest voorstellen.

Daarnaast, tja: ongeveer alles gaat qua impact (als in % getroffen systemen van totaal) kleiner zijn dan heartbleed was

F5 is een van de grootste fabrikanten van load balancers en security er omheen. Geen kleine speler.

Grote kans dat jouw bericht over dat je niet eerder van F5 had gehoord door meerdere F5 appliances is gegaan voordat het hier stond :-)

Patches voor lopende (ondersteunde) versies zijn helemaal nog niet beschikbaar. Daarvoor moet je (voor BIGIP) toch echt upgraden naar 11.6.1 HF2. Waarbij ik moet zeggen dat die via de downloadportal nog nergens is te vinden.

[Reactie gewijzigd door ed1703 op 9 februari 2017 13:17]

Inderdaad best upgraden binnen dezelfde supported branch om weer een hoop andere regressies te vermijden.

Ik (wij) zitten bewust nog op 11.5.4 HF2 vanwege rare dingen in 11.6
Gelukkig is het een default off setting.

Same here 11.5.4 HF2.

Kak, dat word weer overwerken. Kan ik weer alle klanten langs

Inventariseren of een van deze klanten uberhaupt gebruik maakt van session tickets, anders is er niets aan de hand. Ook is er geen echte fix op dit moment anders dan updaten maar dit heeft vaak andere complicaties of onverwachte gedragingen.

Het is niet omdat een klant deze functie niet gebruikt dat je niet moet patchen. Wij maken hier zelf ook geen gebruik van maar ben toch begonnen met deze patch.
Binnen x aantal maand kan het zijn dat het ons toch plots een goed idee lijkt om die functie te gebruiken, dan is de kans groot dat we al lang vergeten zijn dat dit issue gepasseerd is.

@Zjemm: je hebt de juiste reflex!

[Reactie gewijzigd door DolphShaft op 9 februari 2017 14:35]

In dit geval zou ik, wanneer je deze feature niet enabled hebt, wachten op een nieuwe HF voor dezelfde maintenance release als die er nog niet is. Blind upgraden naar een nieuwe minor (bv. van 11.5 naar 11.6) of major (bv. van 11.5 naar 12.0) release heeft me in het verleden al veel te veel ellende opgeleverd.

Heb het zelfde. Gelukkig redelijk snel te controleren. Via de CLI inloggen en de config van client-SSL oproepen. Als je dit via CRT doet, kan je gelijk zoeken op session-ticket.

Zoiets dan om snel te checken of het nergens enabled staat:

"tmsh list ltm profile client-ssl all | grep -i session-ticket"

Hoezo langs? Bij onze klanten wordt dat gewoon vanuit India gedaan.

Iets met persoonlijk contact

Ik voorzie een hoop werk morgen!