Lek in Kamernet gaf toegang tot 1,3 miljoen privéberichten

De Nederlandse student Nelson Berg, die eerder lekken vaststelde bij de HvA en UvA, heeft een lek gevonden in de site van Kamernet. Zo was het mogelijk om 1,3 miljoen privéberichten in te zien, bijvoorbeeld die tussen potentiële huurders en verhuurders zijn verstuurd.

Berg heeft zijn bevindingen gepubliceerd op zijn eigen blog. Daar schrijft hij dat hij het lek ontdekte doordat hij op zoek was naar een kamer in Amsterdam. Hij kwam erachter dat het mogelijk was om via de Messages-api berichten met een id op te vragen die niet aan hemzelf toebehoorden, waardoor toegang tot de privéberichten van anderen mogelijk was. Door een script te schrijven dat elk tienduizendste bericht opvroeg, kon hij uitkomen op een schatting van 1,3 miljoen berichten. Een woordvoerder van Kamernet bevestigt deze inschatting tegenover Tweakers.

Berg legt uit dat hij weinig kan zeggen over de inhoud van de berichten. "Veel mensen proberen zich op die manier te introduceren en daarom staat er vaak persoonlijke informatie in. Daar kunnen bijvoorbeeld contactgegevens tussen zitten, als deze zijn uitgewisseld." Ook zouden er foto's inzichtelijk zijn geweest, al zegt de woordvoerder van Kamernet dat niet elk profiel van een foto is voorzien. Hij zegt verder dat het lek binnen een half uur na de melding was opgelost.

"Nadat de melding binnen was, hebben wij ons hele devteam van hun taken afgehaald om hiernaar te kijken en te zoeken naar vergelijkbare lekken", aldus de woordvoerder. Door de logs zo ver mogelijk terug te controleren zou zijn gebleken dat behalve Berg zich niemand anders toegang tot de gegevens had verschaft. Het lek is inmiddels gemeld aan de Autoriteit Persoonsgegevens. Door de aard van de hack en het gebrek aan negatieve intenties ziet Kamernet op dit moment geen noodzaak om het lek aan de getroffen gebruikers te melden.

Hoewel Kamernet geen bug bounty-programma heeft, is dit volgens de woordvoerder wel iets waar momenteel over na wordt gedacht. Over een mogelijke beloning aan Berg zegt hij: "We weten dat hij een kamer zoekt in Amsterdam, dus mogelijk kunnen wij daarin iets betekenen." Berg ontdekte eerder lekken in het studenteninformatiesysteem van de HvA en UvA. Daardoor waren gegevens van meer dan 500.000 studenten toegankelijk.

Reacties (71)

[beyazz06]

Hier de post op zijn eigen blog waarin hij wat meer uitleg geeft over hoe&wat:
https://binaryit.net/disclosures/kamernet/

[Reactie gewijzigd door beyazz06 op 26 juli 2024 20:10]

[emnich]

En weer gaat Nelson verder dan hij zou moeten. Het constateren dát het mogelijk is om een ander bericht op te halen is voldoende. Je hoeft niet te gaan bepalen om hoeveel berichten het dan precies gaat en/of wat er dan in staat.

Maar ik snap dat het commercieel en voor de berichtgeving leuker is om grote getallen te kunnen noemen.

[Kecin]

Dat heeft die wel eens erger gedaan. Volgens mij heeft hij het tijdig aangegeven aan Kamernet die hem zeer dankbaar lijken te zijn.
Ook heeft hij elk 10.000e bericht gescanned, dus niet élk ID.

Uiteindelijk had het efficiënter gekund, maar zolang je maar transparant blijft en het niet doorzend naar andere partijen is er niets aan de hand. Hij had het ook kunnen laten liggen en de data onnodig voor iedereen open te laten staan (door het niet te melden).

Het noemen van het grotere aantallen brengt bij veel mensen ook gelijk de consequentie naar boven. Het bericht is totaal irrelevant als het slechts 1 privébericht van de 1,3 miljoen zou betreffen. Dan heb je het eerder over een incident i.p.v. een grootschalig 'lek'.
/my2cts

[emnich]

Nee, hij heeft niet elk bericht opgehaald maar wel 1.300 130 stuks terwijl dat niet nodig was. Met 3 stuks was het lek voldoende duidelijk. Hij heeft het al beter aangepakt dan bij de eerdere lekken.

Nogmaals, ik snap het vanuit het oogpunt voor het verkrijgen van publiciteit en ik waardeer het dat hij het keurig en tijdig heeft aangekaart bij Kamernet maar imho zal hij toch nog terughoudender moeten zijn.

[edit]
@flabber: Sorry, rekenfoutje. Je hebt gelijk dat het er slechts 130 zijn. Mijn punt blijft echter staan dat het aantonen van de hoeveelheid berichten niet nodig zou zijn.

Daarbij, als je dat toch wilt aantonen dan hoef je alleen maar te kijken óf je een reactie krijgt van de server en niet de daadwerkelijke berichten op te slaan.

[Reactie gewijzigd door emnich op 26 juli 2024 20:10]

[flabber]

1,3 miljoen in blokken van 10.000 is 'slechts' 130, geen 1.300.
Dat is wellicht nog steeds meer dan strikt noodzakelijk, maar begrijpelijk als je niet weet om wat voor getallen het gaat.
Als je vermoed dat het om vele tienduizenden tot enkele honderdduizenden kan gaan, dan is een startwaarde van 10.000 een goede keuze.
Verwacht je dat het om miljarden zou gaan, dan kun je beter beginnen met 10.000.000, maar bij een instelling als kamernet zou ik ook eerder denken aan een paar honderdduizend.

[galena]

Je kunt ook bij 10.000.000 beginnen en dan terugtellen :-) Dan hoef je maar één echt bericht op te halen.

[flabber]

Maar hoe kom je op die waarde van 10.000.000?
Stel dat er 978 miljard entries waren geweest, dan zat je op ehm... 0,001% van het totaal. En dan moet je alsnog weer gaan ophogen.
Begin je bij 30 miljard en ga je terug tellen met 1.000.000, dan ben je ook weer een 2.999 slagen verder voordat je de eerste hit hebt.

Ik weet niet of er een (beter) algoritme bestaat dat in minder dan 100 iteraties de omvang van een set kan bepalen zonder enige vorm van voorkennis?

[eyhey]

Het is mogelijk om de lengte van een set met een lengte 0 tot M te bepalen met een algoritme die een running time heeft van log₂(M)

edit: antwoord verbetert ten opzichte van de vraag

[Reactie gewijzigd door eyhey op 26 juli 2024 20:10]

[trogdor]

Omdat je niet weet wat de bovengrens is moet je bij 1 beginnen. Door vanaf dat startpunt te gaan verdubbelen, en pas als je de bovengrens hebt gevonden (2097152 > 1300000) kan je echt gaan zoeken.
Het verdubbelen van het startpunt kost grappig genoeg ook log₂(M) , dus het totale algorithme kost 2 log₂(M) requests.

[eyhey]

Dat is inderdaad waar, maar bij het bepalen van de running time worden vaak constanten weggelaten, omdat alleen de groei van de functie belangrijk is en soms afhankelijk van de implementatie van het algoritme.

Daarnaast was mijn antwoord niet helemaal juist ten opzichte van de vraag(inmiddels verbeterd).

[trogdor]

Om het even heel precies te definieren, het heeft een orde O van log₂n , maar het aantal requests is 2 log₂n.
42 dus in dit geval. (42 , het antwoord op .... :-) )

[kimborntobewild]

Dat zijn er ook zo'n 40. Dus dat maakt ook al niet zoveel uit met 130 (qua orde van grootte).

[Verwijderd]

nevermind

[Reactie gewijzigd door Verwijderd op 26 juli 2024 20:10]

[galena]

Het maakt niet zoveel uit hoeveel requests je doet op niet-bestaande berichten, want dat levert geen privacy schending op, alleen een reply dat het bericht niet bestaat. Dus als je terugtelt heb je wel meer requests, maar die zijn niet zo erg.

Maar goed, de hacker heeft netjes gehandeld, waarvoor respect.

[kimborntobewild]

Je kunt ook bij 10.000.000 beginnen en dan terugtellen :-) Dan hoef je maar één echt bericht op te halen.

Niet praktisch; als de site een stevige bescherming heeft dan zal de firewall/DOS-detector je IP-adres blocken (al dan niet tijdelijk).

[robvanwijk]

Je kunt ook bij 10.000.000 beginnen en dan terugtellen :-) Dan hoef je maar één echt bericht op te halen.

Of je maakt even een test-account aan, en stuurt van je ene account een bericht naar je andere en kijkt welk ID dat bericht krijgt, dan ben je er meteen, zonder gegevens van andere mensen in te hoeven zien. Tenminste, je kunt de omvang van het lek op die manier bepalen; om vast te stellen dat er een lek is zul je inderdaad een bericht van iemand anders op moeten halen.

[CH4OS]

Gebeurd vaak zat, dat mensen wel wat meer informatie willen dan alleen te weten dat er iets lekt. Een schatting van het aantal berichten (hoef je ze dus niet voor gelezen te hebben!) is daarbij een goede indicatie. Dat hij dan 130 berichten zou hebben, is natuurlijk ook maar het maximale. En op het aantal berichten dat er dan in de tabel staan, is het alsnog peanuts.

Punt is, dat niet gelijk bepaalde zaken als lek worden gezien bij een handvol (zeg maximaal 5) berichten, zouden bedrijven het vaak alsnog op toevalstreffer gooien. Met 100 of meer, is het toch wel erg duidelijk dat er echt iets mis is.

EDIT:
Het gaat echter om zo'n 1,32 miljoen berichten, 132 berichten die dus in elk geval geteld zijn. (bron)

[Reactie gewijzigd door CH4OS op 26 juli 2024 20:10]

[Rob Coops]

Dat hangt er heel erg van af wat de grote van het bedrijf is... een bedrijf dat bivoorbeeld 500.000.000 berichten in een systeem heeft staan zal ook bij 100 or bij 1000 gelekte berichten waarschijnlijk nog niet zo snel het idee hebben dat er nu echt onmiddellijk iets heel erg goed mis is.

Daarom is het idee van een schatting (er staan ongeveer 1.32M records in die tabel) een veel betere oplossing. Natuurlijk als de ID's in de tabel simpel weg oplopen dan is dat nog wel te raden maar om dat te kunnen bevestigen moet je toch een flink aantal berichten opvragen tussen de 0 en de vermoedelijke max. Immers het gebeurt niet zelden dat een systeem om welke reden dan ook een flinke reeks ID's overslaat bijvoorbeeld beginnend bij de 1000 or de 1M omdat dat er leuker uitziet bijvoorbeeld.
Als je instaat bent om een redelijk precies aantal te noemen en een duidelijke omschrijving hebt hoe je aan dat aantal bent gekomen dan is het voor de beheerder vaak al snel duidelijk dat er inderdaad een flink lek is gevonden en dat het tijd wordt er iets aan te doen.

En in dit geval heeft kamernet heel correct gehandeld door het lek zo snel mogelijk te onderzoeken en te dichten, het ook netjes te melden en natuurlijk het hele verhaal te bevestigen in de pers. Iets wat flink wat andere bedrijven vaak liever niet doen want slechte publiciteit en zo... Persoonlijk zou ik dit eerder goede publiciteit noemen in dit geval.

[supersnathan94]

Tsja. Het aantal nep ads en slechte ads is echter dusdanig hoog dat een beetje publiciteit geen kwaad kan. Kamernet is moementeel echt wel meer spam dan daadwerkelijk inhoud. Zeker in afgelegen gebieden. Mijn zusje is aan het kijken voor een kamer in de omgeving van Heelsum (wageningen regio) en vrijwel alle plaatsingen die ze tegen kwam waren nep.

Of om mensen naar een grotere site te lokken van bijvoorbeeld een stichting die niet eens jn de buurt zat ofwel een ad van Kamernet intern. Kost je wel €20 iedere keer.

[Blokker_1999]

Daar ga ik niet volledig mee akkoord. Door na te gaan hoeveel berichten er toegankelijk zijn kan hij ook een inschatting maken van de ernst van het lek en daarmee alsnog naar de media stappen indien zou blijken dat de site eigenaar er niets aan wil verhelpen.

Door slechts elk tienduizendste bericht op te halen heb je sowieso een zeer beperkte subset aan berichten.

[emnich]

Dat kan je dus eventueel doen nádat blijkt dat de eigenaar het niet wil oplossen en zelfs dan hoef je niet de daadwerkelijke berichten op te slaan en te bekijken. Alleen het feit dat je script een geldig antwoord krijgt is voldoende om te bepalen om hoeveel berichten het gaat.

Behalve zijn eigen commerciële belang is er namelijk geen enkele reden te bedenken om méér op te halen, op te slaan en te lezen dan strikt noodzakelijk om het lek aan te tonen.

[Verwijderd]

"niet de daadwerkelijke berichten op te slaan"
Het lijkt er niet op dat hij dat gedaan heeft.

"en te bekijken"
Aangezien hij niks kan zeggen over de inhoud, betwijfel ik of hij ze bekeken heeft.

"zijn eigen commerciële belang"
Welk commercieel belang? Hij heeft er niks mee verdiend en heeft de informatie ook niet doorverkocht.

"is er namelijk geen enkele reden te bedenken om méér op te halen"
Wat ben jij voor tweaker? Er zijn zat redenen te bedenken, voor het scannen van een groot deel van de berichten en deze ook inhoudelijk controlleren
- Omvang van het lek aftasten
- Testen of het voor alle subsets van berichten gaat, of enkel een deel
- Kijken of je daadwerkelijk inhoud terug krijgt of enkel een error
- Testen of de berichten toegankelijk zijn door een huidige API fout of een historische fout in de informatie verwerking.

Een lek, is het onterecht toegankelijk zijn van teveel informatie. Een groot lek is het onterecht toegankelijk zijn van grote hoeveelheden informatie.

Om een lek aan te tonen heb je dus nodig:
- Toegang tot een systeem
- Controlle dat er daadwerkelijk informatie toegankelijk is
- Controle dat die informatie daadwerkelijk onrechtmatig toegankelijk is.

Om de grote van een lek aan te tonen, heb je daarnaast nodig:
- Grote van de hoeveelheid toegankelijke informatie
- Controle of bij x datum, daadwerkelijk sprake is van een informatie lek (Het kan immers zijn dat bij een datum kleiner dan x, de berichten ineens geen inhoud meer bevatten)


Dit is een hele simplistische omschrijving, maar het is in elk geval volkomen terecht hoe hij het onderzoek heeft opgezet.

[emnich]

Tja, gezien de -1 moderaties vinden de meeste Tweakers elke kritiek op de werkwijze van Nelson off-topic terwijl het me lijkt dat iets over Responsible Disclosure toch echt on-topic is bij het melden van een lek. Tegen beter weten in toch nog een laatste reactie.

Hij heeft daadwerkelijk de berichten opgeslagen en bewaard

All the obtained data is gone, with exception of some screen-shots and a tiny set of data as evidence(132 messages in this case), which are stored on an encrypted drive.

Zijn commerciële belang is om aandacht te krijgen en vermeldingen te krijgen naar zijn bedrijfspagina waar hij security services aanbied.

Om aan te tonen of het groot of klein lek is, hoef je de berichten niet op te slaan én niet te bekijken. Daarbij is er geen enkele reden om te moeten aantonen dat het om een groot of klein lek gaat behalve dat een groot lek meer publiciteit oplevert voor zijn bedrijf en diensten. Bepalen of het een groot of klein lek is, is dus vooral ingegeven door commerciële motieven.

Uit de Leidraad voor Responsible Disclosure:

De melder zal niet op onevenredige wijze handelen:

• door een kwetsbaarheid verder uit te nutten dan noodzakelijk is om de kwetsbaarheid vast te stellen.
• door gegevens van het systeem te kopiëren, te wijzigen of te verwijderen. Een alternatief hiervoor is het maken van een directory listing van een systeem.

Door meer dan 3 berichten op te vragen, haalt hij meer op dan noodzakelijk om de kwetsbaarheid vast te stellen en door de gegevens op te slaan voldoet hij niet aan punt 2.

Nogmaals, het is prima dat hij dit meldt en dat hij het commercieel uitbuit maar hij moet niet verder gaan dan hij noodzakelijk hoeft.

[Reactie gewijzigd door emnich op 26 juli 2024 20:10]

[Verwijderd]

"Tja, gezien de -1 moderaties vinden de meeste Tweakers elke kritiek op de werkwijze van Nelson off-topic terwijl het me lijkt dat iets over Responsible Disclosure toch echt on-topic is bij het melden van een lek. Tegen beter weten in toch nog een laatste reactie."
Off-topic is een 0 moderatie. -1 is een ongewenst post, die bijv. kwetsend of (in jouw geval) foutief is.

"Hij heeft daadwerkelijk de berichten opgeslagen en bewaard"
Hij heeft 132 berichten bewaard, als vertegenwoordiging van verschillende delen van de database en hij weigert ook keurig enige uitlating te doen over de inhoud daarvan.

Daarnaast moet hij bij weigeren door het bedrijf een geruime hoeveelheid bewijs hebben om daar eventueel aangifte van te doen. (Ja, ook daar bestaan kaders voor)

"Om aan te tonen of het groot of klein lek is, hoef je de berichten niet op te slaan én niet te bekijken"

Weldegelijk, dat een API een response geeft, betekend nog niet dat het een inhoudelijke response is. Opslaan is altijd noodzakelijk voor bewijsmiddelen, als hij er melding etc van doet, moet je de scope van het lek kunnen bewijzen.

"Door meer dan 3 berichten op te vragen, haalt hij meer op dan noodzakelijk om de kwetsbaarheid"
Nee, want de kwetsbaarheid bevat ook de schaal. Om de schaal vast te stellen mag je meer ophalen dan 3 berichten.

"In door de gegevens op te slaan voldoet hij niet aan punt 2."
Nee, als je punt 2 als jurist leest, wordt er bedoeld dat er een subsidiariteitseis is voor opslag van informatie. Dat houd in dat je niet mag kopieeren indien er een ander bewijsmiddel is dat minder ver strekt.

Daarnaast valt het mij op, dat het lijkt alsof het door een stelletje HBO juristen is geschreven...
Daarnaast heeft dit wettelijk weinig waarde, de Minister mag een advies uitbrengen aan het college van procoureursgeneraal en het college zal dit vaak overnemen.

Het enige wat dit betekend is dat het OM eerder een beleidssepot toe past op dit soort zaken. Dat zegt echter weinig over de uiteindelijke uitspraak van de Rechter, dat wordt hierdoor niet beinvloed (en dat zou staatsrechtelijk ook niet mogen). De waarde van dit soort stukken als literatuur is of gebruik is nagenoeg nihil.

Ook bij 138ab lid 2 SR (waar het hierbij om gaat), kan men zich ter zitting gewoon beroepen op een rechtvaardigingsgrond. Daarbij gaat de rechter kijken waarom hij betreffende informatie heeft verkregen en hoe hij deze (vertrouwlijke) informatie heeft behandeld.

De kans dat hij hiervoor ook maar enige strafrechtelijke sanctie zou krijgen lijkt heel-heel klein. Zeker met zo'n belachelijk slecht geschreven leidraad.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 20:10]

[kimborntobewild]

Daarbij is er geen enkele reden om te moeten aantonen dat het om een groot of klein lek gaat behalve dat een groot lek meer publiciteit oplevert voor zijn bedrijf en diensten.

Dat klopt niet; ervaring leert dat een bedrijf vaak slecht/traag reageert als een white hat hacker niet aantoont dat het een groot lek is.
Je kan ook 'gold' hat hackers willen: hackers die zonder een vergoeding aan te nemen, je systemen test op lekken. Maar daar kan een hacker niet van leven; dus krijg je minder goede hackers en meer black hat hackers (immers, de lekken blijven dan langer zitten).
Kamernet mag juist in zijn handjes knijpen dat dit (voor zover momenteel bekend: geen verdere toegang door anderen) zo gelopen is.

[Reactie gewijzigd door kimborntobewild op 26 juli 2024 20:10]

[SpiceWorm]

En wat krijgt hij als beloning? Een jaar gratis kamernet? Waarom blijven we zo'n belangrijk onderwerp als vrijwilligerswerk zien?

Ik zou het gemeld hebben en een dik bedrag uitonderhandeld hebben. Of op de "zwarte markt" verkocht hebben. Dat laatste is gewoon legaal.

[Reactie gewijzigd door SpiceWorm op 26 juli 2024 20:10]

[Verwijderd]

Daar is een woord voor: Blackmailen

[SpiceWorm]

Je hebt gelijk. Het lijkt erop dat dit in Nederland afdreiging is en dat is strafbaar. Dat moet je dus niet doen.

Maar je kan wel het lek tegen een geldbedrag aanbieden. Mochten ze het niet willen dan mag je het lek aan een andere partij verkopen. Zo lang je het dreigen "ik verkoop het aan iemand anders" achterwege laat dan ben je niet strafbaar

[Reactie gewijzigd door SpiceWorm op 26 juli 2024 20:10]

[Verwijderd]

Ja, dat zou je kunnen doen. Maar dan ben je wel een lul

[SpiceWorm]

Tsja of je bent een lul als je iemand die een vet lek in een belangrijk onderdeel van je bedrijf meldt aanbied om diegene aan een kamer te helpen ipv gewoon 1000 euro op z'n rekening te storten.
Zo'n dienst is gewoon geld waard, essentieel voor de bedrijfsvoering en ik vind het echt bizar dat mensen dit vrijwillig doen.

Heb je wel eens van kamernet gebruik (moeten) maken? Als er iets een naar businessmodel heeft dan is kamernet het wel met tegoed wat verloopt binnen 6 maanden.

[Verwijderd]

Ik heb 21€ betaalt om daar 15 dagen een kamer te kunnen zoeken. Maarja supply & demand welcome to capitalism. Het is helaas een oligopolie.
Ik verwacht niet van bedrijven dat ze mij belonen.

[Av-]

Hij doet dit niet vrijwillig, zijn belang bij deze 'hacks' zijn commercieel van aard. Niet voor niets publiceert hij ze op zijn website waar hij tevens IT security diensten aanbied. ;-)

[trogdor]

In welk land is het legaal om gestolen gegevens te verkopen ?

[SpiceWorm]

Het is legaal om een softwarelek te verkopen. Gestolen gegevens verkopen niet nee.

[Juncto]

Als ik het zo lees, dan heeft Nelson eerst Kamernet geïnformeerd en de tijd gegeven om het op te lossen en daarna pas gepubliceerd en Kamernet lijkt hierin ook correct gehandeld te hebben en dankbaar te zijn voor de vondst, dus dan zien we eens een positief voorbeeld :-)

[kaboom]

Lijkt inderdaad een mooi voorbeeld van hoe het ook kan en zou moeten :-)

[Navi]

Is het niet raar dat ze de mensen met een account op dit site niet informeren?

[Anonymoussaurus]

Nee, want waarom zouden ze? Er zijn geen wachtwoorden buitgemaakt, en er is ook geen misbruik gemaakt van het lek. Bovendien kon de heer Berg géén wachtwoorden inzien.

[bazzard]

Slecht dat het kon maar na de melding is het snel opgepakt, binnen een half uur oplossen en de media netjes te woord staan beperkt mogelijk verdere imago schade.

[Gtoniser]

Leuke find. Enkele maanden geleden heb ik een soortgelijk lek aan kamernet gemeld waarbij ook willekeurige berichten inzichtelijk waren. Toen ging dit gewoon via een URL van de berichten pagina ipv via de API. Jammer dat ze het toch blijkbaar niet grondig genoeg hebben opgelost toen, maar dat zie je wel vaker.

[Kevin-de-Groot]

Ik vind dit ook wel een ernstig lek, hoor. Uit mijn ervaring, als er een ID wordt meegestuurd, moet je ook altijd opvragen of de ingelogde gebruiker het bericht met het meegegeven ID wel mag inzien. Lijkt me een basis principe van beveiliging. Misschien heb ik het verhaal verkeerd begrepen, hoor.

[lekorque]

Call me naive maar ik vind het een ernstige zaak dat iemand uberhaupt de poging waagt om die informatie zo te verkrijgen.
Het onderscheid tussen ethical en non-ethical is flinterdun. Technisch is er geen verschil, het vraagt dezelfde skills en sluwigheid van de hacker. Alleen in morele zin is er een onderscheid. De definitie van die morele overtuiging is niet vast en de ene hacker heeft andere waarden dan de ander.
Het lijkt inmiddels ook een omgekeerde wereld: de eigenaar van het informatiesysteem kan worden gestraft als deze wordt gehacked. Dat is net alsof je een boete krijgt wanneer je fiets wordt gestolen. Of het sleuteltje er nou nog in zat of niet, zou niet moeten uitmaken. Die Berg zegt in feite: "hee eigenaar, je fiets kan worden gejat met het sleuteltje dat onder het zadel zit". En dan willen ze 'm ook nog bedanken.

Fijn dat deze persoon zijn eigenschappen tot het goede richt, maar hij doet het ook publiekelijk en dat vind ik moreel verwerpelijk. Kom je er achter dat dit lek er zit, dan kun je dat of voor jezelf houden, of je meld 't aan de instantie. Bij de Albert Heijn op het prikbord hangen dat "het fietssleuteltje onder het zadel zit, met vriendelijke groet Dhr Berg", hoort daar eigenlijk niet bij. Tenzij je in het oog wil springen om persoonlijk gewin. Dus een morele waarde die discutabel is.

[Tjolk]

Dat is net alsof je een boete krijgt wanneer je fiets wordt gestolen. Of het sleuteltje er nou nog in zat of niet, zou niet moeten uitmaken. Die Berg zegt in feite: "hee eigenaar, je fiets kan worden gejat met het sleuteltje dat onder het zadel zit". En dan willen ze 'm ook nog bedanken.

Met dat verschil dat een gestolen fiets alleen maar jezelf treft. In dit geval gaat het om gegevens van anderen waar je de verantwoordelijkheid voor hebt.

Om een beetje jouw type vergelijking te maken: alsof de kluisjes op het NS station eenvoudig te openen zouden zijn met een haarspeld, waardoor de bezittingen van de gebruikers ervan in gevaar komen.

[lekorque]

Dat is inderdaad een passende analogie. Maar dan nog: het wereldkundig maken van die "back door" is op zich al wangedrag. Daar komt nog bij dat de persoon de poging heeft gewaagd, en dus een strafbaar feit heeft gepleegd.

Als je ongevraagd een hack doet (white hat of niet) dan ben je al over het randje. Als je dan ook nog die hack wereldkundig maakt om zogenaamde ethische of morele gronden, dan ben je gewoonweg een zak, én breng je de data in gevaar. Zeg dan eerlijk dat je het doet om in de schijnwerpers te komen en om je "ethical" hack CV te pimpen.

[xats6nl]

laatste zin : moet dat niet zijn 50.000 of 5.000 studenten ?

[Roozzz]

Als je de bronnen in de zin ervoor opent staat daar 385.000 en 95.000 gelekte gegevens van studenten. 500.000 lijkt me dan ook de correcte orde van grootte.

[flabber]

50.000 is inderdaad meer in de orde van grootte van HVA en UvA bij elkaar.
Echter, bij de andere hacks ging het om het studenten informatie systeem.
Deze bevatten erg veel historische data waardoor er data van meer dan 700.000 unieke (ex-)studenten ingezien kon worden.

[YoNiE]

Moet Kamernet nu geen "datalek" melding doen ivm WBP?

[edit] nevermind, lezen

[Reactie gewijzigd door YoNiE op 26 juli 2024 20:10]

[dutchgio]

"Het lek is inmiddels gemeld aan de Autoriteit Persoonsgegevens.""

Vanuit bovenstaand bericht, is dus al gedaan.

[Reactie gewijzigd door dutchgio op 26 juli 2024 20:10]