Weinig populaire Nederlandse sites zijn kwetsbaar voor kritieke OpenSSL-bug

Nog maar acht van de 500 populairste sites in Nederland blijken kwetsbaar voor de kritieke OpenSSL-bug Heartbleed. Wereldwijd proberen beheerders in allerijl hun systemen te patchen. Vooral voor routers bij thuisgebruikers levert bijwerken problemen op.

Uit een inventarisatie van Tweakers blijkt dat acht van de Alexa Top 500 van meest bezochte sites vanuit Nederland vatbaar te zijn voor de OpenSSL-bug die dinsdag bekend werd. Hoeveel sites aanvankelijk kwetsbaar waren is niet bekend.

Ongeveer 17,5 procent van alle ssl-sites wereldwijd, in totaal een half miljoen, zou aanvankelijk kwetsbaar zijn geweest, becijferde Netcraft. Hoewel meer dan 66 procent van de servers wereldwijd Apache of nginx, en daarmee OpenSSL, draait, maakt lang niet ieder site gebruik van https. Vrijwel alle grote sites en diensten, zoals die van Google, Yahoo, Facebook en Microsoft, waren bij het bekendmaken van de bug al bijgewerkt, of bezig dit te doen. Yahoo bleek dinsdag nog wel relatief lang kwetsbaar, blijkt onder andere uit een blogstuk van Fox-IT en ook tientallen andere sites uit de Alexa Top 1000 van wereldwijd populaire sites, zoals Kickass Torrents, OKCupid, XDA Developers. Otto.nl en WeTransfer waren kwetsbaar.

Beheerders van kleinere sites zijn ook veel minder snel in het bijwerken en dit is vooral ernstig bij webshops. Uit een snelle rondgang langs grote tot middelgrote webshops, vond Tweakers vijftien kwetsbare sites, die daarmee klantgegevens zoals creditcardnummers kunnen lekken.

Daarnaast is de verwachting dat de zogenoemde Heartbleed-bug effect gaat krijgen bij routers. Vooral thuisgebruikers hebben geen idee of hun modem annex router kwetsbaar is, schrijft The Register. Als ze het al weten zijn ze afhankelijk van de leverancier voor een firmware-upgrade en oudere apparaten worden waarschijnlijk niet meer bijgewerkt.

Dinsdag werd de Heartbleed-bug bekend. De bug zit in OpenSSL, die veel diensten wereldwijd gebruiken voor de ssl-encryptie voor hun sites. De bug zit in de 'heartbeat'-extensie, die computers een berichtje laat sturen om te verifiëren dat een systeem aan de andere kant van de ssl-lijn nog steeds online is en kan reageren.

Het bleek mogelijk een kwaadaardig Heartbeat-bericht te maken dat een server overhaalt de inhoud van zijn geheugen prijs te geven. Daarmee zouden onder andere wachtwoorden en creditcardgegevens op straat kunnen komen. Er zou weinig technische kennis nodig zijn om de kwetsbaarheid te benutten en het lek zou al twee jaar in de software zitten.

Reacties (67)

[mkools24]

Hier kun je je server testen: http://filippo.io/Heartbleed/

[walkstyle]

Met een eigen server/vps kun je beter uitvoeren:
openssl version

Vindt het maar niks om elke site via daar in te vullen, met het risico dat iemand er misbruik van maakt.

[WhiteDog]

Sorry maar dat is niet altijd correct.

Zo geeft "openssl version" bij mij 1.0.1e
Jij zou dus stellen dat ik vulnerable ben. Echter gebruik ik CentOS 6.5 en is deze bug gepatcht in versie 1.0.1e-16 (1.0.1e-15 en lager zijn vulnerable).

Met "yum list openssl" kreeg ik wel de volledige versie.

Daarnaast nog deze tips:
- Check met "openssl version -a" de build date (na 07/04/2014).
- herstart alle processen die je vind met "sudo lsof -n | grep ssl | grep DEL" (pending changes) of gewoon de machine even helemaal rebooten.

[mxcreep]

Vergeet er dan niet bij te zeggen dat de versies in CentOS 5.x ook veilig zijn, dat zijn versies voor 1.0 waar de bug geintroduceerd schijnt te zijn. Al mijn oude CentOS 5 vm's hebben OpenSSL 0.9.8.x en zijn safe.

[Stukfruit]

Daarom staat er onder die site ook een linkje naar Github met de broncode zodat je de tool zelf kan draaien:

https://github.com/FiloSottile/Heartbleed

[Faeron]

Niet alleen de server moet gepatched worden. Ook de private key en het bijbehorende certificaat moet worden vervangen omdat deze mogelijkerwijs gecompromitteerd is. Zo heeft de Rabobank wel haar server gepatched, maar gebruiken ze nog steeds hetzelfde certificaat. Internetbankieren bij de Rabobank is dus nog steeds onveilig!!

[bjv]

Wie zegt dat www.rabobank.nl OpenSSL gebruikt?

Alleen voor sites die OpenSSL gebruiken, die hoeven te patchen. Nu is OpenSSL een heel populaire SSL library, maar er zijn ook genoeg andere zoals GnuTLS en NSS die je kunt gebruiken, of bijvoorbeeld dedicated hardware voor SSL afhandeling. Al die andere SSL engines hebben (waarschijnlijk) geen last van HeartBleed en hoeven dus ook niet gepatcht te worden.

[drdelta]

Waaruit blijkt dat ze kwetsbaar zijn?

[Faeron]

Ze waren kwetsbaar: https://twitter.com/cducroix/statuses/453452094268510208

[Reactie gewijzigd door Faeron op 25 juli 2024 17:32]

[NMe]

De grote Nederlandse banken hebben gisteren alledrie aangegeven dat ze geen OpenSSL gebruiken en dus niet kwetsbaar zijn.

[mxcreep]

Denk dat ze in veel gevallen wel hardware loadbalancers voor hun webservers hebben die ook SSL offloading doen, dan is het de vraag welke SSL library in die loadbalancers gebruikt wordt.

[chickpoint]

Ik ben benieuwd wanneer synology een hotfix uitbrengt voor dit lek. Wel wat geruchten maar helaas nog geen concrete informatie.

[wesleyvdbrink]

Zoek en gij zult vinden: http://ukdl.synology.com/...pdate/update_pack/4458-2/
Heb de patch hier geinstalleerd en lek is verholpen

[traviandus]

Toch kan er in deze korte tijd al een grootschalige (geautomatiseerde) diefstal zijn gedaan van private keys. Volgens mij is het vrij lastig vast te stellen of de private key op straat ligt (en de rest van de inhoud van het virtuele geheugen van de webserver)

[Reactie gewijzigd door traviandus op 25 juli 2024 17:32]

[OMX2000]

Kans is er maar is klein. Het is niet alsof je gericht data terug krijgt. Het is random data die toevalligerwijs een private key kan bevatten als dat in het geheugen heeft gezeten en net is vrijgegeven.

http://arstechnica.com/se...ited-months-before-patch/

[Siebsel]

Daarom wordt ook geadviseerd de keys te veranderen, SSL certificaten opnieuw aan te vragen en je wachtwoorden te wijzigen.

[mxcreep]

Die adviezen zijn heel erg leuk voor sites die ik zelf beheer, ik zie persoonlijk een groter probleem bij andere instanties die dit niet doen en waarvan private key data beschikbaar is gekomen, de communicatie met mij en die partij zal dus deels leesbaar zijn in het uiterste geval. Feitelijk zou je dus nu bij elke SSL site moeten gaan checken wanneer het certificaat is uitgegeven om een inschatting te kunnen maken of ze dit na het uitkomen van deze bug nog vervangen hebben, is bijna onbegonnen werk als gebruiker.

Wachtwoorden wijzigen als gebruiker is denk ik inderdaad een goed idee, maar nutteloos wanneer die private key toch onverhoopt op straat ligt.

[Yggdrasil]

Het is inderdaad niet vast te stellen of er gebruik is gemaakt van het lek, dus moet men uit gaan van het slechtste scenario.

[_eXistenZ_]

Alle informatie in een handig overzichtje: http://heartbleed.nl

[WhatsappHack]

Nou, dan vind ik de engelse variant (http://www.heartbleed.com) toch echt een heel stuk informatiever.

[theMob]

Ik kreeg een berichtje van Xolphin (waar ik mijn certificaat heb afgenomen) dat ze mijn site gecontroleerd hebben en gezien hebben dat hij kwetsbaar is voor de bug, Wel netjes en meteen uitgezet. Nu nog wachten hoe lang het duurt voor Synology een patch heeft. Gelukkig is het net nu extreem rustig...

[wesleyvdbrink]

Zoek en gij zult vinden: http://ukdl.synology.com/...pdate/update_pack/4458-2/
Heb de patch hier geinstalleerd en lek is verholpen.

[bjv]

Waarom denkt iedereen bij SSL alleen aan websites?

[CriticalHit_NL]

Artikel goed gelezen?

"Daarnaast is de verwachting dat de zogenoemde Heartbleed-bug effect gaat krijgen bij routers. Vooral thuisgebruikers hebben geen idee of hun modem annex router kwetsbaar is, schrijft The Register. Als ze het al weten zijn ze afhankelijk van de leverancier voor een firmware-upgrade en oudere apparaten worden waarschijnlijk niet meer bijgewerkt."

Bronnen:
http://www.theregister.co...than_just_a_website_vuln/
http://www.nu.nl/tech/374...ar-groot-lek-openssl.html

[Kees]

Tja, en dat gaat eigenlijk ook weer over https in het algemeen.

Maar verder heb je dingen als: imap-ssl, pop3-ssl, mailservers, irc, (open)vpn, en allerhande spul wat via ssl met elkaar praat dat kwetsbaar is.

https is alleen het meest eenvoudige te controleren.

[mbb]

Ik neem aan dat het oof voor NAS-systemen geld, die draaien ook vaak een interne webserver en kun je ook alleen met eventueel beschikbare firmware updaten. Dus daar ook afhankelijk van de fabrikant

[mxcreep]

Soms wel soms niet, zijn ook systemen bij waar je prima zelf wat kunt compilen.

[borft]

goed punt, je moet niet vergeten na het updaten van je openssl library alle services die ervan gebruik maken te starten. Veel mensen lijken ook te denken dat het een Linux probleem is, terwijl openssl een cross-platform library is

[Gunner]

Wereldwijd proberen beheerders in allerijl hun systemen te patchen.

Waaronder Tweakers.net

Tweakers is kwetsbaar voor OpenSSL-bug

[Reactie gewijzigd door Gunner op 25 juli 2024 17:32]

[Wilbert de Vries]

Dat is gisteren al gedaan

[Kees]

Hoezo is die bug al 'jaren' bekend? De desbetreffende code is geschreven in december 2011, toen pas ontstond de bug. En pas gisteren is de CVE bekend gemaakt, daarvoor was de bug er natuurlijk al wel maar was hij niet bekend.

Let wel, dit is niet omdat systeembeheerders niet hebben lopen patchen, maar omdat die bug gewoon niet bekend was. En nu hij wel bekend is zijn vrijwel alle sites al geupdated. En ja, er was paniek in de tent, ik heb gehoord van changeprocedures die nog nooit zo snel doorlopen zijn etc.

Dat die bug al jaren bekend was is gewoon pure kolder.

[SuperDre]

Maar mogelijk dat sowieso de bug al jaren bekend was bij bepaalde hackers.. Omdat hij pas deze week in het nieuws is gekomen wil nog niet zeggen dat de bug niet al langer bekend was..

[Kees]

We hebben het hier over twee dingen eigenlijk; ik bedoel met 'bekend' dat het bij de ontwikkelaars bekent is en dat die er een patch (of workaround) voor gemaakt hebben voor de gebruikers.

Een 0-day is niet bekend bij het publiek maar bij slechts en klein aantal mensen. En dan kun je de gebruiker niet verwijten dat hij kwetsbaar is voor de bug.

Zeggen dat mensen pas zijn gaan patchen 'omdat de bug in het nieuws kwam' is een beetje onzinnig; tot eergisteren waren er uberhaubt geen patches en slechts een sellecte groep ontwikkelaars en researchers wisten er van (en ja, mischien ook hackers). Waar ik op ageer is 'Pas toen het groot in het nieuws kwam ja. Terwijl de bug al jaren bekend was.'. Alsof men eerder actie had kunnen ondernemen als gebruiker/sysadmin zijnde en dat we pas iets doen omdat de bug nu in het nieuws is.

[ACM]

OpenSSL publiceerde het pas op 7 april, en de CVE was blijkbaar op 3 december 2013 gemaakt. Dus "al jaren bekend" is wellicht ietwat overdreven?

[Reactie gewijzigd door ACM op 25 juli 2024 17:32]

[CyBeR]

Disclaimer: The entry creation date may reflect when the CVE-ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.

De datum van een CVE zegt niet zo heel veel.

[ACM]

Ok, maar dan nog zie ik er geen bewijs in dat het bestaan (en de impact) van deze bug al "jaren bekend" zou zijn geweest.
Althans, niet bij het grote publiek. Het kan natuurlijk prima zijn dat er ergens iemand al (maximaal 2 a 3 jaar) deze bug kent en daar misbruik van heeft gemaakt, maar die heeft het dan niet aan de grote klok gehangen (en blijkbaar ook niet aan OpenSSL doorgegeven).

[CyBeR]

Ok, maar dan nog zie ik er geen bewijs in dat het bestaan (en de impact) van deze bug al "jaren bekend" zou zijn geweest.

Ik bedoel het ook andersom. De vulnerability van die CVE is van dit jaar (zie ook 2014 in CVE-2014-0160), niet van 2013. Maar het nummer is in 2013 gealloceerd.

De datum van de bekendmaking van OpenSSL is wmb leidend.

[Reactie gewijzigd door CyBeR op 25 juli 2024 17:32]

[koku]

De bug bestond misschien al jaren, maar dat hij bestond is pas deze week ontdekt... Beetje onzinnige reactie dus.

[SuperDre]

Nou, de bug was al langer ontdekt, pas deze week is hij publiekelijk gemaakt.. groot verschil...

[huntedjohan]

in de context van deze discussie maakt dat dus net niets uit. alleen voor eventuele misbruiken maakt het uit. je kun als beheerder van een website niet iets fixen als je niet weet dat de fout er in zit. doordat het 2 dagen terug bekent gemaakt is kunnen beheerders dus ook net 2 dagen er op in spelen.

om dan lekker simpel te zeggen dat de bug al langer bestond en dat het dus eigenlijk fout is van tweakers dat ze het nu pas gefixed hebben is behoorlijk kortzichtig. (dit is dan bedoeld als reactie op gunner )

[t1mmy]

Ik neem aan dat jij elke bug van elk systeem en elke versies uit je hoofd kent?

[Nas T]

And: it's gone:

Ondertussen allemaal geregeld...

[Kenhas]

De bug zit er al jaren in maar ik dacht toch dat de bug nu pas gevonden was. Anders zouden ze er nu toch geen zo'n ophef rond maken.

En je kan natuurlijk maar iets aanpakken als je weet dat er iets aan schort

[Booster]

Waar het in dit artikel over 'websites' gaat, wordt denk ik 'de belangrijkste domeinnaam van die website' bedoeld. Een subdomein die op een andere server draait, kan natuurlijk wel alsnog kwetsbaar zijn, en soms nét zo interessant. Denk maar aan (web)mail.grotesite.nl of login.grotesite.nl.

Gisteren was dit o.a. het geval bij een van de grootste Nederlandse webhosters.

Ik verwacht dat dit probleem nog jaren en jaren aan narigheid zal veroorzaken, ook bij Nederlandse websites.

[Kees]

Ik ben wat dat betreft iets optimistischer; de bug is redelijk recent, en ook al heeft hij er twee jaar ingezeten, hij is nu gepatched.

Het probleem zijn de mensen die nu de kwetsbare versie nog draaien maar niet updaten. Gelukkig zijn dat vooral de mensen die niet updaten, dus de kans dat ze een kwestbare versie draaien is niet heel groot

[Booster]

Ik denk voor de toekomst niet zozeer aan problemen op de servers die die websites hostten, maar wel problemen op routers en APs (consumenten en ook de grotere merken) waar het verkeer van die sites of bedrijven doorheen gaat.

Nu is er nog veel aandacht voor deze bug, maar over een tijdje is die aandacht weg. Als je dan toevallig nu onder een steen ligt dan duurt het even voor je ontdekt dat je al tijden een probleem hebt

Of, denk aan beheerders die redeneren "ik gebruik toch geen Apache" en zich niet realiseren dat er op termijn ook exploits kunnen verschijnen voor TLS bij SMTP, IMAP, POP3, VPN's wellicht, etc.

[Verwijderd]

Yep, mijn exim smtp server had ik compiled met openssl en die was natuurlijk ook vulnerable.

[WhatsappHack]

'Met duizenden websites die op Windows XP draaien dacht ik dat het "the perfect storm" zou zijn om Apache op XP te draaien met OpenSSL. Helaas bleek de gebundelde OpenSSL versie 0.9.8 te zijn.'

[drdelta]

Waarom zou je in hemelsnaam Apache en OpenSSL op Windows XP willen draaien? Dat is vragen om moeilijkheden.

[WhatsappHack]

Ik geloof dat ironie en sarcasme helaas niet helemaal lekker doorkomen op het internet.
(Die OpenSSL versie is ook niet kwetsbaar namelijk.)