image

Ernstig lek in SSL-protocol ontdekt

donderdag 5 november 2009, 17:42 door Redactie, 7 reacties

Onderzoekers hebben een ernstig beveiligingslek in het SSL-protocol ontdekt, waardoor aanvallers in bepaalde gevallen servers in shared hosting omgevingen, mailservers, databases en talloze andere beveiligde applicaties kunnen hacken. Secure Sockets Layer (SSL) wordt gebruikt voor het versleutelen van dataverkeer, waardoor het tijdens het vervoer via internet niet is af te luisteren. De kwetsbaarheid zorgt ervoor dat aanvallers via een man-in-the-middle aanval het verkeer wel kunnen onderscheppen.

In werkelijkheid gaat het om een ontwerpfout in het TLS protocol bij het opnieuw uitwisselen van parameters voor een bestaande TLS-verbinding. Dit doet zich bijvoorbeeld voor als een client een beveiligd deel van een webserver benadert, die de certificaten van de langskomende client vereist. Is dit het geval, dan zal de server om het juiste certificaat vragen. Tijdens deze uitwisseling wordt de originele aanvraag opnieuw afgespeeld alsof die al door het client certificaat is geauthenticeerd, terwijl dit niet het geval is.

Man in the middle
"Na wat eigen tests kunnen we bevestigen dat het lek bestaat en voor de meesten een behoorlijke dreiging vormt", zegt de Luxemburgse beveiligingsonderzoeker Thierry Zoller. Een aanvaller zou het lek kunnen misbruiken door tussen de verbinding van de client en de server te gaan zitten en een HTTPS verbinding met de server op te zetten. Vervolgens houdt hij de verbinding met de client in een onvolledige staat. De server krijgt vervolgens een verzoek voor een beveiligd gedeelte, waarop de server een compleet nieuwe verbinding opzet en het client certificaat vraagt. De aanvaller stuurt alle pakketjes onveranderd tussen de client en server door. Uiteindelijk wordt het HTTP request van de aanvaller, bijvoorbeeld voor een beveiligd gedeelte, uitgevoerd alsof het van de client komt.

Consortium
Het probleem werd in augustus door onderzoekers van PhoneFactor ontdekt, een bedrijf dat beveiliging voor mobiele telefoons doet. Achter de schermen werkte het bedrijf al twee maanden samen met een consortium van leveranciers genaamd ICASI (Industry Consortium for Advancement of Security on the Internet) om een industriebrede oplossing voor het probleem uit te brengen, genaamd “Project Mogul."

SAP engineer Martin Rex gooide roet in het eten, toen hij gisteren hetzelfde lek ontdekte. Rex was zich niet bewust van de gevolgen en plaatste zijn ontdekking op de IETF (Internet Engineering Task Force) mailinglist. Uiteindelijk besloot ook PhoneFactor met hun ontdekking publiekelijk te gaan. Het is nog steeds onbekend wanneer een update beschikbaar is.

De kwetsbaarheid is aanwezig in de laatste versies van Microsoft IIS en Apache Foundation httpd web servers, en ook OpenSSL is kwetsbaar. Inmiddels heeft onderzoeker Ben Laurie een patch ontwikkeld, maar die stopt alleen het opnieuw uitwisselen en lost niet het onderliggende probleem op. Een oplossing voor lange termijn wordt inmiddels besproken. Een mogelijkheid zou kunnen zijn om de client certificaten eerder uit te wisselen voordat een specifieke URL wordt opgevraagd.

Vergaande gevolgen
De gevolgen van het lek raken niet alleen HTTP. "Wat denk je van SQL? Een aanvaller die de mogelijkheid heeft om een enkel request van willekeurige lengte te injecteren in een stroom van SQL queries en responses kan vernietigend zijn." Daarnaast zijn er nog duizenden verschillende software update mechanismen die van SSL afhankelijk zijn om op een veilige manier te functioneren. "Er moet voor dit lek van alles worden gefixt: Web browsers, Web servers, Web load balancers, Web accelerators, mailservers, SQL Servers, ODBC drivers en peer-to-peer protocollen", aldus onderzoeker Chris Paget.

Volgens hem is dit "een bug die ons nog lang zal achtervolgen." Hij verwacht dat er tools verschijnen die dit lek over een groot aantal protocollen en apparaten zullen misbruiken. Het heeft dan ook vergaande gevolgen voor de beveiliging van talloze systemen, zo merkt hij op. "Iedereen die zegt dat dit geen probleem is, begrijpt het niet." Paget noemt het geen gigantisch probleem voor HTTP, hoewel hij er rekening mee houdt dat dit wel kan gebeuren. "Maar er is veel meer dat door SSL wordt beschermd dan alleen HTTP."

Reacties (7)
05-11-2009, 18:10 door Anoniem
Wat ik altijd vreemd is hoe dik mensen dingen moeten aanzetten om hun geloofwaardigheid te onderbouwen.

Dat je in een lab opstelling ALLE en ten ALLE tijden A-symetirische encryptie kunt onderscheppen en een man-in-the-middle attack kunt laten plaatsvinden is niet zo bijzonder.

Het gaat erom welke risico's het in de praktijk met zich mee kan brengen, en die is verwaarloosbaar. Tenzij je Osama Bin Laden heet en SSL gebruikt.

De condities waaraan je moet voldoen om een dergelijke attack succesvol en zonder detectie te kunnen uitvoeren, maakt het vele malen eenvoudiger om gewoon client of server te hacken.

Maar goed, misschien snap ik de ernst niet.
05-11-2009, 22:46 door fubar
Als deze security issue inderdaad klopt is de reikwijdte enorm. Dat betekent dat we een flinke hoeveelheid werk op ons af gaan krijgen om dit te patchen. Waarbij het nog maar de vraag is hoe snel patches beschikbaar komen... Wel typisch dat men hier dus al maanden van weet en blijkbaar nog heel veel partijen geen fix hebben of op de hoogte zijn gebracht...
05-11-2009, 23:11 door Bitwiper
Redactie schreef: "De kwetsbaarheid zorgt ervoor dat aanvallers via een man-in-the-middle aanval het verkeer wel kunnen onderscheppen " - dat is, voor zover ik het nu begrijp, nauwelijks het geval, wat niet wegneemt dat aanvallers er ongetwijfeld handig gebruik van zullen kunnen maken.

Eric Rescorla werkt aan een IETF Internet-Draft waarin hij de aanval en een oplossing beschrijft (de huidige conceptversie heb ik hier opgehaald: https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt). Meer gedetailleerde PDF's van de oorspronkelijke ontdekkers van deze kwetsbaarheid (Marsh Ray en Steve Dispensa van PhoneFactor) vind je hier: http://extendedsubset.com/?p=8.

Een aanvaller (die noem ik hieronder steeds MITM) moet zich als man-in-the-middle in de "kabel" (WiFi mag natuurlijk ook) tussen de client en de server kunnen nestelen (bijv. via een ARP-spoofing attack). Dan wacht de MITM tot de client een SSL of TLS connectie opzet naar een server (dit is een "gewone" TLS/SSL verbinding, d.w.z. zonder client certificaat):

client --- MITM --- server

(1) de client probeert een TLS verbinding te starten (client ---> MITM)
(2) de MITM ontvangt en bewaart deze request, maar stuurt hem nu nog niet door
(3) in plaats daavan zet de MITM zelf een nieuwe TLS/SSL verbinding op met de server (MITM ---> server)
(4) de MITM kan nu vanalles doen (lees voorbereiden) op de server, via zijn verbinding (MITM <---> server)
(5) zodra de aanval voldoende is voorbereid stuurt de MITM de TLS setup-request van de client uit stap 1 waadoor de server denkt dat de client een renegotiation wil starten (MITM ---> server)
(6) als ik Ivan Ristic goed begrijp (zie http://blog.ivanristic.com/2009/11/ssl-and-tls-authentication-gap-vulnerability-discovered.html) zou het ergens net vóór of net na 5 mogelijk moeten zijn om in een http get request van de client het /path/to/resource te wijzigen, waardoor de client een ander antwoord krijgt - echter pas in stap 9 (MITM ---> server)
(7) de rest van de TSL/SSL handshake tussen de client en de server laat de MITM ongemoeid door (client <-----------> server)
(8) zodra de sessie tussen de client en de server is opgezet ziet de MITM alleen nog versleuteld verkeer voorbij komen
(9) het eerste dat de client (onleesbaar voor de MITM) komt is een antwoord op iets dat de client niet gevraagd heeft, maar wat in sommige specifieke aanvallen wel van pas kan komen

Kortom, de client wil sessie 1 starten maar wordt geblokkeerd. De MITM start zelf sessie 2. Na de gewenste voorbereidingen laat de MITM sessie 2 via renegotiation alsnog overgaan in sessie 1. De server weet niet beter dan dat de verbinding steeds met dezelfde client heeft plaatsgevonden.

Iets vergelijkbaars speelt in het geval van client certificaten, waarbij het uitgangspunt is dat de MITM eerst zaken op de server kan doen mits die server daarvoor nog niet om het client certificaat vraagt. Ook dan kan de MITM zijn aanval eerst voorbereiden en vervolgens de bestaande https sessie laten overnemen door de client waarna die client zich authenticeert middels een client certificaat (ik vermoed dat er dan laatste request meer gedaan kan worden zoals in stap 6). Het punt hierbij is dat de server niet weet dat deze halverwege met een andere client praat, waardoor deze met terugwerkende kracht de door de MITM uitgevoerde handelingen aan de client kan toeschrijven.

Het bovenstaande is onder voorbehoud, het is wat complexe materie en de experts laten mogelijk nog niet het achterste van hun tong zien. Voor zover ik het begrijp is het enige verkeer dat tussen de client en de server onversleuteld (inzichtelijk en te wijzigen door de MITM) over het lijntje gaat één enkele http get request. Wachtwoorden e.d. krijgt de aanvaller in principe niet te zien (tenzij er sprake is van aanvullende bugs).

Desalniettemin moet deze flaw niet worden onderschat, ongetwijfeld kan deze in heel specifieke gevallen worden uitgebuit, maar misschien ook wel in heel algemene. Op de blog van Ben Laurie (zie http://www.links.org/?p=780) merkt ene joat op: "Isnt renegotiation how ISA works when used as a front-end for OWA?"
06-11-2009, 01:22 door Anoniem
@Bitwiper: hartelijk dank voor je samenvatting
06-11-2009, 08:33 door Anoniem
Dus als ik het goed begrijp is op dit moment de enige fix de renegotiation uit het protocol te slopen.
Wat heeft dit voor gevolgen voor bestaande software? Hoe intensief wordt deze renegotiation functionaliteit
van het protocol toegepast in bestaande software?
06-11-2009, 10:44 door Anoniem
ssh is ook veiliger dan,ssl.
Vandaar dat vaker ssh wordt gebruikt dan ssl.
06-11-2009, 11:52 door Bitwiper
Door Anoniem: @Bitwiper: hartelijk dank voor je samenvatting
Graag gedaan!

Door Anoniem: Dus als ik het goed begrijp is op dit moment de enige fix de renegotiation uit het protocol te slopen.
Wat heeft dit voor gevolgen voor bestaande software? Hoe intensief wordt deze renegotiation functionaliteit
van het protocol toegepast in bestaande software?
Voorbeelden, zie https://bugzilla.redhat.com/show_bug.cgi?id=533125#c4: mod_ssl en PostgreSQL.

Interessant is ook de bijdrage van Florian Weimer op de ietf tls maillijst (http://www.ietf.org/mail-archive/web/tls/current/msg03972.html, waarin hij eerlijk toegeeft:

"I've written web applications which use an server-internal atemporal request to access future authentication information. While that might seem naive in retrospect, it was the recommended way of adding client certificate authentication without introducing additional round-trips, so I'm probably not the only one who did that".

Als je dat combineert met de melding op de redhat lijst m.b.t. mod_ssl dan is dit wel degelijk een issue:

"Server-initiated renegotiations are commonly needed in setups where client certificate authentication is required for some parts of the web site, but not for the whole site, or when different cipher suites are required for different parts of the site".

Door Anoniem: ssh is ook veiliger dan,ssl.
Oh? wel eens in je fw logs naar poort 22 gekeken? (Denk je dat je die meldingen zou zien als die niet een bepaalde successrate habben?) Volgens http://www.openssl.org/related/apps.html maakt OpenSSH gebruikt van OpenSSL libraries, maar deze kwetsbaarheid zou naar verluidt geen impact hebben op OpenSSL, zie http://djm.net.au/2009/11/6/ssh-is-not-vulnerable-to-the-ssl-tls-mitm-attack (bron: dezelfde redhat pagina als boven), dus in dit geval heb je toevallig wel gelijk ;)
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.