Tiradeweek: Oh, en iemand wijzen op een vulnerability is dus géén strafbaar feit

cant-hear-you-epo-eob-software-patent-octrooi.pngKondig je een tiradeweek aan, krijg je allemaal tips van mensen met dingen waar je tenen van gaan krullen: Stop checking our code for vulnerabilities, aldus de (inmiddels ex-) Chief Security Officer van Oracle. Het doet me denken aan de standaardreactie van wel meer bedrijven: je meldt een probleem, en de reactie is niet “oh dat was stom, het wordt gefixt” maar “uw handelen is strafbaar ex art. 138ab Strafrecht” en vervolgens niets doen met de melding.

Een bekend probleem ja, en iets dat met responsible disclosure opgelost zou moeten zijn. Maar het blijft rondzingen. En wat me vooral zo frustreert, is het onbegrip voor die mensen die met zo’n tip aan komen zetten. Alsof het normaal is om te zeggen “rot op met je tip, jij bent strafbaar”.

Kijk. Natuurlijk is het ergens gek dat iemand aan je raam rammelt en dan zegt “joh, weet je dat dat raam van je heel gammel is”. Of ineens in de keuken staat en zegt “jij moet écht een beter slot op je achterdeur nemen hoor, hier zijn trouwens je koekjes, je kelderluik moet ook nodig gepatcht”. In het normale leven gebeuren die dingen niet, afgezien van een enkele buurman die je erop wijst dat je deur open staat.

Dit is echter een van die weinige situaties waarin het internet écht anders is dan de echte wereld en vergelijkingen niet opgaan, ook niet met auto’s.

En de reden dát het anders is, is dat internetdiensten van de software aan elkaar hangen. En iedereen weet: software, dat is kwetsbare ellende die je elke dag moet bijwerken. Dat doet niemand, en daardoor hebben we steeds die puinhoop met hacks, datalekken, DDOS aanvallen en ga zo maar door. Er is ook – waarom mag Joost weten – geen wet die zegt dat je je systemen veilig moet inrichten zodat je geen digitale overlast aanricht.

Het is dus legaal om een lekke puinzooi online te zetten, er nul kwaliteitscontrole op te doen, gevaar voor jezelf en anderen te scheppen. En dan heb je mensen die als ze daar een tip over krijgen, reageren met dat de kláger strafbaar is. Sorry maar daar zakt mijn broek van af. Wat mij betreft is het vanaf nu verboden te dreigen met aangifte of rechtszaken tenzij je kunt aantonen je veiligheidszaakjes op orde te hebben.

Arnoud

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

Minister: geen aangifte tegen ‘ethische’ hackers

bug-disclosureMinister Opstelten van Veiligheid en Justitie wil niet dat bedrijven en organisaties aangifte doen tegen hackers met goede bedoelingen, die veiligheidsproblemen aankaarten, las ik bij Tweakers. In een brief aan de Tweede Kamer beschrijft hij dat het ‘de voorkeur’ heeft dat een bedrijf beleid ontwikkelt voor responsible disclosure en daarin verklaart geen aangifte te zullen doen als mensen conform dat beleid bugs op verantwoorde wijze komen melden. Creatief!

Om bedrijven te helpen zulk beleid te maken, heeft het NCSC een Leidraad om te komen tot een praktijk van Responsible Disclosure opgesteld. Deze beschrijft in voor mij heldere taal wat kwetsbaarheden zijn, waarom je meldingen daarvan via responsible disclosure wilt opvangen en hoe zo’n proces eruit moet zien.

Het proces is eigenlijk vrij simpel:

  1. De organisatie stelt een meldpunt op voor meldingen over kwetsbaarheden, en alloceert ook capaciteit om meldingen op te vangen en door te leiden naar de verantwoordelijke afdeling.
  2. Ontvangst van een melding wordt digitaal bevestigd, waarna organisatie en melder gaan overleggen over de verdere afhandeling.
  3. In dat overleg wordt een termijn afgesproken waarna de melder de kwetsbaarheid openbaar mag maken, bij voorkeur 60 dagen als het gaat om software en zes maanden bij hardware. (Want hardwarelekken zijn niet zo simpel te fixen.)
  4. Bij een niet of moeilijk op te lossen kwetsbaarheid (of bij hoge kosten) kan worden afgesproken geen disclosure te doen. Ik had graag gezien dat daar “in zeer uitzonderlijke gevallen” komt te staan, want de standaardzin van bedrijfsjuristen bij meldingen wordt nu “Vanwege de hoge kosten en het zeer moeilijk op te lossen karakter van deze kwetsbaarheid is het u verboden hiervan publicatie te doen.”
  5. De organisatie houdt de melder op de hoogte van de voortgang.
  6. De organisatie kan desgewenst de melder credits geven in het persbericht dat de fout gefixt is (of in de patch.)
  7. De organisatie kan een beloning of waardering geven voor een melding, mits men zich aan de spelregels houdt.
  8. De organisatie belooft in het beleid geen juridische stappen te nemen tegen de melder indien conform het beleid wordt gehandeld.

En ja, zo’n belofte is juridisch bindend, je kunt een bedrijf daarmee om de oren slaan als ze alsnog aangifte gaan doen of een kort geding tegen publicatie beginnen.

Wat houden die “conform het beleid”-spelregels nu in?

Allereerst moet de melder de melding doen bij de organisatie zelf, en wel op een vertrouwelijke manier. Ook moet dat zo snel mogelijk na ontdekking. En hij publiceert pas conform de afspraken hierboven.

Belangrijke vuistregel voor de melder is “niet op onevenredige wijze te handelen”. Zo is social engineering categorisch uitgesloten – we wéten immers al dat mensen eenvoudig te hacken zijn. Ook brute forcen mag niet (hoi Nieuwe Revu) want dat gaat niet over kwetsbaarheden.

Meer specifiek mag er niet meer worden gedaan dan strikt nodig om de kwetsbaarheid aan te tonen. Je mag bijvoorbeeld geen backdoors installeren, of gegevens aanpassen, kopiëren of verwijderen. Wil je bewijzen dat je van alles kunt lezen, lees dan een directory; wil je bewijzen dat je kunt schrijven, maak dan een nieuw leeg bestand aan. En toegang delen met je vrienden mag ook niet.

Hoewel ik hierboven een tikje cynisch klink soms, moet ik zeggen dat ik het een mooi initiatief vind. En de regels klinken ook logisch en werkbaar voor een bona fide organisatie. Natuurlijk is er ruimte voor misbruik of te kwader trouw inzetten van de regels, maar het is een hele verbetering ten opzichte van het grijze gebied dat er nu is.

Ik denk dat wij een (gratis) generator gaan bouwen voor RD-beleid. Wat zou er volgens jullie zeker in moeten? Missen jullie nog dingen?

Arnoud

Heel internet stukmaken, mag dat? (2)

Internet stukmaken kan op heel veel manieren. En nu hebben we er weer eentje: met een paar slim gekozen TCP/IP pakketten is het mogelijk om vrijwel elke op internet aangesloten computer plat te leggen, meldt Webwereld.

Bijzonder aan deze aanval is dat hij kennelijk al jaren bekend was bij ontdekkers Outpost24. Men komt echter nu pas naar buiten, omdat er nog steeds geen oplossing voor is en de aandacht misschien mensen stimuleert om deze te gaan zoeken. Op 17 oktober zullen de ontdekkers de aanval demonstreren, maar geen diepe technische details geven.

En dat was waar een lezer me over mailde: zouden ze die wel mogen geven eigenlijk? Met die details kan iedereen aan de slag om een exploit te maken en systemen platleggen. Niemand die dat kan stoppen, want er is dus geen oplossing bekend. Dat lijkt nogal onverantwoordelijk. Maar is het strafbaar?

Als ik de artikelen goed begrijp, dan gaat het hier om een vorm van denial of service, een aanval waarbij de toegang tot een geautomatiseerd werk wordt belemmerd door bepaalde gegevens op te sturen. Dat is strafbaar onder artikel 138b Wetboek van Strafrecht. De meeste mensen denken bij een DoS-aanval vooral aan grote hoeveelheden onzingegevens zoals bij mailbommen of pingfloods. Maar ook een enkel slim gekozen pakketje valt onder deze strafbepaling (winnuke’t u nog wel eens iemand?).

Ook strafbaar is het om technische hulpmiddelen aan te bieden die “hoofdzakelijk geschikt gemaakt of ontworpen” zijn om een DoS-aanval mee uit te voeren (art. 139d lid 2 sub a Strafrecht). Bij diefstal van diensten bepaalde de Hoge Raad in 2005 dat een tijdschrift met een stappenplan een verboden hulpmiddel was (om gratis Canal+ te mogen kijken). Maar dat ging alleen goed omdat artikel 326c van het Wetboek van Strafrecht spreekt van het aanbieden van een “voorwerp en/of gegevens”. En een tijdschrift bevat gegevens, zo oordeelde de Hoge Raad.

Artikel 139d lid 2 spreekt van een “technisch hulpmiddel”, wat mij toch een stuk beperkter lijkt dan “een voorwerp of gegevens”. Valt een proof of concept exploit, een stuk code dat laat zien dat een aanval echt mogelijk is, daar nu onder? Het is een hulpmiddel, maar is het geschikt gemaakt of ontworpen om ook werkelijk aanvallen mee uit te voeren? En dan dus niet demonstratie-aanvallen in het lab, maar echte aanvallen in het wild.

Ik vind het een erg lastige vraag. Het gaat me wat ver om code ter ondersteuning van beveiligingsonderzoek strafbaar te stellen. Aan de andere kant, als die code uitlekt hebben alle script kiddies ook weer maandenlang plezier met het platleggen van internet en dat is ook bepaald onwenselijk.

Wat vinden jullie? Mag die code worden gepubliceerd, of moeten ze daarmee wachten tot iedereen gepatcht is? En maakt het daarbij uit dat dit een fout met een heel brede impact is, in tegenstelling tot een eenvoudige buffer overflow in versie X van één bepaald stuk software?

Arnoud

Verantwoord hacken van beveiligingen is legaal

Tweakers in de bocht: het testteam van Tweakers haalt de biometrische USB-stick BioSlimDisk Signature volledig uit elkaar, en ontdekt hoe men de beveiliging voor de gek kan houden. Ze deden dat al eens eerder trouwens. Maar het gaat me deze keer om hoe men omging met de bevindingen:

De lezer zal begrijpen dat we wederom verrukt waren met het resultaat; weer een stick bezweken. Zoals de regels van responsible disclosure vereisen, hebben we uiteraard voor publicatie contact opgenomen met de leverancier. De Nederlandse importeur verwees ons direct door naar de fabrikant. Deze nam vanuit het hoofdkantoor in Singapore contact op.

De fabrikant wilde de hack wel erkennen, maar gaf direct aan dat Tweakers.net een prototype getest had, een prototype dat niet op de markt zal verschijnen. In de definitieve stick zouden extra beveiligingen zijn aangebracht die de door ons uitgevoerde hack zouden moeten voorkomen.

En zo hoort het. Het is in Nederland toegestaan om de beveiliging te testen van je eigen apparatuur. Er zijn uitzonderingen, zoals het aanpassen van regio-restricties of het omzeilen of uitschakelen van kopieerbeveiligingen. En andermans systeem hacken “om de beveiliging te testen” mag natuurlijk niet zonder toestemming.

De interessante vraag is natuurlijk, wat mag je met het resultaat? Je hebt natuurlijk recht op vrije meningsuiting, ook (juist!) voor maatschappelijk relevante zaken als een onveilig systeem. Vandaar dat zo vaak gepleit wordt voor full disclosure: publiceer alle details over beveiligingsfouten, zodat iedereen er rekening mee kan houden.

Een nadeel van full disclosure is dat ook kwaadwillenden meteen leren van de fouten, en er gebruik van kunnen maken terwijl de fabrikant nog bezig is met de reparatie. Dat pleit dan weer voor geheimhouding. Alleen, ervaringen uit het verleden leren dat niet alle leveranciers even snel aan de slag gaan met gemelde beveiligingsfouten. Full disclosure is voor een deel dan ook een reactie op deze praktijk: publicatie dwingt de leverancier zo snel mogelijk aan de slag te gaan en met een reparatie (bug fix) te komen.

Een tussenvorm is responsible disclosure: geef de leverancier of fabrikant een redelijke tijd om de fout te repareren, en houd de fout geheim zolang er uitzicht is op een snelle reparatie. Blijkt de leverancier onwillig of duurt het onredelijk lang om tot een oplossing te komen, dan publiceer je de fout zodat mensen in ieder geval weten dat het probleem bestaat, en ze een lapmiddel kunnen verzinnen.

Hoe dan ook, publicatie van zulke resultaten mag. Een dergelijke publicatie moet wel duidelijk gericht zijn op een wetenschappelijk of journalistiek doel, en rekening houden met de redelijke belangen van de fabrikant. De publicatie mag niet ontaarden in een recept of instructies om het systeem te kraken, want dat dient geen legitiem doel en is er vooral op gericht de fabrikant schade toe te brengen. En dat mag niet.

Kortom, doe het zoals Tweakers

Wat overigens helaas niet uitsluit dat je toch juridische problemen tegen kunt komen. Dat ondervond Fox-IT bij het testen van een serie beveiligde USB-sticks. De bedrijven wier producten slecht uit de tests kwamen, begonnen over “smaad” en “reputatieschade”, en dreigden met advocaten. De bedrijven in kwestie hadden het rapport trouwens nog niet gezien toen een van de wel succesvolle firma’s al met een juichend persbericht naar buiten kwam. Dat was inderdaad niet zo netjes. De bedrijven allemaal op de hoogte houden is dus wel belangrijk.

Arnoud