"OpenSSL-kwetsbaarheden ongeschikt voor grootschalig misbruik"
De kwetsbaarheden in OpenSSL waarvoor gisteren een beveiligingsupdate verscheen zijn ongeschikt voor grootschalig misbruik, zo stellen verschillende securitybedrijven. Pas als er aan verschillende voorwaarden is voldaan kan een aanval plaatsvinden.
OpenSSL behoort tot de meestgebruikte software voor het versleutelen van internetverbindingen. Websites maken er bijvoorbeeld gebruik van om het verkeer van en naar bezoekers te versleutelen, maar het wordt ook binnen allerlei applicaties gebruikt. Kwetsbaarheden in de software kunnen grote gevolgen hebben, zoals de Heartbleed-bug uit 2014 aantoonde.
De twee verholpen beveiligingslekken, CVE-2022-3602 en CVE-2022-3786, bevinden zich in de code van OpenSSL die verantwoordelijk is voor de verificatie van X.509-certificaten. Deze code wordt meestal op een client uitgevoerd die zich bij een server wil authenticeren en het certificaat gepresenteerd krijgt. Om misbruik van de kwetsbaarheden te maken zou een certificaatautoriteit, vertrouwd door het slachtoffer, een malafide certificaat moeten hebben gesigneerd.
Het slachtoffer moet vervolgens het malafide certificaat valideren of een aantal waarschuwingen van de browser negeren. Daarnaast moet er gebruik worden gemaakt van OpenSSL 3.0.x tot en met 3.0.6. Een eindgebruiker zou bijvoorbeeld risico lopen wanneer hij een malafide website bezoekt die een certificaat met een exploit aanbiedt. Dit certificaat moet door een certificaatautoriteit zijn gesigneerd.
Om een server aan te vallen zou die wederzijdse authenticatie moeten ondersteunen. Hierbij bieden zowel de client als de server een geldig en gesigneerd X.509-certificaat aan. De client biedt dan een malafide certificaat aan, legt internetbedrijf Cloudflare uit. Dit is een ongebruikelijke configuratie, stelt securitybedrijf Rapid7.
In het geval van een aanval op de browser of e-mailclient van een eindgebruiker zou de aanvaller het slachtoffer eerst verbinding met een malafide server moeten laten maken. Bijvoorbeeld door een man-in-the-middle-aanval of een phishinglink. "In beide gevallen zijn deze aanvallen niet goed geschikt voor grootschalig misbruik", aldus Rapid7, doelend op zowel de client- als server-aanval. Securitybedrijf Censys stelt dat de kans op misbruik bij een eindgebruiker groter is dan bij een server, gezien de ongewone setup die bij de laatste is vereist.
een certificaataanvraag te valideren, en dan te volgen welke uitgevers zich daar niet aan houden en hun (root)certificaten
intrekken.
Ik kreeg OpenSSL versie 3 vandaag binnen op Linux Ubuntu 22.04 LTS via de gewone update-functie.
Leuker kunnen we het niet maken,wel makkelijker
Pater analoog
een certificaataanvraag te valideren, en dan te volgen welke uitgevers zich daar niet aan houden en hun (root)certificaten
intrekken.
Zo makkelijk is het niet in de praktijk. Wat een certificate authority ondertekent is niet het certificaat, maar een cryptografische hash van een certificaat. Een hash is niet meer als een heel lang getal.
Als een certificate authority bij ondertekening kan controleren op een overflow in het certificaat, dan kan je browser dat ook. Waar de controle ook thuis hoort.
Bovendien zullen certificaat authorities ook iets als de OpenSSL library gebruiken, dus zijn ze zelf ook kwetsbaar voor aanvallen die nog niet bekend zijn. Zo vaak komt zo'n lek niet voor. Dit is de tweede keer sinds het bestaan van OpenSSL. Ga daar geen nieuwe procedures voor optuigen.
Ik kreeg OpenSSL versie 3 vandaag binnen op Linux Ubuntu 22.04 LTS via de gewone update-functie.
Tja, dan kunnen we stoppen met het gebruik van software in het algemeen omdat overal wel een kwetsbaarheid in zit. Het is ook onzin om te denken dat kwetsbaarheden te voorkomen zijn want wat nu niet kwetsbaar is kan dat volgende week wel ineens zijn. Belangrijk is ook een juiste analyse te hebben hoe gemakkelijk een kwetsbaarheid is te misbruiken en daar mankeert imho wel het nodig aan. Er wordt soms paniek gemaakt over kwetsbaarheden die pas te misbruiken zijn wanneer er fysieke toegang tot een server is. Maar als deze fysieke toegang er al is heb je een dergelijke kwetsbaarheid helemaal niet meer nodig.
Deze OpenSSL kwetsbaarheid hoort in feite ook een beetje in dat rijtje thuis want Openssl 3.x wordt nog nauwelijks gebruikt en om het te kunnen misbruiken moet je toch wel iets meer doen dan alleen een scriptje draaien.
Via phishing zou je nog wel een eind kunnen komen maar ook dat is lastig om een fake certificaat te laten trusten en om vervolgens dezelfde gebruiker er zich ergens ermee te laten valideren.
Kortom, wederom een storm in een glas water maar er zijn weer een hoop 'adviseurs' die er weer flink aan verdiend hebben.
een certificaataanvraag te valideren, en dan te volgen welke uitgevers zich daar niet aan houden en hun (root)certificaten
intrekken.
Zo makkelijk is het niet in de praktijk. Wat een certificate authority ondertekent is niet het certificaat, maar een cryptografische hash van een certificaat. Een hash is niet meer als een heel lang getal.
Nee een certificate authority krijgt alle velden van het certificaat onder ogen, anders weten ze niet wat ze goedkeuren.
Je bent denk ik in de war met de situatie dat een certificate authority niet je secret key te zien hoeft te krijgen.
(als je zelf een signing request maakt en laat signen, dus niet door hen het hele certificaat laten maken en opsturen als
gesigned certificaat+key, wat je tegenwoordig vaak voorgeschoteld krijgt)
Dat is ook een plek waar het gecontroleerd moet worden, maar het aantal certificate authorities is veel kleiner dan
het aantal gebruikers, dus alvast checken bij de bron kan nooit kwaad. Dat blijkt nu maar weer eens.
Deze OpenSSL kwetsbaarheid hoort in feite ook een beetje in dat rijtje thuis want Openssl 3.x wordt nog nauwelijks gebruikt en om het te kunnen misbruiken moet je toch wel iets meer doen dan alleen een scriptje draaien.
Nou dat is zeker iets wat in dit geval helemaal fout gegaan is! Er was een buffer overflow en die buffer staat in de
stack dus is er meteen moord en brand geroepen, maar eerst even kijken hoe ver die buffer dan overflowed kan worden
en wat er dan zou kunnen gebeuren (crash of mogelijke remote code execution) dat had in een dergelijke high-profile
situatie geen kwaad gekund. Je zag ook dat er zat deskundigen waren die dit wel konden en aangaven dat het in
werkelijkheid niet echt een belangrijk probleem was, maar die indicaties zijn niet voortijdig gepubliceerd.
Een dure les, want geloofwaardigheid is in het geding en is nu aangetast.
Nee een certificate authority krijgt alle velden van het certificaat onder ogen, anders weten ze niet wat ze goedkeuren.
Je bent denk ik in de war met de situatie dat een certificate authority niet je secret key te zien hoeft te krijgen.
(als je zelf een signing request maakt en laat signen, dus niet door hen het hele certificaat laten maken en opsturen als
gesigned certificaat+key, wat je tegenwoordig vaak voorgeschoteld krijgt)
In principe hoeft de certificate authority geen publieke key van elke website te bewaren. Het is niet zo dat als je een website bezoekt, dat je dan bij de root certificate authority de public key ophaalt. De public key van de root certificate authority zit al in de browser dus ze hoeven helemaal niets ter download aan te bieden.
Alleen certificaten ondertekenen met hun root certificaat. Dat is alles. Lekker simpel en dus veilig.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
