Hagenaar die datalek in CBG-database ontdekte ontloopt straf
Een 45-jarige Hagenaar die zich in 2015 toegang verschafte tot een database van het Centraal Bureau voor Genealogie (CBG) en daar via een script 80.000 records met allerlei persoonsgegevens kopieerde hoeft geen werkstraf uit te voeren, zo heeft de rechtbank Den Haag bepaald.
De man ontdekte in het robots.txt bestand van de CBG-website de regel "disallow: / pictura.php # toegang tot de vriendendatabase". Websites kunnen via het robots.txt-bestand aan zoekmachines laten weten welke onderdelen niet moeten worden geïndexeerd. Via het pictura-script was het mogelijk om individuele records uit de CBG-database op te vragen. Hiervoor moest het ID van een record worden opgegeven.
Na ontdekking van het pictura-script ging de Hagenaar structureel te werk om te achterhalen welke ID's een record opleverden. Vervolgens schreef hij een script waarbij alle 80.000 records uit de CBG-database werden gekopieerd. De records bleken namen, adressen, bankgegevens en betalingsgegevens te bevatten. Hierop informeerde de Hagenaar het online klokkenluidersplatform PubLeak, Trouw, Tweakers.net en De Volkskrant over het datalek. Het Centraal Bureau voor Genealogie waarschuwde hij niet.
Geen echte beveiliging
Volgens de advocaat van de man was er geen sprake van echte beveiliging, dus kon die ook niet door de verdachte worden doorbroken. De rechter was het daar niet mee eens: "Van wederrechtelijk binnendringen in een geautomatiseerd werk is sprake als men zich de toegang verschaft tot dat werk tegen de onmiskenbare wil van de rechthebbende. Die wil kan blijken uit woorden en daden, maar in ieder geval moet die blijken uit enige beveiliging van dat werk, ofwel een kenbare drempel zodat onbevoegden zich niet zomaar de toegang daartoe kunnen verschaffen. De beveiliging hoeft niet adequaat te zijn; een minimale beveiliging is voldoende. Het gaat erom dat degene die het werk binnendringt, doelbewust enige inspanning moet hebben gedaan om de beveiliging te doorbreken."
De beheerder van de CBG-website had via de regel "disallow" in het bestand robots.txt aangegeven dat het pictura-script niet gevonden moest worden. Daarnaast stond er vermeld dat het om een vriendendatase ging. Volgens de rechter ligt het voor de hand dat de beheerder die niet met derden wil delen. Toch heeft de Hagenaar het pictura-script opgevraagd en vervolgens allerlei ID's geprobeerd. "Hiermee moet voor de verdachte nogmaals duidelijk zijn geweest dat het niet de bedoeling van de beheerder was dat pictura.php en de achterliggende database door derden werd opgevraagd. Wie immers een ID moet invoeren om gegevens te kunnen raadplegen, terwijl hem dat ID niet door een rechthebbende is verstrekt en hij daarnaar dus moet raden, moet begrijpen dat de raadpleging van die gegevens niet voor hem is bedoeld", zo laat de rechter weten.
Verder stelde de rechter dat de man met behulp van "valse signalen" was binnengedrongen. "Van valse signalen is sprake als "enig teken" wordt gegeven dat bij de ontvanger een gevolg bewerkstelligt dat gebaseerd is op (geprogrammeerde) veronderstellingen die onjuist blijken te zijn, terwijl degene die het teken geeft, weet dat hij met dat teken dat gevolg uitlokt", aldus het vonnis. De rechter kon zich echter niet vinden in de opvatting van het Openbaar Ministerie dat er sprake was van binnendringen met een "valse sleutel". Het invoeren van een ID is namelijk niet te beschouwen als een vorm van autorisatie of als een manier om in te loggen.
Vonnis
De advocaat van de man verklaarde dat zijn cliënt zich had beziggehouden met "ethisch hacken" en dat de verdachte met zijn handelen een maatschappelijk belang heeft gediend, namelijk de beveiliging van persoonsgegevens. De rechter stelde dat de man met het ontdekken van het datalek inderdaad een maatschappelijk belang heeft gediend. De manier waarop hij handelde was echter niet proportioneel. Daarnaast had hij ook eerst het Centraal Bureau voor Genealogie moeten waarschuwen.
Het Openbaar Ministerie had een werkstraf van 120 uur geëist, waarvan 60 uur voorwaardelijk. De rechter besloot de Hagenaar echter geen straf op te leggen. De man had geen kwade bedoelingen en heeft de verkregen persoonsgegevens niet voor eigen gewin gebruikt. Tevens heeft de verdachte vanaf het begin van het opsporingsonderzoek openheid van zaken gegeven. De rechtbank hield er daarnaast ook rekening mee dat de behandeling van de strafzaak de redelijke termijn heeft overschreden en de man voor en na het incident niet in aanraking met de politie is gekomen. "Gelet op al het voorgaande acht de rechtbank oplegging van een sanctie passend noch geboden", zo laat het vonnis weten.
1e partij: de aanbieder van een dienst. 2e partij: de afnemer van die dienst (klant). 3e partij: ieder andere,
1e partij: de aanbieder van een dienst. 2e partij: de afnemer van die dienst (klant). 3e partij: ieder andere,
Ja een zoekmachine is een derde partij maar dat wil niet zeggen dat omdat een zoekmachine wordt uitgesloten, meteen iedereen zou moeten worden uitgesloten...
Een appel is fruit, maar niet elk fruit is een appel...
Erg jammer weer dit
https://www.ncsc.nl/actueel/nieuwsberichten/leidraad-responsible-disclosure.html
1e partij: de aanbieder van een dienst. 2e partij: de afnemer van die dienst (klant). 3e partij: ieder andere,
Een zoekmachine is een derde partij, maar niet iedere derde partij is een zoekmachine. Als zoekmachines gevraagd wordt een pagina niet te indexeren geldt dat dus niet sluitend of dwingend voor overige derden. Die zouden eruit kunnen afleiden dat ze niet welkom zijn, maar dat is zeker niet de enige redelijke gevolgtrekking.
1e partij: de aanbieder van een dienst. 2e partij: de afnemer van die dienst (klant). 3e partij: ieder andere
Het feit dat je iets in een disallow regels zet voor zoek machines, is geen juridische boodschap dat het bestand niet benaderd mag worden (door anderen dan crawlers).
Moet je eens kijken hoeveel ''normale'' pagina's van websites die je gewoon bezoekt op disallow staan in een robots.txt
Hieronder een voorbeeld van Bol.com - denk je dat dit een verbod is voor klanten om bij een bestelling de checkout pagina te bezoeken ? Of een verbod om je account pagina, je winkelwagentje, of je verlanglijstje te bekijken ?
# Sitemap
Sitemap: https://www.bol.com/sitemap/products_weekly-index.xml
Disallow: /intershoproot/
Disallow: /sdd/
Disallow: /*/rnwy/account/
Disallow: /*/account/
Disallow: /*/checkout/
Disallow: /*/wishlist/
Disallow: /*/order/
Disallow: /*/personalization/
Disallow: /*/imagesnoindex/
Disallow: /*/ebooks/
noindex: /*/inwinkelwagentje.html*
Disallow: /*/inwinkelwagentje.html*
Disallow: /*/verlanglijstje/verlanglijstje.html*
Disallow: /*/verlanglijstje/*/index.html
Disallow: /*/m/service/mini-verjaardag-aanmelden/index.html
Disallow: /*/m/service/mini-verjaardag-bedankt/index.html
Disallow: /*/service/schrijf-een-recensie.html*
Disallow: /*/bltg/*
Het is een rule om te voorkomen dat deze pagina's direkt in de zoekmachine terecht komen - ook al is het de bedoeling dat je de pagina's, vanaf de Bol.com portal, wel kan bezoeken. Anders wordt het bestellen van hun produkten immers onmogelijk.
In sommige gevallen is het wel wenselijk dat je vanaf de website een pagina bezoekt, die op ''disallow'' staat in robots.txt, en in andere gevallen weer niet.
Volgens de redenatie hier, zou het bezoeken van deze Bol.com pagina's ongewenst, en illegaal zijn ?
Tegenwoordig zoekt het meerendeel van de mensen met een zoekmachine naar informatie op diverse sites. De gedachte dat als een zoekmachine een bepaalde URL niet mag indexeren, zou dus best wel de conclusie op kunnen leveren dat die URL door niemand gevonden zou horen te worden.
De rechter heeft gewoon de dagelijks praktijk meegenomen in zijn oordeel.
Peter
Als hij normaal te vinden is kan de "ontdekking" van de pagina nooit het probleem zijn, terwijl het lezen van robots.txt misschien al gerekend kan worden onder "enige moeite doen".
Het is niet meer dan een bordje “Crawlers worden verzocht hier niet te komen”.
De man is geen crawler. En al was hij een crawler dan is het nog niet verboden om de pagina te bezoeken.
Robots.txt is ook nooit bedoelt om pagina’s uit de zoekmachine te verwijderen. Dit is van de Google Search Console Help pagina: “You should not use robots.txt as a means to hide your web pages from Google Search results.”
Tegenwoordig zoekt het meerendeel van de mensen met een zoekmachine naar informatie op diverse sites. De gedachte dat als een zoekmachine een bepaalde URL niet mag indexeren, zou dus best wel de conclusie op kunnen leveren dat die URL door niemand gevonden zou horen te worden.
De rechter heeft gewoon de dagelijks praktijk meegenomen in zijn oordeel.
Peter
Los van het feit dat dit geen responsible disclosure was, had de rechter m.i. (tevens) ook kunnen oordelen dat het bestand onvoldoende (niet) beveiligd was.
De beheerder in kwestie wilde niet dat het bestand in zoek machines terecht kwam en heeft daarom een entry in robots.txt opgenomen. Hieruit zou kunnen blijken dat de beheerder dus wist dat dit bestand niet beveiligd was. Waarom zou je deze entry anders opnemen in robots.txt?
M.i. dus ook nalatigheid van de beheerder.
Vrij vertaald in de fysieke wereld: Je laat je deur van je woning open staan (bestand), plakt een briefje op de deur dat zegt dat inbrekers niet naar binnen mogen (robots.txt) en je gaat op vakantie. Vervolgens lees je in de media dat er spullen uit je woning gestolen zijn. Mening verzekeringsmaatschappij zal vermoedelijk niks uitkeren (rechter). i.v.m. nalatigheid.
Punt dat ik hier wil maken is dat ondanks dat deze "hacker" zich niet heeft gehouden aan de responsible disclosure voorwaarden, er ook best gekeken mag worden naar het bedrijf in kwestie. Zij zijn m.i. immers nalatig geweest.
Een boete opleggen wegens het onvoldoende (niet) beveiligen en daardoor dus lekken van gevoelige informatie zou een goede start zijn om bedrijven wat actiever met IT beveiliging bezig te laten zijn.
In dit soort situaties wordt vaak gekeken naar de aanvaller(s) omdat zij verkeerd zijn geweest. Het "target" (bedrijf) wordt vervolgens vaak gezien als het zielige slachtoffer.
M.i. moet hier e.e.a. veranderen, het "zielige slachtoffer" had wellicht beter zijn/haar best moeten doen om er voor te zorgen dat aanvallers dit bestand niet zonder authenticatie hadden kunnen gebruiken om data te extracten.
In dit soort situaties wordt vaak gekeken naar de aanvaller(s) omdat zij verkeerd zijn geweest. Het "target" (bedrijf) wordt vervolgens vaak gezien als het zielige slachtoffer.
M.i. moet hier e.e.a. veranderen, het "zielige slachtoffer" had wellicht beter zijn/haar best moeten doen om er voor te zorgen dat aanvallers dit bestand niet zonder authenticatie hadden kunnen gebruiken om data te extracten.
Ik ben het daar niet mee eens. Ik denk dat er juist moet veranderen dat mensen die zielige slachtoffers aanvallen
streng aangepakt worden. Als je oma over straat loopt en beroofd wordt van haar portemonnee en sieraden dan
ga je ook niet roepen dat ze zich maar beter had moeten beveiligen als ze over straat ging omdat ze kon weten dat
ze anders overvallen zou worden.
Het "goed beveiligd zijn" is een glijdende schaal, dat blijkt ook wel uit de comments in dit topic. De mensen hier die weten
het allemaal heel goed en vinden de beheerders van alle sites ter wereld allemaal slecht, maar de realiteit is dat wat
ooit als redelijk beveiligd gezien werd nu ineens slecht- of niet beveiligd zou heten. Net als je oma wil niet iedereen
mee doen in die rat-race, en om die dan allemaal maar zielig te noemen dat gaat echt te ver.
In dit soort situaties wordt vaak gekeken naar de aanvaller(s) omdat zij verkeerd zijn geweest. Het "target" (bedrijf) wordt vervolgens vaak gezien als het zielige slachtoffer.
M.i. moet hier e.e.a. veranderen, het "zielige slachtoffer" had wellicht beter zijn/haar best moeten doen om er voor te zorgen dat aanvallers dit bestand niet zonder authenticatie hadden kunnen gebruiken om data te extracten.
Ik ben het daar niet mee eens. Ik denk dat er juist moet veranderen dat mensen die zielige slachtoffers aanvallen
streng aangepakt worden. Als je oma over straat loopt en beroofd wordt van haar portemonnee en sieraden dan
ga je ook niet roepen dat ze zich maar beter had moeten beveiligen als ze over straat ging omdat ze kon weten dat
ze anders overvallen zou worden.
Het "goed beveiligd zijn" is een glijdende schaal, dat blijkt ook wel uit de comments in dit topic. De mensen hier die weten
het allemaal heel goed en vinden de beheerders van alle sites ter wereld allemaal slecht, maar de realiteit is dat wat
ooit als redelijk beveiligd gezien werd nu ineens slecht- of niet beveiligd zou heten. Net als je oma wil niet iedereen
mee doen in die rat-race, en om die dan allemaal maar zielig te noemen dat gaat echt te ver.
De beheerders zijn niet slecht, het zijn de bedrijven die geen security audits doen maar wel (gevoelige) persoonsgegevens verwerken. Dat is m.i. een steeds groter probleem aan het worden en juist dat zou moeten worden aangepakt. Daar zijn reeds wat verbeteringen doorgevoerd (AVG) maar de uitvoer hiervan is op dit moment onduidelijk.
Het bestand welke deze data toonde was niet beveiligd en kon direct worden gequeried middels een identifier. Juist daarom zou dit m.i. bestraft moeten worden. Het verwerken van (gevoelige) persoonsgegevens maar deze niet beveiligen.
In het geval dat niet iedereen "mee wilt doen in die rat-race", moeten ze dit soort gegevens niet verwerken en door een ander laten doen die er wel goed mee om kan gaan. Het gaat hier tenslotte om gegevens van derden welke niet beveiligd waren.
Persoonlijk zou ik het nog wel een stap verder willen brengen: het verplichten van minimaal twee security audits per jaar indien er (gevoelige) persoonsgegevens worden verwerkt.
In dit soort situaties wordt vaak gekeken naar de aanvaller(s) omdat zij verkeerd zijn geweest. Het "target" (bedrijf) wordt vervolgens vaak gezien als het zielige slachtoffer.
M.i. moet hier e.e.a. veranderen, het "zielige slachtoffer" had wellicht beter zijn/haar best moeten doen om er voor te zorgen dat aanvallers dit bestand niet zonder authenticatie hadden kunnen gebruiken om data te extracten.
Ik ben het daar niet mee eens. Ik denk dat er juist moet veranderen dat mensen die zielige slachtoffers aanvallen
streng aangepakt worden. Als je oma over straat loopt en beroofd wordt van haar portemonnee en sieraden dan
ga je ook niet roepen dat ze zich maar beter had moeten beveiligen als ze over straat ging omdat ze kon weten dat
ze anders overvallen zou worden.
Het "goed beveiligd zijn" is een glijdende schaal, dat blijkt ook wel uit de comments in dit topic. De mensen hier die weten
het allemaal heel goed en vinden de beheerders van alle sites ter wereld allemaal slecht, maar de realiteit is dat wat
ooit als redelijk beveiligd gezien werd nu ineens slecht- of niet beveiligd zou heten. Net als je oma wil niet iedereen
mee doen in die rat-race, en om die dan allemaal maar zielig te noemen dat gaat echt te ver.
Ik vind dat als je er een bedrijfsvoering op na houdt, en deze efficient wil verijken met allerlei IT tools die beschikbaar zijn, je eerst eens de gebruikshandleiding van die " Tools ", moet gaan lezen voordat je die gereedschappen gaat implementeren. Vooral als het beoogde doel extern naar het " publiek " gericht wordt, en al helemaal als je privacygevoelige gegevens erbij betrekken wilt.
Het is gewoon slordigheid geweest, en geen onkunde, want ze nemen die site beheerders speciaal aan voor dit soort taken. Je wou daar op die positie zitten hoog en droog, dan moet je daar ook capabel voor zijn, en niet zeuren als je op de blaren moet zitten achteraf als blijkt dat je zo'n script niet goed kan programmeren. Van mij had dat bedrijf boetedoening moeten doen, en niet die hacker die duidelijk ethisch aan het hacken was. Als het een echte hacker was geweest had je namelijk nooit iets van die actie gehoord, en had er nooit iemand iets van geleerd. Nu staat een kleine partij in het strafbankje voor de fout die een grote partij gemaakt heeft. Deze uitspraak is een omgekeerde wereld, en het is niet eerlijk.
Lang verhaal kort te houden, ze zouden in de rechtsspraak wat meer Jip en Janneketaal moeten gebruiken, want feit is gewoon dat die website niet goed beveiligd was, en dat was de verantwoordelijkheid van dat bedrijf/vereniging/stichting. Punt uit. En dat bedrijf had in het strafbankje moeten zitten.
Sterker nog, je lekt daarmee opzettelijk gegevens naar buiten toe alsof je met Paaseieren zoeken zegt "Kijk vooral niet achter de kast ...."
[...]
In dit soort situaties wordt vaak gekeken naar de aanvaller(s) omdat zij verkeerd zijn geweest. Het "target" (bedrijf) wordt vervolgens vaak gezien als het zielige slachtoffer.
Om bij je analogie te blijven, als je je huis met een briefje "beveiligt" terwijl je op vakantie bent is iemand die iets uit je huis steelt nog steeds strafbaar. De verzekeringsmaatschappij zal mogelijk inderdaad niets uitkeren, maar als de dader gepakt wordt dan zit het er dik in dat de de strafrechter hem zal veroordelen voor insluiping en diefstal.
Dat die website niet goed beveiligd was is evident. Aangezien er een gegevenslek heeft plaatsgevonden is te hopen dat ze dat aan AP en de betrokkenen hebben gemeld en maatregelen hebben genomen om het lek te dichten. Maar daar ging dit bericht niet over, dit ging over de strafzaak tegen degene die het aan het licht bracht en dat weer niet goed aanpakte.
Erg jammer weer dit
https://www.ncsc.nl/actueel/nieuwsberichten/leidraad-responsible-disclosure.html
Iedereen kan gebruik maken van responsible disclosure als je een zwakheid ontdekt in een website. Ongeacht of een responsible disclosure procedure heeft ingericht. Gaat er wel om hoe ver je gaat in het uitbuiten van een zwakheid. Lees de stof maar eens goed over dit onderwerp
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
