Mag ik mensen laten checken of hun OpenSSL aan Heartbleed lijdt?

heartbleed-bug-openssl-securityEen kritieke bug in beveiligingssoftware OpenSSL heeft het jarenlang mogelijk gemaakt om wachtwoorden en andere geheime data van servers te achterhalen. Voor hackers, maar ook de NSA, zo is gebleken. De pijnlijke fout, die Heartbleed is genoemd, is zeer wijdverspreid. Logisch dus dat mensen nu tools ontwikkelen om te zien of een site kwetsbaar is. Maar mag dat eigenlijk wel?

De kwetsbaarheid in de OpenSSL software zit hem in een stukje code dat wordt gebruikt om een beveiligde verbinding ‘open’ te houden. Om dat te doen, stuurt de client periodiek een signaal naar de server, die dan een korte reactie geeft. Een soort meten van de hartslag van de server; leeft hij nog? De reactie bestaat uit een kopie van het signaal, oftewel je herhaalt als server wat de client net tegen je zet (“Hallo?” “Hallo!” zeg maar).

Bij dat signaal staat hoe lang het is. En het probleem is dat de server dat opgegeven aantal bytes terugstuurt, ongeacht hoe lang de boodschap feitelijk was. Zeg je dus “64Hallo?” dan krijg je 64 tekens terug, waarvan de eerste vijf “Hallo?” zijn en de rest wat er toevallig in het servergeheugen staat. Dat kan dus van alles zijn, inclusief wachtwoorden en sessie-tokens van anderen. Zie ook deze xkcd. Daar gaat mijn hart ook wel even van bloeden ja.

Je site testen of deze kwetsbaar is, is dus zeer verstandig. Daar zijn tools voor, en natuurlijk is het volstrekt legaal dat te doen op je eigen site. Maar een hoop mensen willen ook testen of andere sites kwetsbaar zijn, bijvoorbeeld omdat ze daar hun webmail of andere belangrijke diensten hebben ondergebracht. Of omdat ze journalistiek nieuwsgierig zijn. Of omdat ze in willen breken. En daar ga je dan, juridisch: mág dat dan wel, andermans site testen op deze veiligheid?

Testen van een kwetsbaarheid is in theorie te zien als computervredebreuk. Het is van dezelfde orde als testen of iemands achterdeurslot met een balpen te openen is. Je dringt binnen in de server en verschaft je toegang tot gegevens waarvoor je niet geautoriseerd bent. Het gaat iets verder dan een portscan, waarbij je immers alleen maar legale verzoeken doet aan de server (“Dag, doet u aan POP3 of NTP?”) en de informatie die je dan krijgt, gebruikt om in te breken. Het testen op de Heartbleed-fout levert je meer informatie op dan de bedoeling is. Dus formeel ben je strafbaar.

Gezien de grote impact van de fout denk ik toch dat dit juridisch niet bezwaarlijk moet zijn. Wel moet je een duidelijk belang hebben bij het testen van die site én de beheerders op de hoogte stellen van de fout. Misbruik maken van de gevonden gegevens maakt het echt strafbaar.

Natuurlijk kun je zeggen, het is niet jouw taak om andermans websites te testen. Dat moeten ze zelf doen. Dat is ook zo. Alleen het teleurstellende feit is dat veel mensen dat gewoon niet dóen. En omdat ze daarmee ánderen in gevaar brengen (in tegenstelling tot dat achterdeurslot, waar ze alleen zelf last van hebben) vind ik het maatschappelijk verantwoord om dan toch aan de bel te trekken: “hoi, je bloedt andermans gegevens, dóe iets”.

Diverse mensen vroegen me ook of ze een site mogen opzetten die onderzoekt of een gegeven website kwetsbaar is (zoals Filippo). Ik denk dat dat wel mag, mits je de tool maar zo voorzichtig mogelijk opzet. Het liefst zegt hij alleen “ja/nee”, een datadump van wat de server lekt (bloedt?) laat zien, gaat echt te ver. En je zou nog een vertraging in kunnen bouwen. Eén site testen prima, twee of drie nou vooruit, maar wie twintig sites achter elkaar gaat testen is een beetje raar.

Helemaal netjes zou zijn dat je zegt, installeer eerst een bepaald bestandje op je website met een unieke naam, en dan controleert of dat bestandje bestaat op die website voordat je de test uitvoert. Dan weet je zeker dat de gebruiker aan de website gelieerd is. Maar dat voelt wat zwaar voor één korte test.

Arnoud

24 reacties

  1. Om dit te testen waarom zou je “64Hallo” moeten gebruiken? Een keer een test met “6Hallo” is genoeg om aan te kunnen tonen dat het lek aanwezig is en met dat ene extra teken van alleen deze ene test kan je weinig kwaadwillends.

      1. Je wilt het liefste iets meer karakters. Positie 6 zou 0 kunnen zijn omdat strings daar normaal gesproken mee eindigen.

        Als ik het goed begrijp is dat niet nodig, bij een gepatched systeem wordt de request genegeerd (silently discard) als er een grotere lengte opgegegeven wordt dan het bericht werkelijk lang is. Het feit dat je antwoord krijgt op ‘6hallo’ is dan dus al bevestiging dat je met een kwetsbaar systeem te maken hebt.

        http://git.openssl.org if (1 + 2 + 16 > s->s3->rrec.length) return 0; /* silently discard *

  2. Het is een misverstand dat Heartbleed alleen effect heeft op servers, ook clients zijn gevoelig voor het lekken van gevoelige data als ze een OpenSSL versie gebruiken die het Heartbleed lek vertoont.

    Kwaadwillende websites kunnen op deze manier ook bij hun klanten aan gevoelige informatie komen, denk vooral aan apparaten zoals verouderde Androidtelefoons of andere embedded toepassingen die OpenSSL gebruiken waar deze zwakheden optreden.

  3. Ik vraag me af… als je 64kB over de buffer-grootte heen kan gaan, en geheugensegmenten zijn meestal zo’n 4kB, dan moet je (als je “geluk” hebt) ook een segmentatie-fout kunnen veroorzaken op de server, door een kwetsbare server te testen op de heartbleed bug. Dan heb je meer gedaan dan een beetje nieuwsgierig kijken: je hebt potentieel een (web-)server offline gehaald.

    1. Die geheugenblokken worden dankzij virtuele paginering tot een groot geheugenblok samengevoegd en de software leest het virtuele geheugen. De hardware wordt niet direct benaderd. Dit betekent dat je rustig honderden megabytes aan data kunt opvragen. (Gigabytes op x64 systemen.) Vraag is alleen of het betreffende proces ook honderden megabytes heeft gealloceerd. Zoniet, dan vindt er een exception plaats want een proces kan alleen zijn eigen geheugen uitlezen. Virtueel geheugen wordt niet alleen gebruikt om bij beperkte RAM delen op schijf op te slaan maar ook om te voorkomen dat applicaties het geheugen in gatenkaas veranderen. Fysiek heb je dan kleine blokken kriskras over je RAM modules staan maar bij ophalen en wegschrijven voert de hardware een speciale mapping uit die ervoor zorgt dat de software hier niets van merkt.

    1. Dit valt mogelijk onder de persvrijheid.

      De “eerste versie” was trouwens niet door Fox-IT zelf naar buiten gebracht, maar door handige lezers op de server van Fox-IT teruggevonden. Er bestond ooit zowel http://foxitsecurity.files.wordpress.com/2014/04/heartbleed-example.png als http://foxitsecurity.files.wordpress.com/2014/04/heartbleed-example2.png, waarbij de eerste niet was geblurred, en Fox-IT naar de tweede linkte.

  4. “Daar gaat mijn hart ook wel even van bloeden ja” Heartbeat protocol, wat nu data lekt, heart-bleed 🙂

    https://tools.ietf.org/html/rfc6520 Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension

    Edit: The sender of a HeartbeatMessage MUST use a random padding of at least 16 bytes. The padding of a received HeartbeatMessage message MUST be ignored.

    Dat random is even mis gegaan…… (het ignoren ook)

  5. Toch is het maar de vraag hoe groot het risico uiteindelijk is. Een beetje server heeft toch al snel meerdere gigabytes in het geheugen en het stukje geheugen dat je uitleest komt uit het deel dat aan OpenSSL toebehoort. Geen idee of het uit de heap, de stack of gewoon uit het data segment afkomstig is wat je terugkrijgt. Natuurlijk, als je “abc123” in die data ziet staan dan is dat vast een wachtwoord. Maar welke account hoort daar vervolgens weer bij? De manier waarop moderne computers met geheugen omgaan levert ook enige bescherming op. Memory Protection is onderdeel van de meeste besturings-systemen en voorkomt dan je meer data kunt uitlezen dan wat het proces heeft gealloceerd. Daardoor kan de bug geen data uitlezen van andere processen. Alleen zijn eigen proces. Als je dus 100 MB wilt uitlezen en de data is maar 90 MB groot dan gaat het dus fout. (Mogelijk wel een methode om een DDOS uit te voeren.) Dus moet je redelijk kleine blokjes data opvragen en hopen dat er op dat moment net iets ‘lekkers’ in het geheugen staat. En die data dient vervolgens ook geanalyseerd te worden.

    Ja, het is mogelijk dat gevoelige gegevens zijn gelekt maar deze gegevens zijn ook nog eens uit het geheugen afkomstig. Als het al weken geleden is dat je een bepaalde Heartbleed-site hebt bezocht dan is het onwaarschijnlijk dat jouw informatie nog in het geheugen staan. En als je 24/7 de pagina bezoekt en informatie opvraagt dan is de kans groot dat de opgevraagde informatie deels ‘gejat’ kan worden omdat dit toevallig in het geheugen staat. Maar ja, als je 100 KB opvraagt en de hacker leest 50 KB uit, dan heeft hij misschien de helft van die informatie. Een tweede poging zal zelfs minder opleveren tenzij jij weer exact dezelfde informatie gaat opvragen.

    Ja, Heartbleed is een enorme blunder die enig risico met zich meebrengt. Maar sommigen zijn de risico’s volgens mij enorm aan het overdrijven…

    1. Toch is het maar de vraag hoe groot het risico uiteindelijk is.

      Enorm groot. Je kunt er zelfs de SSL private keys mee stelen van een site. Dat is echt heel ernstig omdat je daarmee aan het hart van internet security komt.

      Een beetje server heeft toch al snel meerdere gigabytes in het geheugen en het stukje geheugen dat je uitleest komt uit het deel dat aan OpenSSL toebehoort. Geen idee of het uit de heap, de stack of gewoon uit het data segment afkomstig is wat je terugkrijgt. Natuurlijk, als je “abc123? in die data ziet staan dan is dat vast een wachtwoord. Maar welke account hoort daar vervolgens weer bij?
      Bij het achterhalen van de private sleutels van een Cloudfare server werd de kwetsbare OpenSSL server 100.000 repsectievelijk 2,5 miljoen keer uitgevraagd door de (whitehat)hackers om de data van die private keys te pakken te krijgen. Koste de hackers maar een paar uurtjes om die private keys te pakken te krijgen.

      1. Je kunt er zelfs de SSL private keys mee stelen van een site.
        Klopt, maar dan moet deze wel op dat moment in het geheugen staan, net voorbij de locatie waar de data vandaan gehaald wordt. Deze moet bovendien als dusdanig herkenbaar zijn en je hebt de volledige key nodig, anders werkt hij niet. Ik zeg niet dat er geen risico is, maar dat het een kwestie van kansberekening is. De kansen worden groter naarmate de hacker meerdere pogingen onderneemt. Daarbij moet de server ook redelijk aktief blijven om te zorgen dat het geheugendeel steeds nieuwe data bevat. Anders krijgt de hacker 100.000 keer dezelfde data terug. Daarom is deze aanvalsvector minder succesvol als de server weinig in actie is. En ja, CloudFlare heeft onderzocht Hoe gevaarlijk het lek is en daarbij kwamen ze erachter dat ze best veel risico liepen. Maar CloudFlare is groot en vrij aktief waardoor de kans op gevaar toeneemt. Zeker bij een groot aantal pogingen waarbij steeds 65536 bytes worden bemachtigd. Maar zoals gezegd, er kan in die 64 KB van alles staan. Naast de private key en login credentials kun je er ook delen van email, webpagina’s en wat willekeurige data in aantreffen. Je moet de data nog wel eerst analyseren op wat het nou precies is.

        Ze moeten verder nog uitzoeken of je via de bug naar specifieke informatie kunt gaan vissen. En dan is het natuurlijk nog de vraag wie de hackers specifiek gaan aanvallen. Dit zullen voornamelijk Linux systemen zijn en Windows systemen met Apache of custom-made software die van OpenSSL gebruik maakt. Want Microsoft heeft geen OpenSSL gebruikt in hun Exchange en server software, en is dus ongevoelig! Apple is ook immuun maar Google blijkt wel geraakt te zijn door de bug maar heeft dit meteen gepatcht. Facebook en Yahoo bleken ook kwetsbaar.

        De sites zijn kwetsbaar omdat hun private keys gejat kunnen zijn. OpenSLL patchen en nieuwe private keys genereren is dan de oplossing. Hoe de betreffende key door hackers vervolgens misbruikt kunnen worden is ook lastig in te schatten. Een nepsite maken kan, en dan maar hopen dat bezoekers zien dat faceb00k.com nep is…

        Login gegevens zijn gevoeliger, maar de bug zal dan voornamelijk de meest recente login accounts bevatten. En dan nog alleen bij sites waar je steeds opnieuw moet inloggen. Facebook onthoudt of je in de vorige sessie was ingelogd, dus daar is het lekken van je account alweer een stuk minder. Bij de ING heb je mogelijk wel een probleem omdat je iedere sessie opnieuw moet inloggen. Het is niet helemaal duidelijk wat de ING gebruikt maar volgens mij gebruiken ze Microsoft servers en dan zijn ze immuun. En andere banken? Geen idee, maar als ze Linux gebruiken, dan zijn ze kwetsbaar.

        Natuurlijk zijn er risico’s. Maar hoe groot zijn die uiteindelijk? Groter of kleiner dan de kans dat ik de jackpot win in de Staatsloterij?…

        1. Veel groter. Persoonlijk heb ik in 100% van de pogingen vertrouwelijke informatie achterhaald met een heartbleed-test (met toestemming). Private SSL keys zijn zeldzamer, maar wachtwoorden en session cookies, waarmee sites dus onthouden dat je al ingelogd bent en waarmee je je dus kan doen als een andere gebruiker, komen erg vaak voor. En ook het analyseren is geen probleem: er zijn al scripts ontwikkeld die automatisch interessante informatie uit de response halen. Ook SSL private keys zijn heel eenvoudig herkenbaar, dus dit kan allemaal automatisch. En er worden geen logs achtergelaten, bruteforcen is geen probleem.

          De beste keuze is dan ook om alle informatie die de afgelopen twee jaar door een kwetsbare webserver is gelopen, te beschouwen als gecompromitteerd, en dit te vervangen.

  6. Is al duidelijk HOE deze code in OpenSSL is gekomen? Is het écht ‘slechts’ een bug? Of heeft een door (bijvoorbeeld) NSA betaalde programmeur dit in de code ingebracht zonder te zijn opgemerkt?

    1. Dat is moeilijk te zeggen. De version control logs zeggen dat een bepaalde Duitser de code heeft aangeleverd, en dat die is gereviewd door een (Britse) core-developer van OpenSSL. De Duitser beweert nu dat hij de fout per ongeluk heeft gemaakt.

      Afgaande op de code vind ik dat plausibel: het niet checken van de omvang van data is een fout die je in de C-programmeertaal erg makkelijk maakt. Aan de andere kant is dit natuurlijk geen “bewijs van onschuld”.

  7. Zou het doen van een dergelijke (oppervlakkige) test – bij een dienst waar je zelf gebruik van maakt – niet onder zaakwaarneming kunnen vallen, mits je een vermoeden hebt dat de kwetsbaarheid aanwezig zou kunnen zijn (een vermoeden dat mij redelijk lijkt gezien de reikwijdte van deze bug)?

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.