OpenSSL dicht kwetsbaarheid die denial-of-serviceaanval mogelijk maakte

OpenSSL heeft twee ernstige kwetsbaarheden verholpen, een waarmee denial-of-serviceaanvallen uit te voeren waren en een andere die tot spoofing kon leiden. Er is proof-of-concept-exploitcode ontwikkeld die de mogelijkheid tot misbruik heeft aangetoond.

De kwetsbaarheden betreffen OpenSSL-versies 1.1.1h en latere versies, en zijn verholpen in de recentste versie, 1.1.1k. In OpenSSL 1.0.2 zijn ze niet aanwezig. CVE-2021-3449 is de denial-of-servicekwetsbaarheid. Servers die OpenSSL gebruiken met de standaardconfiguratie om gebruik te maken van TLSv1.2 in combinatie met renegotiation, zijn kwetsbaar. Clients kunnen die systemen een malafide renegotiation ClientHello-bericht sturen om de server te laten crashen.

Kwetsbaarheid CVE-2021-3450 maakt het mogelijk dat een server of client een kwaadaardig certificaat accepteert door bepaalde verificatie te omzeilen. Deze spoofingkwetsbaarheid is echter niet standaard aanwezig, alleen als een bepaalde X509-flag actief is.

OpenSSL geeft details over de kwetsbaarheden en de fixes die zijn doorgevoerd. Debian, FreeBSD, OpenSUSE, SUSE en Ubuntu hebben updates beschikbaar gesteld. Het Nationaal Cyber Security Centrum acht de kans op misbruik en schade hoog, hoewel misbruik in de praktijk nog niet is geconstateerd en er alleen een proof-of-concept voor misbruik is ontwikkeld.

Reacties (21)

Wat ik uit het artikel even niet begrijp:

Servers die OpenSSL gebruiken met de standaardconfiguratie om gebruik te maken van TLSv1.2 in combinatie met renegotiation, zijn kwetsbaar

Zijn nu alle standaard geïnstalleerde en geconfigureerde OpenSSL systemen kwetsbaar of moet de admin ook de renegotiation handmatig hebben aangezet?

Je hebt secure renegotiation en je hebt het oude insecure renegotiation. Daarnaast heb je client-side initiated renegotiation (voor zowel secure als insecure) en je hebt server-side initiated renegotiation (ook voor zowel secure als insecure). Client-side kan je uitzetten. Dat wil je omdat een renegotiation CPU-tijd vraagt en als je dat als client achter elkaar blijft aanvragen, dan belast je de server. Bij een teveel krijg je dus een DoS.

Renegotiation is een nuttige feature. Helemaal uitzetten wil je dus niet. Om die reden kan je server-side initiated renegotiation niet uitzetten.

Wat betreft de huidige kwetsbaarheid zit de fout in client-side initiated secure renegotiation. Echter, uitzetten verhelpt het probleem niet. Je kan namelijk niet voorkomen dat een client een verzoek tot renegotiation doet. Je kan wel voorkomen dat een server zo'n verzoek accepteert en er dus mee aan de slag gaat. Tests wijzen uit dat de bug zit in het deel van de code dat het verzoek ontvangt. Accepteren en afhandelen is dus niet eens nodig om de kwetsbaarheid te misbruiken!

Het enige dat helpt is secure renegotiation in z'n geheel uitzetten. Wat dan overblijft is het oude insecure renegotiation. Echter, die oude renegotiation methode is insecure, want... padam padam... bevat fouten waarmee je de server kan DoS-en. Precies wat nu dus ook met het secure renegotiation mogelijk is. Dus, geen oplossing. Enige dat overblijft is wachten op een patch.

Wat handig hierbij is, is dat een TLS handshake na de TCP handshake komt. Er valt op IP niveau dus niks te spoofen. Met andere woorden, je kan mogelijk in je logfiles het IP adres vinden van diegene die je server liet crashen. Hangt natuurlijk wel af van wanneer de bewuste daemon logt. Direct na connectie of pas aan het einde van het afhandelen van het daadwerkelijke request. Dat eerste is goed, in dat laatste geval komt het loggen te laat (server waarschijnlijk al gecrasht).

[Reactie gewijzigd door Faeron op 26 maart 2021 15:09]

Wat hanidg hierbij is, is dat een TLS handshake na de TCP handshake komt.

bij ssh tcpwrappers gebruiken maakt dat dan hoogstens van bekende gebruikers de overlast komt

Ik weet niet wat je precies met ssh tcpwrapper bedoeld, maar SSH gebruikt geen TLS.

[Reactie gewijzigd door Faeron op 26 maart 2021 15:09]

klopt 100%, ik zat al verder te denken dat DOS alleen, ldap, sendmail submit etc zijn dan weer betere voorbeelden.

Brr, is openvpn ook geraakt ?

[Reactie gewijzigd door tweazer op 26 maart 2021 15:34]

Ik denk het niet, want ook OpenVPN gebruikt voor zover ik weet geen TLS.

OpenVPN kan TLS gebruiken voor packet authentication. Standaard staat dat op OpnSense, pfSense, OpenVPN-AS enz. ook aan.

Dank voor de heldere uitleg!

Als ik het goed begrijp van de PoC - alle standaard systemen uitgezonderd openhttpd en Nginx met de getroffen versies.

Ja... Bij nginx is renegotiation uitgeschakeld sinds eind 2009 en dus niet vulnerable.

[Reactie gewijzigd door AntoonH op 27 maart 2021 17:46]

Ik zou het lekker bij de originele Engelse tekst houden in plaats van vertalingen, zeker in dit soort gevallen:

A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration).

Zie: https://www.openssl.org/news/secadv/20210325.txt

Hmmmm... Dus een rogue toevoeging aan de Hello handshake door middel van het misbruik van SSL_check_chain welke uiteindelijk leid tot segmentation fault (SIGSESV), maar niet in servers lager dan OpenSSL 1.1.1d of hoger dan 1.1.1f of Apache openhttpd en Nginx.

Doet bij mij de vraag opkomen wat deze exploit geïntroduceerd of veroorzaakt heeft..

Ik lees nergens dat het om 'rogue' (opzettelijk foute) toevoeging zou gaan of dat er exploits zijn.

Er zijn twee verschillende kwetsbaarheden. In het artikel staan daar ook twee verschillende verwijzingen naar. Bij een van de kwetsbaarheden staat dat er een fout in de implementatie is gemaakt. Bij de ander staat geen directe uitleg maar wel prima verwijzingen naar de code en inzicht in wijzigingen.

Hoe het kan dat er ondanks controle fouten in code ontstaan is altijd een goede vraag, maar gezien de complexiteit en de hoeveelheid fouten die er zelfs met controle nog gemaakt worden vraag ik me af of je er niet beter rekening mee kan houden dat er hoe dan ook fouten in zullen zitten.

Rogue in de zin dat de client handshake gemanipuleerd wordt - signature_algorithms wordt bij de Hello handshake verwijderd en signature_algorithms_cert toegevoegd waardoor de server op zoek gaat naar een niet-bestaande referentie (als ik het goed volg) omdat een gedeelte van de handshake wordt aangesproken welke (nog) niet bestaat.

Voor de rest - mee eens.

Ik denk dat dit Twitter draadje enig inzicht geeft:

https://twitter.com/FiloSottile/status/1375088352421163012

Bedankt. Dat verduidelijkt het wel iets. Een ‘foutje bedankt’ patch in dit opzicht dus - fix de ene vulnerability en veroorzaak onbedoeld de ander.

Kan iemand uitleggen wat je nu precies kan doen met CVE-2021-3450? Wat wordt er gespoofd? Kan dit gebruikt worden om de desbetreffende server te breachen?

Je kan het misbruiken om een man in the middle aanval uit te voeren. Je moet daarvoor wel het lokale verkeer kunnen onderscheppen. Je kan tijdens de SSL handshake je eigen server-certificaat er tussen fietsen en als je dat dus op de juiste manier doet (de kwetsbaarheid uitbuit), dan gelooft de client dat jou nep-certificaat echt is. Je kan vervolgens al het verdere verkeer inzien of veranderen zonder dat iemand het door heeft.

[Reactie gewijzigd door Faeron op 26 maart 2021 14:40]

Dit soort CVE's is de reden waarom je IoT devices op een gastnetwerk wil houden.

Je zal maar net een apparaat in je netwerk hebben dat OpenSSL 1..1.1h heeft en dat niet of zeer onregelmatig gepatcht wordt.

Ik vind je nog redelijk optimistisch. Genoeg zooi waar je met een moderne browser niet op in kunt loggen omdat de TLS versie verouderd is en als je dat vervolgens omzeilt lukt het nog steeds niet omdat de Javascript voor IE6 geschreven is.

Gisteren al de update uitgerold.

Edit: het ging hier om een Windows server. Dus dat betekende OpenSSL compileren, Apache hercompileren en alle PHP-versies hercompileren. Zie https://www.apachelounge.com/viewtopic.php?t=6359

[Reactie gewijzigd door Jan-E op 26 maart 2021 16:14]