Independent. Dynamic. Involved.
nlen

Een Heartbleed Post Mortem

Door Peter Rietveld en Bram van Pelt.

Vorige week was de week van Heartbleed, naar verluidt het grootste beveiligingslek in jaren. Vakpers en reguliere pers besteedden zeer veel tijd en ruimte om het verhaal goed uit te leggen.

Je zou dan ook verwachten dat alles over het onderwerp onderhand wel gezegd is; de fix is bekend en over het algemeen al uitgerold. Het was even ploeteren maar we kunnen weer terug naar business as usual. Toch?

Nee. Want wat Heartbleed blootlegt is dat er met hoe we met dit soort crisis omgaan, de processen zeg maar, wel wat te verbeteren is. En daar gaan we in deze Post Mortem op in.

Het optreden rond de Heartbleed bug hangt aan elkaar van extreem pragmatische, om niet te zeggen chaotische noodverbanden. Als dat niet beter wordt gaat het de volgende keer geheid weer mis. En bovendien; deze crisis is ook nog lang niet over.

Observeer

Het bericht over de Heartbleed bug kwam via de reguliere pers, de vakpers en Twitter van alle kanten op ons af. Dat was heel fijn. Waarom ging dat zo? Omdat het een kritiek gat in een massaal gebruikt product is (twee derde van alle Internet-gekoppelde devices. Vergelijkbare gaten komen ook voor in minder gangbare software. Vaak genoeg. Sterker nog, er zijn bijna geen producten die zo vaak worden gebruikt als OpenSSL. Over de minder gangbare producten zal je op nu.nl of in het NRC handelsblad niets over lezen. Nu is de kans erg groot dat je organisatie niet alleen de meest gangbare software heeft. Dus als daar nu zo’n super kritiek gat in zit; hoor je dat dan? Het antwoord is vrijwel zeker ontkennend.

Feitelijk is het toeval dat dit gat zoveel aandacht heeft getrokken. De Pass The Hash aanval van 2013 raakte vrijwel zeker een groter deel van de wereld dan Heartbleed – namelijk alle netwerken met spullen van Microsoft erin. Maar de pers heeft het bericht niet overgenomen – en als je bedrijf zich voor dergelijke informatie afhankelijk opstelt van de reguliere pers jouw bedrijf ook niet.

Oriënteer

Hoe snel was de impact van Heartbleed duidelijk toen het bericht kwam? Is het eigenlijk al duidelijk? Hoe kon je achterhalen waar de gewraakte software allemaal in zit? OpenSSL is onder de motorkap in tal van producten gestopt, ook waar je het niet verwacht zoals embedded in hardware. Nu is er wel de bekende testtool  maar deze test alleen websites. OpenSSL zit niet alleen onder websites, maar in tal van andere producten zoals VPN’s, directories, mail servers en vele anderen. Hoe weet je dan of je daar kwetsbaar bent voor de Heartbleed bug?

Je kunt natuurlijk wachten tot de leverancier het meldt. Een rondgang langs wat grote leveranciers maakt duidelijk dat je bij de één op een medewerkers blog moet zijn en bij een andere bij de security advisories moet zijn. Sommige leveranciers hebben niets te melden of vragen geduld voor onderzoek. Voor dit soort berichtgeving bestaan geen standaarden, dus eenvoudig is het niet om een goede inventarisatie te maken. Bovendien moet je dan precies weten wat je allemaal in huis en hebt en bij welke leveranciers je daarvoor moet gaan zoeken.

Nu kun je ook zelf gaan testen. De al genoemde testtool is alleen geschikt voor websites, maar dat wil niet zeggen dat het moeilijk is om andere systemen te testen. Het is namelijk goed mogelijk om andere systemen te testen.

De Heartbleed bug werkt door een fout in een SSL functie. Deze functie, de heartbeat functie, is voorgesteld en geschreven door dr. Seggelmann en is bedoeld om een SSL sessie in stand te houden, ook als het onderstaande protocol geen sessies kan hanteren. In plaats van de sessie te laten verlopen en opnieuw een sessie op te starten wordt een heartbeat call gemaakt. Deze call houdt de SSL sessie dus in stand zodat geen ‘dure’ nieuwe SSL sessie moet worden opgestart.

De fout zit in de manier waarop deze heartbeat is geïmplementeerd. Om de heartbeat uit te voeren moet een gebruiker namelijk een serie bytes doorsturen en de lengte van deze serie bytes opgeven. OpenSSL pakt dan deze informatie op en stuurt dan de bytes weer terug en de sessie blijft bestaan. Bij een aanval op de Heartbleed bug doe je dit alleen iets slimmer, in plaats van dat je aangeeft hoeveel bytes je opstuurt geef je een groter getal aan bytes aan dan dat je stuurt. In dat geval gaat OpenSSL meer bytes uit het geheugen halen dan nodig is en geeft dit terug. Meer is er niet aan de hand.

Omdat het probleem zit in de software die SSL sessies opzet en onderhoud zijn protocollen zoals FTPS, SSH, POP3, IMAP enzovoorts dus ook niet veilig. SSL is een protocol dat op de laag onder http acteert, en moet dus op die laag getest worden. Mailservers die bijvoorbeeld alleen maar POP3 afhandelen zullen op dit moment niet getest zijn, maar kunnen zeer wel kwetsbaar zijn.

Het is dan ook niet zo moeilijk om de Heartbleed test uit te voeren op andere typen machines. Dat kan met een test script:

–          Download het volgende project https://github.com/musalbas/heartbleed-masstest

–          Voeg het volgende toe bij de commandline opties (ergens tussen regels 35-46):

options.add_option(‘–port’, ‘-p’, dest=”port”, default=443, help=”check port, usefull for scanning non https servers”)

–          Zoek vervolgens in het document op ‘443’. Er zijn 2 hits, de eerste in de regel die net is toegevoegd, de tweede een stuk verder naar onderen

–          Vervang de 2e hit van: s.connect((host, 443)) naar s.connect((host, opts.port))

Vanaf dat moment kan je de optie –p gebruiken om een SSL connectie op te zetten naar een niet http port. Zo kun je zelf bepalen of een apparaat kwetsbaar is.

Maar dat brengt ons tot de laatste vraag.

Beslis en Handel

Heb je wel adequaat gereageerd? Heb je alle kwetsbare componenten gevonden en gepatched, al het mogelijk gevoelig materiaal vervangen en alle gebruikers goed geïnformeerd? Volgens de meeste leveranciers moet je alle certificaten, wachtwoorden en dergelijke vervangen.

De Amerikaanse en de Nederlandse overheid zijn het met de leveranciers eens; alles vervangen.

In de praktijk blijkt dat heel weinig organisaties de certificaten vervangen, zoals Netstat signaleerde. Dat betekent dat de meeste organisatie de adviezen om alles te vervangen (nog) niet uitgevoerd hebben.

Wat ‘alles’ inhoudt is overigens nog verre van duidelijk. Als je bijvoorbeeld bij de token leveranciers kijkt zie je dat ook menig sterk authenticatieproduct geraakt is, zoals de bekende tokens van de banken en de software tokens via de telefoon. Een goede uitleg voor hoe dát uitpakt en hoe de oplossing eruit zou kunnen zien voor de OTP is hier te lezen.

Ook de leveranciers van hardware tokens melden, al dan niet prominent, dat de tokens nieuw sleutelmateriaal nodig hebben. Dat betekent een enorme logistieke operatie om de tokens te her-initialiseren of te vervangen. Iedere burger zou dus nieuwe tokens van de banken kunnen verwachten voor het telebankieren.

Zou het?

De praktijk is lastig, zoals goed geïllustreerd door ons aller DigID. Dat meldt zelfs helemaal niets over Heartbleed. Het is begrijpelijk dat organisaties twijfelen, gegeven de kosten en de impact. We wéten immers niet of er informatie gelekt is en we zullen het nooit weten. Om dan zoveel op de schop te nemen is ook zo wat. Met een dergelijke grote operatie kunnen er bovendien ook grote fouten gemaakt worden, zoals Akamai overkwam. Haastige spoed, zeg maar. De verleiding is dan ook gigantisch om het hele verhaal zoveel mogelijk te negeren.

Het nadeel van de struisvogelbenadering is dat je er dan ook niets van zult leren. En leren is hard nodig, want Heartbleed is nog niet over. En een voorproefje van crises die zeker komen.