Veel servers blijken nog steeds kwetsbaar voor Heartbleed-bug

Bij een scan van alle ipv4-adressen met behulp van de portscanner masscan zijn nog 318.000 systemen aangetroffen die vatbaar zijn voor de Heartbleed-bug in OpenSSL. Vlak nadat de kwetsbaarheid aan het licht kwam waren 615.000 systemen nog kwetsbaar.

De resultaten van onderzoeker Robert Graham, de ontwikkelaar van de efficiënte portscanner masscan, kunnen er op wijzen dat het aantal kwetsbare servers is afgenomen, maar dat is niet met zekerheid te zeggen. Tijdens de portscan, die zich enkel toelegde op https-poort 443, vond Graham 22 miljoen servers die ssl ondersteunden; bij de vorige portscan waren dat er 28 miljoen.

Het zou kunnen dat firewalls de pogingen van Graham om servers te testen op aanwezigheid van de Heartbleed-bug blokkeerden, of dat hij last heeft gehad van opstoppingen bij zijn eigen internetprovider. Zeker is in ieder geval dat er nog steeds veel servers kwetsbaar zijn voor de Heartbleed-bug.

Opmerkelijk is dat Graham 1,5 miljoen systemen vond waarop de heartbeat-extensie, waarin de kwetsbaarheid aanwezig is, was ingeschakeld. Een dag nadat de bug werd ontdekt, ontdekte hij slechts een miljoen systemen waarop de heartbeat-extensie was ingeschakeld. Graham denkt dat veel sysadmins heartbeat hebben uitgeschakeld op hun server totdat er een fix beschikbaar was.

De Heartbleed-bug kwam een maand geleden aan het licht. De bug laat kwaadwillenden malafide requests naar een OpenSSL-server sturen, waarna die een deel van het interne geheugen terugstuurt als antwoord. Daarmee liggen in theorie privésleutels, onversleutelde wachtwoorden en andere gevoelige informatie op straat.

Reacties (44)

Ik denk dat vele (linux) servers nog op een OS draaien waarvan de support end-of-life is.
Als je dan een upgrade wil doen naar een nieuwere versie van het OS, sleur je allerhande zaken mee die impact hebben op de actieve services (bvb PHP versie die verhoogt voor web applicaties).
Ik vind 1,5% zeer laag.

Sommige beheerders denken dat een aministratieve maatregel als het veranderen van de poort bijdraagt aan de beveiliging van een systeem en laten een admin-console op een andere poort draaien, waardoor het ontsnapt aan dit soort onderzoeken.
Wil je je eigen systeem/systemen volledig testen?

• Download de laatste versie van Nmap:
• Voer het volgende commando uit in CMD.EXE: Nmap.exe -p 1-65535 -sV --script=ssl-heartbleed.nse --open -iL addressenlijst.txt

Realiseer je wel dat je dit niet op andermans systemen moet gaan proberen!

Die discussie heb ik hier ook gehad laatst, toen werd ik voor gek verklaard toen ik aangaf dat het verplaatsen van poort niets meer en minder is dan security though obscurity en dat het er niet veiliger door wordt. Je wordt misschien door een minder grote massa scriptkiddies gevonden maar elke serieuze hacker die jou tot zijn doel heeft gemaakt zal zeer zeker diverse scans uitvoeren om te achterhalen wat waar draait in jouw omgeving.

Ik ben van mening dat diverse admin interfaces zowieso al niet publiek beschikbaar moeten zijn maar in een intern netwerk. Geef mensen maar vpn accounts dmv certificaten en/of 2 factor authentication. Gebruikers (en daar horen veel beheerders ook bij) moeten opgevoed worden en maar leren dat veiligheid ook akties van je zelf inhouden.

De meeste systemen die nu EOL zijn hebben een veel te oude OpenSSL library om kwetsbaar te zijn, die komen veelal met OpenSSL 0.9.8, waar het probleem zich niet voordoet.

Bedenk je ook dat patchen vaak pas kan/mag na testen en op goedgekeurde momenten. En dat het "pas" een maand geleden is dat deze bug is ontdekt.
Er zijn redelijk wat logge bedrijven die zich met de beste wil van de wereld niet aan een voorgeschreven route kunnen of willen onttrekken.

En dan moet er vervolgens een nieuw certificaat worden aangeschaft aangevraagd en geinstalleerd... volgende change-proces.

Slechte zaak. Je zou verwachten dat mensen dit wel rap oppakken. Al is het natuurlijk zo veel hobbyisten misschien niet goed weten hoe ze lek moeten dichten en dat zorgt voor een boel servers die nog kwetsbaar zijn. In ieder geval hoop ik dat dit aantal nog sterk terugloopt want het is echt een gevaarlijk lek...

[Reactie gewijzigd door DennusB op 9 mei 2014 09:34]

Hobbyisten die actief OpenSSL gebruiken zijn waarschijnlijk sneller geweest met het upgrade/tijdelijk uit zetten tot de patch beschikbaar was dan grote corperates. En anders is het een hobbyist geweest die toch al geen directe (shared hosting etc.) server toegang had.

Met corporate zit je vaak inderdaad met vertragingen omdat patches en bugfixes niet zomaar mogen toegepast worden maar altijd eerst gevalideerd moeten worden. Hoewel het vreemd lijkt dat zo een simpele patch niet op zo een tijd gevalideerd zou kunnen worden.

Als het om een bug van dit kaliber gaat wordt er echt wel een spoedchange uitgevoerd, ook binnen corporate. Dan kan het misschien nog een paar dagen duren maar zeker geen weken.

Ik denk dat niet iedereen op de hoogte is van de heartbleed bug, ook al is het uitgebreid in de media geweest. Vraag maar eens rond in je omgeving wie het wel of niet kent en dan zijn er altijd wel een paar die nooit nieuws lezen en geen enkel idee hebben.

Verder heb je nog zaken als router, printer en allerlei andere remote management interfaces die via HTTPS beanderbaar zijn en de bug misschien ook wel hebben en dat wordt vaak niet geupdate zeker niet door thuisgebruikers.

Doorsnee gebruikers hoeven het ook niet te weten, maar ICT-ers (en zeker de ict-ers die verantwoordelijk zijn hiervoor) moeten het weten. Zo niet, dan zou ik als leidinggevende toch op z'n minst een aantekening in het dossier van zo'n persoon zetten.....

Ik ben ICT-er maar je moest eens weten, hoeveel mensen in dit vak totaal geen interesse hebben en niet eens sites als tweakers of webwereld lezen.

Veel beheerders die ik ken doen het vooral voor de loonstrook aan het einde van de maand en tot het zover is maken ze het zichzelf het liefst zo makkelijk mogelijk.

En hoe gaat die leidinggevende weten dat er zoiets bestaat als een heartbleed bug? Oja, dat moet die ict-er 'm vertellen . . .

Diverse beheer interfaces horen over het geheel genomen gewoon in interne netwerken opgenomen te zijn, niet direct benaderbaar vanaf buiten. Dan heb je alleen nog je VPN waar je naar dient te kijken voor een bug als deze. En uiteraard diensten die wel publiek beschikbaar zijn.

[Reactie gewijzigd door mxcreep op 9 mei 2014 18:53]

Corporate of niet, als je beleid zo in elkaar zit dat je spoedeisende patches niet vlot kunt doorvoeren dan slaat je beleid compleet de plank mis. Een dergelijk beleid is bedoeld om stabiliteit en veiligheid te waarborgen, zodra het die doelen dwarszit moet je toch eens goed gaan nadenken of je goed bezig bent.

Ik zou mijn klanten (en dat kunnen ook interne klanten zijn) in elk geval niet recht in de ogen durven aankijken als ik een patch als deze niet snel zou uitrollen.

Wij hebben op 1200 servers over OTAP heen in 4 uur tijd gepatched. Incl communicatie. Juist grote clubs kunnen het als ze goed zijn!

Het zou kunnen dat de ssl library ook in pakketten zijn opgenomen waar men geen weet van heeft. Zo had hMailServer ook de heartbleed bug. Er is een patch voor maar hoeveel mensen zullen die installeren? In Xampp zit ie ook, hoewel het niet verstandig is deze als productie server te gebruiken wordt dat wel gedaan.

OpenSSL zit in heel veel pakketten je zou eens de bugtraq mailinglijst moeten afschuimen.
Alle HP mailings van de laatste weken zijn HeartBleed gerelateerd.

Dan heb je geen goed configuratiemanagement ingeregeld.

Bedoel je nu dat hobbyisten het wel of niet goed weten? Je zin is daar niet helemaal duidelijk in.

Niet goed... typfoutje inderdaad. Sorry

Ik denk dat er ergens een 'niet' ontbreekt in jouw zin...

ON TOPIC:
Voor iedereen die twijfels heeft over de veiligheid van zijn server: https://www.ssllabs.com/ssltest/ - zeer nuttig (bevat ook tips om een A-score te behalen).

Ik heb de laatste tijd ook geregeld hostingbedrijven gezien die hun klanten vertellen dat het probleem is opgelost...
Beetje rot als je dan een nieuw certificaat zit aan te vragen en de melding krijgt dat de site op een server draait die vatbaar is.... en dat vervolgens met verschillende test kan verifieren...

Dat heeft niet(s) met hobbyisten te maken, volgens mij.

[Reactie gewijzigd door Jester-NL op 9 mei 2014 12:29]

Ze hebben het steeds over kwetsbare servers en dat deze niet goed gepatcht worden, maar is er een tooltje waarmee je simpel kan zien of je kwetsbaar bent? Die misschien een schadeloze exploit probeert toe te passen o.i.d.?

Yes

[Reactie gewijzigd door jasperswaagman op 9 mei 2014 10:08]

Deze test is leuk, maar verteld me alleen of een server OP DIT MOMENT kwetsbaar is. (en kijkt alleen naar poort 443)

Oftewel, ik weet nu nog steeds niet of site x ooit kwetsbaar is geweest en ik dus mijn wachtwoord moet wijzigen.

In dat geval moet je dus al je wachtwoorden wegggooien en opnieuw beginnen als je het 'goed' wilt doen.

Ik wordt daar niet enthousiast van, en mijn klanten ook niet. Zeker de ouderen onder mijn klanten niet.

Ik heb de laatste tijd gemerkt dat www.netcraft.com keurig aangeeft:

• Of een site vatbaar is
• Of een site vatbaar WAS
• Of het certificaat al vervangen is sinds het ontdekken van deze bug

Beter dan dat heb ik nog niet gevonden.
Overigens moet je wel zelf https:// meegeven aan het server-adres

Hee, dat is goede info. Dank je wel.
Voor mijn klanten veel te technisch, maar ik kan nu wel voor mijn klanten wat sites die zij gebruiken controleren.

Vraagje: als ik bij netcraft google.com opgeef, krijg ik te zien dat heartbeat aangeboden werd en nu niet meer. Duidelijk.
Echter, er zijn 8/8 certificaten gekoppeld die niet vernieuwd zijn.
Is een certificaat vernieuwing absoluut noodzakelijk?

De heartbleed-bug maakte het mogelijk om de meest recente [umph] bits uit het geheugen te lezen. En dat gedurende lange tijd.
Er is dus een kans dat de private key uitgelezen is geweest.
Jer kunt er een stukje statistiek en kansberekening op los laten om te bepalen of dat ook gebeurd is

Wat Google heeft gedaan is het volgende:

• Ze hebben gepatcht (uiteraard, er was een lek)
• Ze hebben nieuwe certificaten geplaatst (of om exact(er) te zijn... nieuwe CSRs gemaakt op de servers (waarmee de private key is vervangen en daarmee de certificaten opnieuw laten uitgeven) (want mogelijk zijn de vorige gecomprimeerd, bovendien is het vervangen een gratis service van iedere CA (met hier en daar een uitzondering, maar daar heb je als klant voor gekozen)
• Ze hebben de oude certificaten (nog) niet laten intrekken...

Waarom niet, dat is koffiedik kijken... ik durf het niet te zeggen.
Wel weet ik dat het geen common practice is voor een CA om de vorige versie(s) van een opnieuw uitgegeven certificaat automatisch te revoken. Daar moet je als klant om vragen. En dat heeft waarschijnlijk iets met de beruchte 'revoking list' en de zwaarte daarvan te maken.

In theorie is het dus mogelijk dat er ergens een 'valide' (lijkend) Google-certificaat door een onverlaat wordt gebruikt. Maar laat daar je statistiek en kansberekening nog even op los...
Overigens lijkt het (als ik zelf even naar hun certificaten kijk) dat ze die zelf, en voor een periode van drie maanden, uitgeven. Ik vindt dat wel een mooie periode...

Alleen klopt hun info niet. Als ik de https-versie van onze eigen site opgeef, meldt Netcraft (bron)

The site offered the Heartbeat TLS extension prior to the Heartbleed disclosure, but is using a new certificate.

Toen de heartbleed bug bekend werd, draaide die site op Centos 5 met OpenSSL 0.9.8 en was dus niet vulnerable. Dit weekend heb ik de hele server overgezet naar Centos 6 en https voor die site uitgezet.

Overigens mooi staaltje van eigen vlees keuren. Netcraft zelf vindt ssl.netcraft.com top-of-the-bill, maar ssllabs geeft het slechts een B:
https://www.ssllabs.com/s...e.html?d=ssl.netcraft.com

@Jester: Hij geeft dus niet aan of de site vatbaar was, maar wekt wel die suggestie. Zo blijkt ook wel uit jouw reactie. Verder hebben we het certificaat vervangen, omdat het ook gebruikt werd op wel vulnerable servers. En voor toolsforresearch hebben we SSL gewoon uitgezet zonder er een nieuw certificaat neer te zetten.

[Reactie gewijzigd door Jan-E op 12 mei 2014 13:03]

Dus de info klopt?
Voor het weekend gebruikte je Heartbeat (of had het in ieder geval aan staan). Dat staat er namelijk. Er staat niet dat je ook vatbaar bent (of was).
Daarnaast staan er nu nieuwe certificaten op je servers (sinds 12 april).
Overigens: je certificaat is niet geldig voor de site die je aangeeft. Het is een wildcard-certificaat voor de .nl-site van de organisatie die het domein bezit

Voor wat betreft het keuren van eigen vlees: Ik denk dat de test-methoden een beetje verschillen, aangezien jouw site bij netcraft.com nogal wat hoger scoort dan bij SSLlabs... maar dat laatste kun je met een goed certificaat zo weer recht krijgen

Voor een uitgebreide scan, zie mijn eerdere post.
Voor info over websites die getroffen zijn geweest, zie hier.

Voor wie geïntresseerd is in advisories van leveranciers heb ik een overzicht gemaakt:

• Apache
  • Tomcat
• Barracuda
• Cisco
• Citrix
• D-Link
• Debian
• Dell
  • SonicWALL
• F-Secure
• F5
• FortiGuard
• HP
  • Networking
  • Servers
  • System Management Homepage
  • BladeSystem
  • Smart Update Manager
  • iLO waarschuwing
  • iLO en iLO 2 apparaten crashen tijdens scan!
• Juniper
• Kemp
• McAfee
• Oracle
• Red Hat
• Sophos
• Ubuntu
• VMware

[Reactie gewijzigd door Zarc.oh op 9 mei 2014 12:13]

Dank je wel voor je reactie. Goede info.

De Mashable lijst kende ik al. Daar heb ik een hoop info uit gehaald, maar de lijst is vooral internationaal gericht.

Je eerdere post mbt nmap had ik gelezen, maar inderdaad - niet op andermans servers uitproberen. Dus vandaar voor mij en mijn klanten geen toegevoegde waarde (geen eigen servers).

Ik vraag me af hoe betrouwbaar deze cijfers zijn... Aaangezien er zoveel enorme verschillen in zitten.

Vooral de zin: "Tijdens de portscan, die zich enkel toelegde op https-poort 443, vond Graham 22 miljoen servers die ssl ondersteunden; bij de vorige portscan waren dat er 28 miljoen" baart mij zorgen. Dat er opeens 6 miljoen servers "weg zijn"

Ze kunnen ook gewoon SSL hebben uitgezet omdat ze het eigenlijk helemaal niet gebruikten maar het default wel open stond !

Het lijkt me vrij sterk dat je webpagina's voor de katsekont over https serveert en dan bedenkt: "ah joh, dat kan ook wel gewoon over http"... Zeker geen 6 miljoen...

Bij veel shared hosting staat https standaard aan zonder cert....

https zonder certificaat lijkt mij onmogelijk.

Self signed bedoel k ook

Hij bedoeld natuurlijk zonder een officieel gesigneerd certificaat.

Ongeveer 1,5% is dus nog steeds vatbaar voor heartblead. Hoewel het natuurlijk slordig is , valt dat op zich nog wel mee.

Sinds heartbleed heb ik er toch eens werk van gemaakt als ik nog eens ergens inlog mijn paswoord te veranderen, en te zorgen dat ik overal een ander paswoord heb.
Met al die paswoorden moet ik nu wel terugvallen tooltjes als KeePass, want onthouden is onbegonnen werk.

Het is bijzonder onwaarschijnlijk dat veel beheerders heartbeat hebben uitgeschakeld op hun server totdat er een fix beschikbaar was. Heartbeat in TLS schakel je alleen maar uit door OpenSSL opnieuw te compileren (bron). De fix was toen al beschikbaar (al was de site van OpenSSL wel traag op dat moment) en dus hadden zij net zo goed OpenSSL 1.0.1g kunnen compileren.

Wat je wel zonder compileren uit had kunnen schakelen was de mod_heartbeat.so extensie in Apache, maar dat is heel wat anders dan de heartbeat extensie in TLS.

@bluesgold: check je feiten als je een flamewar wil starten. Mijn Windows servers werden op hetzelfde moment gepatcht als mijn Linuxbakken. Leesvoer.

[Reactie gewijzigd door Jan-E op 10 mei 2014 19:43]