Wat is Heartbleed en hoe bescherm je jezelf?

Heartbleed is nu al even in het nieuws en lijkt zijn impact nog steeds uit te breiden. Verschillende sites blijven updates versturen van de log-in handelingen om gebruikers gerust te stellen dat hun data veilig is. Andere sites melden dat ze slachtoffer zijn geworden, en dat een ander wachtwoord noodzakelijk is. Wat is Heartbleed? Hoe serieus moeten we Heartbleed nemen? En wat kun je doen ter bescherming?

De meningen lopen uiteen van ‘gewoon weer een gat in de verdediging’ tot ‘dit is een revolutionair security-issue’. De gematigde reactie komt meestal voort uit de constatering dat ‘slechts’ 17 procent van de sites is geraakt.

Maar er is ook nog de impact op gadgets en apparatuur die we snel over het hoofd zien. Heel veel smartphones, ip-telefoons, switches en routers worden aangemerkt als kwetsbaar. Internetrouters voor thuisgebruik en de hippe e-thermostaten zijn allemaal mogelijk slachtoffer. En terwijl het internet of things steeds meer apparatuur koppelt, wordt die lijst alleen maar langer. Veel van deze apparaten zullen niet worden geüpdate, waardoor bedrijven die ermee werken en communiceren gevaar lopen. Zij hebben behoefte aan een beveiligingsoplossing die los staat van het wel of niet updaten van het apparaat zelf.

Aangezien er veel aandacht voor is, zullen de leveranciers haast over elkaar vallen met een passend aanbod om gebruikers te beschermen tegen Heartbleed. Netwerkapparatuur zal in stelling worden gebracht om verzoeken die gebruik maken van het lek te detecteren en tegen te houden.

Er zijn verschillende plekken in het dataverkeer waar je dit lek en vergelijkbare kwetsbaarheden kunt tegenhouden. Bedrijven moeten het meest strategische punt kiezen in het netwerk. Om dat punt te bepalen, moet je je afvragen hoe en in welke situatie de kwetsbaarheid wordt gedetecteerd. Waarom dat van belang is, is het goed om te kijken naar hoe Heartbleed werkt.

Werkwijze Heartbleed

Heartbleed maakt gebruik van een ontbrekende lengte-controle in de OpenSSL code-afhandeling van een relatief onschuldige uitbreiding van het tsl/ssl-protocol (gedefinieerd in RFC 6520). Het gaat om twee simpele berichten: een verzoek en een antwoord. Dit verzoek kan door zowel de client als de server worden verstuurd om de connectie in stand te houden. De verzender stuurt een Heartbeat-message met een klein data-pakketje, in verwachting dat de ontvanger diezelfde data terugstuurt. Belangrijk hierbij is dat degene die het bericht verstuurt de omvang van het antwoord bepaalt. De verzender geeft aan de ontvanger door hoeveel dat hij verstuurt en hoeveel hij dus terug verwacht.

De OpenSSL-code zou ervoor moeten zorgen dat de lengte die de aanvaller zegt te versturen daadwerkelijk beschikbaar is. Maar dat doet de code dus niet. Hij vertrouwt de verzender simpelweg en pakt gewoon de hoeveelheid data uit het geheugen. Op die manier kan een aanvaller toegang krijgen tot data in het geheugen en dus informatie als wachtwoorden en sleutels.

Bescherming

Aangezien Heartbleed gebruik maakt van een kwetsbaarheid in versleutelde communicatiepaden moet de oplossing ook daarin worden gerealiseerd. Er zijn drie punten waar je dat kan doen.
1. Client – Je kunt het client-os en apparatuurtype controleren en dit afzetten tegen het bekende gebruik van de geraakt OpenSSL versies. Eenmaal gedetecteerd kan een client blijvend afgewezen worden, zodat het kwaadwillende verzoek sowieso niet gestuurd wordt. Echter, een client afwijzen omdat het mogelijk een kwaadwillende is, kan resulteren in boze, legitieme gebruikers, klanten of andere relaties.
2. Request – Inspecteer client-verzoeken en wijs het af, zodra een Heartbeat-message wordt ontdekt. Dit voorkomt dat de verzoeken worden doorgestuurd naar kwetsbare systemen en servers.
3. Response – Onderzoek antwoorden, en zodra er een Heartbeat-message tussenzit, controleer de lengte. Als die groter is dan wenselijk of gebruikelijk, negeer het. Op die manier ontvangen aanvallers niet je data, maar zijn inmiddels je servers en data wel blootgesteld.

De juiste plek om bescherming te implementeren is de plek die je een keuze biedt tussen verschillende oplossingen. Of op alledrie de punten als je echt helemaal dichtgetimmerd wil zijn. In de meeste gevallen zal de application delivery firewall of application delivery controller de meest strategische plek zijn. De juiste oplossing staat echter niet alleen op de juiste plek in het netwerk. Het zorgt ook voor zichtbaarheid en programmeerbaarheid van de netwerk-stack en is in staat data te vinden die wijzen op een lek, bewust of onbewust.

Een goede tool maakt onderscheid in client en server verkeer en past de benodigde logica toe. De logica die Heartbleed aan de client-kant ontdekt is anders dan die aan de server-kant. In geval van de client moet het op zoek gaan naar een specfiek bericht gericht op een Heartbleed-verzoek, of de omgeving van het client-apparaat onderzoeken. Aan de server-kant moet het de grootte van de response controleren. Elk geval vraagt om zijn eigen, unieke code. De tool moet dus een programmeerbare omgeving hebben die zeer nauwkeurig de juiste logica kan toepassen op het juiste moment.

Nu Heartbleed een goede week zijn slag slaat moeten organisaties redelijkerwijs zicht hebben op de impact binnen hun bedrijf. Uiteraard zijn serverpatches en -upgrades noodzakelijk, en de toewijzing van nieuwe sleutels en wachtwoorden. Ondertussen blijven servers (en dus gebruikers) kwetsbaar. Bedrijven moeten dus direct in actie komen, terwijl er ook gewerkt moet worden aan een oplossing voor de langere termijn.