Ernstige ssl-bug is gepatcht en richt weinig schade aan

Een bug in OpenSSL zorgde ervoor dat een aanvaller met behulp van een legitiem ssl-certificaat valse ssl-certificaten kon genereren. De gevolgen van de bug zijn relatief beperkt: een klein aantal OpenSSL-versies is getroffen en geen enkele browser is vatbaar.

In tegenstelling tot bijvoorbeeld de roemruchte Heartbleed-bug zijn de gevolgen van het nieuwe beveiligingsprobleem, dat eerder deze week werd aangekondigd, beperkt. Zo is geen enkele grote webbrowser getroffen, aldus beveiligingsonderzoeker Filippo Valsorda. Het gaat enkel om servers die de meest recente OpenSSL-versie draaien.

Het probleem, waarbij valse ssl-certificaten kunnen worden uitgegeven, treft bijvoorbeeld wel servers die OpenSSL gebruiken voor het controleren van certificaten en vpn-servers. Er zijn echter maar vier recente OpenSSL-versies getroffen: gebruikers van 1.0.2b, 1.0.2c, 1.0.1n en 1.0.1o moeten updaten. Gebruikers van oudere versies waren niet kwetsbaar. De nieuwe versie is ongeveer een maand in omloop geweest; Ubuntu en Red Hat gebruiken oudere OpenSSL-versies en zijn dus niet vatbaar.

Het beveiligingsprobleem stelde een aanvaller in staat om valse ssl-certificaten te serveren. Dat kwam doordat systemen de 'vertrouwensketen' van ssl-certificaten in bepaalde gevallen niet goed controleerden. Daardoor kon een kwaadwillende met behulp van een normaal ssl-certificaat een vals certificaat genereren. Normaliter horen dergelijke certificaten niet te worden geaccepteerd, maar door de fout in OpenSSL werd dat niet opgemerkt. Daarvoor moest wel het ssl-certificaat worden gemanipuleerd.

Daardoor was een zogenoemd leaf-certificaat genoeg om bijvoorbeeld een certificaat voor Google.com uit te geven. Leaf-certificaten zijn certificaten die eindgebruikers afnemen voor bijvoorbeeld het versleutelen van een website; ze zijn niet bedoeld om zelf certificaten mee uit te geven.

Medewerkers van BoringSSL, Googles fork van OpenSSL, ontdekten de bug. Dat project heeft ook een patch gemaakt, die nu dus beschikbaar is. Nog niet bekend is of dat betekent dat de bug ook in BoringSSL zit; dat project neemt niet standaard alle wijzigingen in OpenSSL over. Het is eveneens onduidelijk of ook LibreSSL, een andere fork van OpenSSL waaraan het OpenBSD-project werkt, kwetsbaar is of was.

Reacties (51)

Het is eveneens onduidelijk of ook LibreSSL, een andere fork van OpenSSL waaraan het OpenBSD-project werkt, ook kwetsbaar is of was.

Nee, LibreSSL is dus niet vulnerable.

[Reactie gewijzigd door Eloy op 9 juli 2015 21:59]

Debian is ook niet lek... hooguit als je 'experimental' draait, maar dan vraag je er ook om.

Enterprise distro's zullen ook niet vaak een nog geen maand oude release hebben

Er zit ook een kwetsbare versie in stretch (de huidige testing) en SID. Maar ook daar geldt dat je die versies op eigne risico draait. Het wordt voornamelijk gedaan die mensen die beseffen dat ze regelmatig moeten patchen.

Er zit ook een kwetsbare versie in stretch (de huidige testing) en SID. Maar ook daar geldt dat je die versies op eigne risico draait.

Dat je dat op eigen risico draait heeft meer te maken met dat updates zo af en toe wel eens dingen willen veranderen of slopen. Het is over het algemeen niet zo dat een meer 'bleeding edge' distro of updatekanaal eerder securityproblemen heeft; integendeel juist.

Het wordt voornamelijk gedaan die mensen die beseffen dat ze regelmatig moeten patchen.

Dat moet je sowieso doen, of je nou CentOS (ultraconservatief) of Arch (ultra bleeding edge) draait. Een conservatieve distro draaien betekent dan wel dat je stokoude software draait waar je geen grote updates voor krijgt, maar security-updates krijg je altijd.

[Reactie gewijzigd door Compizfox op 10 juli 2015 03:15]

Je hebt helemaal gelijk, bij nader inzien was mijn post niet zo handig. In dit geval maakt het allemaal weinig verschil of je stable of unstable draait, patchen moet je toch en voor zo'n bug helemaal.

Ik probeerde aan te geven dat de meeste mensen die unstable draaien toch wel dagelijks patchen omdat ze weten dat de software minder getest is dan die in stable en er regelmatig grote bugs gevonden worden.

Dit is wel het type bug waarvoor je stable draait. Het is een recent geintroduceerde bug die er gelukkig ook weer snel uit is gehaald. Stable bevat alleen software die al een tijdje meegaat waardoor dit soort bugs er hopelijk uit zijn gehaald.

Volgens mij draai je zo'n beetje alles op eigen risico, maar goed

Debian is ook niet lek... hooguit als je 'experimental' draait, maar dan vraag je er ook om.

Enterprise distro's zullen ook niet vaak een nog geen maand oude release hebben

OpenSUSE ook niet, ook OpenSUSE Tumbleweed niet.

Debian testing heeft OpenSSL 1.0.2c en is dus ook lek.

Debian is ook niet lek... hooguit als je 'experimental' draait, maar dan vraag je er ook om.

Naja je vraagt er nooit om natuurlijk lol

Je gaat ermee akkoord dat het experimental is én dus dat het fouten kan bevatten waaronder deze. Dus nee, je vraagt er niet om, maar je doet er wel bewust aan mee

Op naar de volgende bug .. wel vervelend dat de mate van opkloperij van de impact steeds groter wordt.

Vervelend, op CentOS 6.6 zie ik nog geen update beschikbaar

[Reactie gewijzigd door WoBBeL op 9 juli 2015 21:11]

Vervelend, op opensuse 6.6 zie ik nog geen update beschikbaar

1) OpenSUSE 6.6 heeft nooit bestaan.
OpenSUSE 10.0 was de eerste openSUSE release.
Tevens heeft SuSE 6.6 ook nooit bestaan. Alleen 6.4 en 7.0
2) Als een distro release van 2000 een openSSL 1.0.1 of een 1.0.2 liepen ze flink voor.

Of was het een grapje?

Ik durf het niet te zeggen, maar ik bedoelde CentOS

Kijk eens naar het versienummer. Welke versie is nu geïnstalleerd?
In principe heeft CentOS 6.6 versie 1.0.1e, dus deze specifieke package hoeft alleen gepatcht te worden als ze de bug vorige maand hebben gebackport.

CentOS is niet kwetsbaar geweest. Dat staat ook in het artikel.
Tenzij je natuurlijk handmatig uit third party repo's OpenSSL update die wel de nieuwste versie er al in hadden gepropt... Zal je leren bleeding edge spul te draaien.

Heb ik net voor het uitkomen van het vorige bericht m'n Synology NAS bijgewerkt; uit de releasenotes (van 1 juli jl., DSM 5.2-5592):

quote: https://www.synology.com/nl-nl/releaseNote/DS215j

Upgraded OpenSSL to 1.0.1o to address multiple security vulnerabilities [...]

Vanwege de automatische update-functie, die weliswaar is uit te zetten, vermoed ik veel meer van dergelijke systemen die nu gevoelig zijn. Ben benieuwd hoe snel de ontwikkelaars bij Synology dit fixen.

[Reactie gewijzigd door Anoniem: 202103 op 9 juli 2015 16:39]

Hmm, dat was me nog niet opgevallen; hopelijk wordt het snel gefixt. Hoewel ik me niet kan voorstellen dat mensen mijn vakantiefotos (ikzelf in zwembroek) WILLEN hacken

Zo werkt het niet, denk aan een gewone inbrekers. Die zijn er niet op uit om jou te beroven. Ze kijken waar er een raam open staat en daar slaan ze hun slag. Of de buit interessant is en wat ze er mee doen weten ze pas na afloop. Zelfs als ze niks van waarde vinden dan is wel je hele huis een puinhoop.

Ook niet wanneer iemand zich als jou voor wil doen?

tenzij andere mensen jouw synology indirect moeten vertrouwen en/of jij certificaten gebruikt voor het aanmelden op je synology is er niets aan de hand.

Het werkt niet op browsers dus je kunt er niet andere mensen mee voor de gek houden.

Gelukkig is het gepatched, maar vertrouwen in ssl is al kwijt bij mij.

In de afgelopen 2 jaar waren er meer dan 10 ssl-bugs waarbij ook nog eens 3 major die keihard werden geëxploiteerd.

Maar ik bemoei niet.

Zie je een alternatief? Plain-text is niet echt veiliger...

Het is al heel wat dat bugs zoals deze gevonden worden en snel gefixed worden. 100% veilig zal je nooit zijn, maar SSL helpt toch al echt wel ber-gen.

Je kan uit het artikel niet opmaken dat de bug "snel" werd gefixed.
En ook niet wanneer die daadwerkelijk voor het eerst is ontdekt.

Dit komt doordat berichtgeving over/van OpenSSL pas naar buiten komt op het moment dat de fix beschikbaar is, eerder worden er geen mededelingen gedaan.

Een man in the middle kan met een valide certificate alles doen met alle gegevens zonder dat het iemand direct op zal vallen. Je moet al goed kijken naar het certificate dat je gepresenteerd krijgt en weten wat daar zou moeten staan om het te kunnen zien. Je browser zal mooi groen kleuren zolang het certificate van de man in the middle maar een goed certificate is.

Heel veel bedrijven passen ditzelfde principe toe binnen bijvoorbeeld hun proxy server om bijvoorbeeld anti-virus te kunnen doen op versleutelde verbindingen. Zolang het goed is ingericht gaat het niemand het opvallen dat de encryptie op een bepaald moment is opgeheven en opnieuw is opgebouwd.
De man in the middle kan dat ook toepassen, en vrijwel niemand die dat gaat zien.

Ik noem SSL (en ook TLS) daarom "tot in de kern defect", zelfs al zitten er geen bugs in je hebt geen enkele garantie dat er onderweg niemand zit mee te kijken in de verkeersstroom.

IPSec VPN met PFS is daarom in mijn ogen nog steeds een betere techniek voor encryptie van netwerk verkeer.

Een man in the middle kan met een valide certificate alles doen met alle gegevens zonder dat het iemand direct op zal vallen. Je moet al goed kijken naar het certificate dat je gepresenteerd krijgt en weten wat daar zou moeten staan om het te kunnen zien. Je browser zal mooi groen kleuren zolang het certificate van de man in the middle maar een goed certificate is.

Je doet hier voorkomen alsof dit altijd kan, buiten deze OpenSSL bug om, maar dat is niet waar. Om een SSL/TLS connectie correct te MitMen heb je een valide certificaat nodig voor het domein in kwestie, anders wordt het mooi rood ipv mooi groen

Heel veel bedrijven passen ditzelfde principe toe binnen bijvoorbeeld hun proxy server om bijvoorbeeld anti-virus te kunnen doen op versleutelde verbindingen. Zolang het goed is ingericht gaat het niemand het opvallen dat de encryptie op een bepaald moment is opgeheven en opnieuw is opgebouwd.

Dat klopt, maar alleen omdat de proxy dan een certificaat gebruikt dat op alle client computers als trusted is geïnstalleerd, anders werkt dat truukje niet.

Ik noem SSL (en ook TLS) daarom "tot in de kern defect", zelfs al zitten er geen bugs in je hebt geen enkele garantie dat er onderweg niemand zit mee te kijken in de verkeersstroom.

Dit slaat dan ook redelijk nergens op; met de opzet van TLS is weinig mis. Als je het certificaat kunt vertrouwen dan is de verbinding veilig (bugs daargelaten), en heb je wel degelijk de garantie dat er niemand mee zit te kijken.

Of je een certificaat kunt vertrouwen is een andere kwestie, de trust hierarchy met certificate authorities is om verschillende redenen in twijfel te trekken (ik ben er geen fan van), maar dat heeft niet veel meer met TLS/SSL te maken.

(SSL is overigens wel verouderd en deprecated en wordt nog maar nauwelijks gebruikt, maar het is dan ook al zo'n 10 jaar opgevolgd door TLS)

SSL zou in principe idd nergens meer gebruikt moeten worden, TLS is beter.
Maar nog steeds ben je afhankelijk van certificates en helaas elk cert die bijvoorbeeld door een Thawte is gesigned wordt by default getrust in je browser en daarmee ook een certificate gesigned door een certificate gesigned door Thawte. Kost een paar pegels, maar het werkt wel.

Er is een domeinverificatie - hoe wil je die omzeilen dan?

Stel je wilt een certificaat voor Google, dan krijg je ook op een @google.com email adres een mail ter verificatie (volgens mij was dit webmaster@<domein.tld>). Als je niet bij deze email kan, kan je ook geen geldig certificaat voor dot domein aanmaken.

Een vals certificaat zou kunnen, maar die krijg je nooit correct gesigneerd zodat de browser t niet opvalt. Daarnaast gebruiken veel grote websites HSTS, waardoor bij een afwijking al meteen een foutmelding komt, en de website niet eens laad. Mooi voorbeeld zijn vaak juist proxies. Bij ons op t werk krijg ik in FF en Chrome een melding dat de website HSTS gebruikt, ipv de afvang pagina dat de pagina geblokkeerd is.

Het punt is dat ik een CA certificate heb, en prima een certificate voor mij proxy (mitm) kan uitgeven op naam van google die perfect kloppend is.
De enige manier waarop je kan zien dat het certificaat niet echt van google is, is door naar het IP adres te kijken en het feit dat die als tussenstap zit tussen het "google" certificate en die van de trusted registrar.

Het uitgegeven Certificate wordt vertrouwd omdat de trust chain in orde is.

Maar nog steeds ben je afhankelijk van certificates en helaas elk cert die bijvoorbeeld door een Thawte is gesigned wordt by default getrust in je browser en daarmee ook een certificate gesigned door een certificate gesigned door Thawte. Kost een paar pegels, maar het werkt wel.

Een leaf certificate (voor bv tweakers.net) dat door Thawte gesigned is kan geen andere certificaten (voor bv google.com) meer signen, omdat dat certificate de "CA" flag mist. Of ja, het kan wel, maar dat laatste certificaat wordt dan nergens geaccepteerd omdat hij niet door een correct hogergelegen certificaat is gesigned.

Dat is ook precies waar deze OpenSSL bug over gaat; de check voor de "CA" flag werd onder bepaalde omstandigheden niet uitgevoerd, waardoor dergelijke incorrecte certificaten wel geaccepteerd werden.

De enige manier waarop kan wat jij beschrijft is door een signing certificate (met CA flag) te krijgen van een CA als Thawte. En ja, ik geloof best dat dat mogelijk is, als je genoeg geld betaalt of inbreekt bij ze, oid. Ik heb geen al te hogen pet op van CAs. En ja, dat is een zwakke kant in het hele CA trust model.

Maar dat heeft wederom niks met SSL/TLS te maken. Je zou ook TLS kunnen gebruiken met alleen zelf-geverifieerde certificaten, of met certificaten via een web-of-trust model zoals PGP/GPG. Wat uiteraard weer zijn eigen nadelen heeft.

Die CA flag is idd het belangrijkste onderdeel van de aanval.
Voor de rest:
Het certificate is een onlosmakelijk deel van het protocol dus het heeft er wel degelijk mee te maken, dat het huidige probleem zich in het certificate gedeelte bevindt en niet in de encryptie an sich maakt niet uit, je kan de encryptie ongedaan maken en het is niet te zien als je er niet speciaal naar kijkt en daar ligt de zwakte van het systeem.

Je vergeet voor het gemak even dat die mitm wel een CA certificaat nodig heeft dat je systeem vertrouwd voor het werkt.

Die goede certificaten waar je het over hebt komen niet zomaar uit de lucht vallen zeg maar.

[Reactie gewijzigd door freaky op 9 juli 2015 21:03]

Dat specifieke CA certificaat vertrouwen is alleen noodzakelijk als hij self signed is. En het hoeft niet zo maar uit de lucht komen vallen, er gaat geld genoeg rond in het informatie circuit dat een dergelijk geldig certificaat kopen niet out of reach is...

Huh?

Juist als het certificaat bij een CA thuishoort en dus niet self-signed is, moet het bedrijf op de een of andere manier die CA kunnen nabootsen anders spuugt je browser vrolijk een foutmelding uit en krijg je een "ZOMG. WE'RE ALL GONNA DIE. RETURN TO SAFETY!" schermpje. Alle keys moeten kloppen. Als je browser 't certificaat gecached heeft zullen waardes afwijken tenzij die proxy de private key heeft weten achterhalen, et cetera.

Je moet altijd die CA vertrouwen als we het over SSL proxies hebben.
Stel, jij bezoekt rabobank.nl. Nu wil je dat uiteraard met SSL doen.
De proxy kent de sleutels niet (hoogstens de publieke.) en kan dus zichzelf niet valideren als "rabobank.nl", je browser geeft nu een foutmelding.
Wat alternatief kan is dat de proxy *wel* authorative is voor "rabobank.nl", mits deze een eigen CA heeft... En dan moet je wat...? Juist, die moet je eerst vertrouwen.

Puntje bij paaltje krijg je dus altijd een foutmelding tenzij je die CA van de proxy vertrouwt.

Het systeem werkt inderdaad alleen maar als je de CA's zou kunnen vertrouwen. Het verleden heeft echter uitgewezen dat dat niet altijd het geval is. Als er maar 1 CA is die onbetrouwbaar is, dan valt het systeem al om.

Nou zijn er technieken als certificate pinning die het risico proberen te verkleinen, maar ook dat is niet helemaal waterdicht. In chrome zitten bijv. hard coded certificaten ingebakken voor de Google sites, maar dat werkt niet voor overige sites. Voor alle andere sites is er toch de factor "vertrouwen bij eerste bezoek". Als je bij het eerste bezoek aan een bepaalde site een legitiem certificaat te pakken hebt, dan kan je browser in de gaten houden dat dat certificaat niet plots wijzigt bij een volgend bezoek. Maar als je een site voor het eerst bezoekt weet je gewoonweg niet of je een legitiem certificaat ontvangt of eentje die geldig lijkt omdat een CA geknoeid heeft.

Dus echt 100% garantie dat er niemand zit mee te kijken kan dit systeem gewoon niet bieden. Ik denk dat Alfa1970 dat bedoelde.

Met websites die een EV certificaat gebruiken en je bent hiervan op de hoogte, dan zou het ook kunnen opvallen wanneer bij het opnieuw versleutelen geen EV certificaat is gebruikt.

Ook is het sowieso verstandig om altijd even te kijken aan wie een certificaat is controlleren, of dit klopt en inderdaad is uitgegegeven aan diegene met wie je wilt comuniseren (let dus bijvoorbeeld op de websitenaam/ domeinaam waaraan het certificaat is uitgegeven).

Al heb je natuurlijk geen 100% garantie dat er niemand heeft meegekeken, maar dat geeft bij mijn weete geen enkele beveiliging.

[Reactie gewijzigd door Zeehond op 9 juli 2015 22:28]

IPSec VPN met PFS is daarom in mijn ogen nog steeds een betere techniek voor encryptie van netwerk verkeer.

En TLS met ECDHE of DHE key exchange? Waarom is dat dan defect?

Mitm zo goed als niet detectable.

Dat is een beetje vaag, wees eens iets specifieker? Wat maakt TLS fundamenteel anders dan IKEv2? Beiden hebben zo hun flaws, overigens.

En stel dat een IKE daemon is gelinkt tegen libcrypto.so.1, wat betekende deze bug daar dan voor? Deze bug zat niet in een stuk code die specifiek was voor TLS, dit betrof het controleren van een certificate chain, iets dat ook door bijvoorbeeld Racoon wordt gebruikt als dat tegen libcrypto is gelinkt.

Deze bug geldt dus mogelijk ook voor S/MIME, IPsec of andere dingen die iets met X.509 certificaten doen en daarvoor OpenSSL's libcrypto gebruiken.

Ik denk dat hij bedoelt dat zijn vertrouwen in OpenSSL op is, en dat is wel een beetje te begrijpen.

Ik vind dit juist heel goed, nu word wat aan gedaan.
wil je je vertrouwen kwijt..

http://cve.mitre.org/data/refs/refmap/source-APPLE.html
http://cve.mitre.org/data/refs/refmap/source-MS.html
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=android

Vertrouwt je ook een auto niet, waar de afgelopen 2 jaar meer dan 10 upgrades zijn aan gebeurt die het veiliger maken ?

Even los van de impact van de bug (die in dit soort gevallen wellicht hoger ligt dan bij autos); jij geeft aan dat het vertrouwen weg is in SSL, maar het punt blijft dat ze in de afgelopen jaren verbeteringen doorgevoerd hebben o.b.v. dit soort ontdekkingen. Want welk stuk techniek wordt nu gebouwd en hoeft nooit gepatched/verbeterd te worden omdat het perfect is?

Verder, je gebruikt dus geen SSL, maar wat gebruik je dan wel? een brakke beveiliging is nog steeds beter dan geen beveiliging, zolang je op de hoogte bent en inschat wat de risico's zijn die eraan verbonden zitten.

Ik kan me ook niet voorstellen dat er veel geheime diensten zijn die te popelen staan om specifiek jouw traffic te bekijken...

Jawel hoor, die diensten werken steeds meer met sleepnetten waar ze zo veel mogelijk in vangen en opslaan. Waar het goed voor is zien ze later wel. Alle wachtwoorden worden sowieso opgeslagen. Een hoop mensen gebruiken hun hele leven lang overal hetzelfde wachtwoord. Dus ook het wachtwoord van een onbetekende tiener is interessant. Over 30 jaar staat die tiener misschien wel aan het hoofd van een bedrijf of politieke partij. Erg handig als je dan nu al z'n wachtwoorden hebt en wat pikante foto's om mee te chanteren.

Niet gek lang geleden is er een Amerikaanse journalist tegen een boom aangereden. "Zelfmoord".
Het was alleen wel een paar uur na een belletje met wikileaks i.v.m de overdracht van een dossier.
Ook had hij eerder de carrière van een Amerikaanse generaal beëindigd.

Tl;dr Ook de software in je auto moet veilig zijn.

Ja gelukkig waren al bang voor een nieuwe heartbleed. Dus valt gelukkig allemaal weer mee deze ronde.

Ja man altijd spannend dit soort dagen. Je loopt de hele dag te wachten op de announcement en dan valt het redelijk mee :-) Redhat/Centos systemen zijn niet kwetsbaar, maar geloof dat Ubuntu 15.10 dat wel is.

Jij en dan moet je met je server ook nog een client rol spelen met een openssl.

maar geloof dat Ubuntu 15.10 dat wel is.

Interessant, maar die komt pas over drie maanden uit.

Je kan je beter zorgen maken om de zaken die helemaal geen announcement, maar ook geen patches, krijgen... Dan wordt het pas spannend...