Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Kentekens en adresgegevens 50.000 Snappcar-gebruikers uitgelekt via api

Door een lek bij autodeelplatform Snappcar lagen de kentekens en adresgegevens van 50.000 Nederlanders op straat. Die waren op te vragen via de api, ontdekte RTL Nieuws. Het lek is inmiddels gedicht en het bedrijf informeert getroffen gebruikers.

RTL ontdekte het lek na een tip van een lezer en bracht Snappcar daar maandag vóór publicatie van op de hoogte. Het bedrijf heeft het lek direct gedicht, waarna RTL publiceerde. Het bleek mogelijk om via de api informatie op te vragen die niet opvraagbaar zou moeten zijn. Het ging om kentekens en privéadressen van gebruikers.

Snappcar heeft inmiddels een reactie op het nieuws geplaatst. Daarin zegt het bedrijf dat er geen tekenen zijn dat er misbruik is gemaakt van het lek, en dat niemand toegang heeft gehad tot de adresgegevens en kentekens. Ook zegt het bedrijf dat e-mailadressen en wachtwoorden niet via de api te bemachtigen waren. Het bedrijf roept klanten die bezorgd zijn over het lek, op om contact op te nemen. Snappcar heeft de Autoriteit Persoonsgegevens ingelicht en klanten die getroffen zijn geïnformeerd.

Door Tijs Hofmans

Redacteur privacy & security

09-07-2019 • 16:31

67 Linkedin Google+

Reacties (67)

Wijzig sortering
Wat een belachelijke reactie. Maak jij soms nooit fouten? Dit soort dingen gebeuren zolang mensen de APIs bouwen en beveiligen, het is interessanter hoe het bedrijf vervolgens met het lek omgaat.

Dit hoeft niks met bezuinigingen te maken te hebben en al helemaal niet of het aan recent afgestudeerden is uitbesteedt
[...] Dit soort dingen gebeuren zolang mensen de APIs bouwen en beveiligen, het is interessanter hoe het bedrijf vervolgens met het lek omgaat.
Nee, dit soort dingen gebeuren zolang onervaren mensen APIs bouwen en beveiligen.
@PM_Petrol stelt een aantal vragen. Eentje met daarin de aanname dat op projecten bezuinigd wordt op de verkeerde onderdelen (security bijvoorbeeld) en de andere dat er onervaren medewerkers op projecten gezet worden.

Zelf heb ik bij bedrijven gewerkt waar ook onervaren programmeurs werkten aan kritische systemen. Zij voerden niet enkel taken uit, maar maakten ook beslissingen over architectuur. Daar sluipen fouten in, daarvoor zijn het beginnende programmeurs. Het besluit van een bedrijf om jonge, relatief onervaren (en goedkope) ontwikkelaars op projecten te zetten komt veel vaker voor dan de meeste mensen denken of zien.

Helaas ken ik genoeg bedrijven waar het eerste prototype van een webapplicatie nog altijd draait, met de nodige hacks om het te stabiliseren.
Dit hoeft niks met bezuinigingen te maken te hebben en al helemaal niet of het aan recent afgestudeerden is uitbesteedt
Het zal niet 100% onderdeel zijn van de oorzaak, maar ik durf er toch wel vergif op in te nemen dat ofwel knijpen in het security budget ofwel onervaren programmeurs deels veroorzaker zijn van dit lek.
Sorry, maar ik vind je strekking totaal verkeerd. Ik kom uit de Devops rol en ben zeer betrokken met security op dit moment. Daarnaast ook veel te maken gehad "change management" waardoor ik inzicht heb over de gehele organisatie en niet dat 'ene kleine' stukje waar jij het nu over hebt (onervaren programmeurs, etc.).

Ten eerste is een programmeur met alle respect een nobody binnen de organisatie. Ik bedoel dit niet inhoudelijk of persoonlijk, noch denigerend. Echter draagt een programmeur maar beperkte verantwoordelijkheid. Misschien verantwoordelijk voor zijn stukje code, dat dit wel "goed" moet zijn. Desalnietemin zul je nog steeds processen moeten hebben die zulke dingen kunnen waarborgen. Dus om zo'n hack af te schuiven richting "onervaren mensen die APIs bouwen en beveiligen", vind ik wel heel erg gemakkelijk. Dit is puur kijken naar 'eerste' oorzaak en gevolg. Niet vanuit WAAR die oorzaak vandaan is gekomen.

Er kan net zo goed een project manager en/of IT manager zijn die zorgt draagt dat bepaalde doelen behaald worden. Ook op het gebied van testing & security. Je mag en kan niet verwachten dat 1 programmeur de gehele organisatorische verantwoordelijkheid draagd.

Ook al is een programmeur onbekwaam en/of onervaren. Dan ligt die verantwoording alsnog bij een manager / baas. Hier zijn ook letterlijk rechtsuitspraken op gedaan. Recent nog een casus geweest van een verpleegkundige die door onkunde een grove fout heeft gemaakt. De uitspraak was dat "bedrijf" onvoldoende begeleiding heeft gegeven. Hoewel de verpleegkundige dermate "slecht bezig was", had bedrijf dit moeten signaleren en adequaat op moeten reageren.

Het feit dat men vrijheid krijgt in architectuur is helemaal niet slecht en zeker niet de gehele oorzaak is bepaalde infra niet 'okay' is. Immers vind ik dat hier een rol van CTO of whatever een eindverantwoordelijke rol in moet spelen. In het geven van de vrijheid en waar nodig managen om bedrijfswaardes te waarborgen (en dus ook security, CISO ;) ).

Zolang de big boss de waarde van gedegen producten niet inziet, er geen tijd en geld wordt geinvesteerd in kennis, kunde en rust, dan zal dit ook merkbaar zijn in de rest van de organisatie. Als er geen CISO is. Als er geen seniors zijn die ook nog ruimte krijgen om een veilig product te mogen ontwikkelen of hun kennis te delen met het rest van het team. Zeker als je alleen maar deadlines hebt en niet eens mag/kan werken aan test-cases, pen-tests, of whatever. Visa-versa ook als er geen gedegen mensen binnen de organisatie zitten die juist op een iets hoger niveau deze kernwaardes moeten overbrengen bij management. Maar laten we vooral die ene onervaren programmeur te schuld geven.

-----

Dat allemaal gezegd hebbende. Zolang er geen boeiende post mortem komt met daadwerkelijke details zit iedereen hier maar te gissen. Voor hetzelfde geld is eigenlijk alles best wel in orde en is er toevallig 1 stomme fout geweest. Misschien hebben ze vorige maand nog wel een volledige pen test gedaan en is er pas een nieuwe release geweest. Ik probeer het niet echt goed te praten, want uiteindelijk ben ik wel van mening dat dit echt wel voorkomen had moeten worden. Desalnietemin vind ik het te simpel om van die one-liners te roepen; "daar lag het aan". Want dat is pure onzin.
Jong, onervaren en meestal overmoedig. Vooral dat laatste wil nog wel eens de bovenhand nemen.
ik heb ook de indruk dat er weinig aandacht wordt besteed aan beveiliging in de verschikllende opleidingen en eigenlijk zou dit met stip bovenaan moeten staan.
Jong, onervaren en meestal overmoedig. Vooral dat laatste wil nog wel eens de bovenhand nemen.
Mijn ervaring is dat juist de meest ervaren developers op den duur niet meer kritisch op zichzelf zijn en dan
juist de foutjes in de applicaties sluipen.
Uiteraard. Maar als de API openbaar toegankelijk is, dan is het niet beveiligd.
Ik weet niet precies hoe de code hiervoor werkt, maar een wat ervaren developer ziet zoiets toch niet over het hoofd, zeker niet als je in een team werkt.
Een API kan op allerlei manieren openbaar toegankelijk zijn. Dat kan zijn dat er ergens een proxy open stond of dat authenticatie tokens nooit verliepen.

Uit zowel de blogpost van Snappcar als het artikel van RTL wordt niet duidelijk wat exact het probleem is dus het blijft speculatie. Beveiligingsproblemen zitten vaak in een klein hoekje
Er zijn gewoon ontzettend veel plekken waar gegevens staan. Daarom lijkt het ook zo vaak voor te komen.
Niet alleen daar, ik heb zelf bij collega's meegemaakt, dat ik iets tegen kom bij code audits, en ik vraag waarom op bepaalde dingen niet wordt gecontroleerd. Dan reageren ze soms best laconiek dat het bij normaal gebruik gewoon werkt, en kost het anders weer een halve dag om het helemaal dicht te timmeren.

Ik zorg dan dat dat laatste wel gebeurt, maar als er geen audits plaats vinden, bij bijvoorbeeld kleine bedrijfjes die API's enz bouwen, dan gebeurt dit. Je wilt niet weten hoeveel er potentieel lek is als je iets op een andere manier benaderd dan de bedoeling is.
Precies, weird machines vind je echt overal als je gaat zoeken.
SQLi is nog steeds een ding (er zijn zelfs voorbeelden van scholen die dit aanleren, gewoon SQLi in het huiswerk/voorbeelden) hoe makkelijk het ook te verhelpen is.

[Reactie gewijzigd door jozuf op 10 juli 2019 06:54]

Dat komt omdat er ontzettend veel bedrijven in de wereld zijn, en dit nu erg actueel is. Je hoort dus van elke lek. Uiteraard is elke 1 te veel, en zou het niet mogen. Helaas hebben veel bedrijven nog steeds andere prioriteiten en zal dit vermoed ik helaas altijd blijven. Zo lang mensen IT systemen maken blijven criminelen manieren vinden om binnen te komen
Goedkope junior developers op een plek zetten waar ze niet horen te zitten.
Of voor een dubbeltje op de eerste rang willen zitten en je project en\of beheer outsourcen naar een vage asiatische club.
Door een lek bij autodeelplatform Snapcarr lagen de kentekens en adresgegevens van 50.000 Nederlanders op straat.
Daarin zegt het bedrijf dat er geen tekenen zijn dat er misbruik is gemaakt van het lek, en dat niemand toegang heeft gehad tot de adresgegevens en kentekens.
Wait what? Dus RTL toont aan dat ze er bij kunnen, maar niemand heeft er bij gekund?
Klinkt niet heel plausibel.
Dat staat ook niet in de blog van Snappcar, dus ik weet niet waar deze conclusie vandaan komt.
Jawel; 4e alinea van het blog bericht begint met:
Er is op dit moment geen indicatie dat er daadwerkelijk adresgegevens of kentekens bemachtigd zijn door derden.
'Er is geen indicatie' bla bla is een voorzichtige stelling dat zij niet kunnen concluderen dat er misbruik is gemaakt van het lek.

[Reactie gewijzigd door xoniq op 9 juli 2019 17:00]

Er is geen indicatie als je uberhaubt niet logt wie er toegang heeft gehad. Geen indicatie klinkt alleen wat beter.
Klopt. Maar ‘geen indicatie’ is een heel voorzichtige stelling om de boel te sussen, en als er wel iets blijkt te gebeuren, dan is er hier gelogen, ‘er was op dat moment alleen geen indicatie hiervan’.

Zulke termen gebruiken vind ik nogal te voorzichtig.
Maar als je gewoon geen indicaties hebt dat er misbruik is gemaakt is de uitspraak ook gewoon waar. Hou altijd in de gaten dat de meeste lekken gevonden worden voor er misbruik van is gemaakt. Met iets als adres + kenteken is het makkelijk te zien of die data ergens te koop is) of dat die werkelijk geld waard is. Naam en adres staan tenslotte voor 94% in het telefoonboek.
Maar als je gewoon geen indicaties hebt dat er misbruik is gemaakt is de uitspraak ook gewoon waar.
Het gaat er niet om of de uitspraak waar is, het gaat erom dat de uitspraak nietszeggend is.

"Er is op dit moment geen indicatie" is ook waar als
  • je nog niet begonnen bent met zoeken
  • je wel begonnen bent met zoeken maar je überhaupt niet in staat bent om misbruik te constateren
Ik heb geen telefoonnummer in het telefoonboek. Maar maak me wel zorgen over de gelekte gegevens. Ik kreeg toevallig vandaag een phising sms. Rabobank wereldpas. Zie oa oplichting van Tros circa januari 2019. Het nummer dat is gebruikt vandaag is 06 87172863.Ze hebben wellicht al van mijn 06 nummer gebruik gemaakt, dit staat namelijk bij mijn adresgegevens.

Geen e-mail van Snappcar! En een reactie op een blog dat er geen gebruik van is gemaakt zegt niks. Iedereen kan dit verklaren, zonder onderzoek te doen. En ook al is er onderzoek gedaan dan gaat het om de kwaliteit van de onderzoeker die eventuele schade kan achterhalen. Ik wacht even af wat er gebeurt.
Er is op dit moment geen indicatie dat er daadwerkelijk adresgegevens of kentekens bemachtigd zijn door derden. Daarnaast zijn er op geen enkel moment andere type gegevens (zoals wachtwoorden, e-mailadressen of financiële gegevens) openbaar geweest. Ook zijn gegevens van huurders nooit openbaar toegankelijk geweest.
Ik denk dat het moet slaan op de gegevens van de verhuurders, het is inderdaad niet juist verwoord door Tweakers.
Plus dat RTL niet zelf actief zoekt naar lekken, maar tipgevers najaagt. Dus er is tenminste nog iemand die het lek heeft gevonden en RTL heeft getipt.
Rtl heeft daar zelf wel de kans kennis voor. Een van hun journalisten won onlangs nog een prijs.
Ik claim ook nergens dat RTL daar geen kennis van heeft, maar het lijkt me stug dat werknemers zelf vanuit het niets lekken zoeken in API’s. Lijkt me dat we eerst een tip over komt, en dat ze op onderzoek uit gaan. Als ze de kennis niet hadden konden ze dit zelf ook niet onderzoeken natuurlijk.
men beweert niet dat niemand erbij kon, maar dat er geen teken van misbruik is, wat naar mijn menig nu ok weer niet wil zeggen dat dit er niet geweest is, geen teken van is nogal een vaag begrip
Ai ai ai ai. Zo slecht dit. Heel slecht voor hun imago, maar nog slechter is dat dit soort data 'gewoon' in het openbaar terecht komt.
Waar baseer je dit op? Ik lees dat RTL het artikel heeft gepubliceerd na het dichten van de lek. Wat dat betreft vind ik dat RTL professioneel heeft gehandeld en hiermee een grotere potentiële datalek heeft geminimaliseerd.
Dat laatste is sowieso netjes, maar je hebt geen idee hoe lang dit al open staat, en hoe lang dit al is misbruikt. RTL die komt er ook niet bij toeval achter, die is ook gewoon getipt, waardoor RTL niet de enige is die wist van het lek.
Met een beetje deftig logsysteem moet dat prima kunnen. Dat iets open staat kan je misschien nooit achter komen. Maar een beetje requests loggen kost amper overhead. Achteraf terugkijken of bepaalde api requests misbruikt zijn sinds introductie hoeft geen probleem te wezen.
dat zijn al 2 aannames,

1. er is een systeem dat requests logt
2. logfiles worden daadwerkelijk bijgehouden.
Heel slecht voor hun imago
Ik hoop het ergens, maar in praktijk zie ik er heel weinig van. Ik kan geen voorbeelden noemen van bedrijven die echt nadeel hebben gehad van de berichtgeving over een datalek. Ken je ahsleymaddison.com nog? Dat is een dating site voor overspel. Die site heeft een groot datalek gehad en heeft dat gewoon overleefd. Ik kan me weinig sites bedenken die meer privacygevoelig zijn.

Veel mensen doen nog steeds een beetje lacherig over IT-beveiliging. Ik geloof dat ze het accepteren omdat ze zelf ook niks snappen van IT en de daar bij horende beveiliging, en het eigenlijk heel normaal vinden dat IT een onveilige en onbegrijpbare puinhoop is. De beste stuurlui staan aan wal, maar in het geval van IT kunnen die stuurlui het water niet vinden.
Dat blog bericht doet er nogal luchtig over. Dat alleen mensen met een 'specifieke' methode erbij konden (ja dus? Er is nog zoiets als Pastebin om al die gegevens op te dumpen), en dat er verder geen gegevens gelekt zijn. Ik vind de adresgegevens enz toch al teveel.
De vraag is houden ze logs bij voor elk aanvraag? Hoogst waarschijnlijk niet.
Handig als je nog een Audi RS 6 nodig hebt voor je volgende klusje.

Om welke API gaat het?
Een API tussen de klanten-app en de servers of tussen de servers en derden die in deze informatie mogen grasduinen. Paswoord en email uitgezonderd. Als het het eerste is dan zou ik verwachten dat email wel is op te vragen namelijk.
wauw .. best slecht dit. Dus er was een API gewoon open

https://blog.snappcar.nl/...ar-op-artikel-rtl-nieuws/

"Gistermiddag 8 juli 2019 is SnappCar door een journalist van RTL Nieuws gewezen op een onbeveiligde toegang tot data op ons platform, via een zogenaamde ‘API’. Via deze toegang was het mogelijk voor derden met de juiste technische kennis adresgegevens en kentekens van autoverhuurders op te zoeken zonder ingelogd te zijn met een SnappCar-account."
Titel, nieuws, best tegenstrijdig toch?
en dat niemand toegang heeft gehad tot de adresgegevens en kentekens
uitgelekt via api

Goed, RLT is natuurlijk ook meer sensatie dan nieuws, maar liggen die 50k gegevens nu wel of niet op straat? Feit dat ik ergens bij kan, betekent niet dat dit dan ook direct op pastebin te vinden is.
We willen benadrukken dat het risico op een ernstige inbreuk van de privacy, zoals identiteitsfraude, zeer klein is. Met name omdat geen andere gegevens openbaar zijn geweest en dat alleen mensen met specifieke technische kennis, na een aantal handelingen, bij de adresgegevens en kentekens konden
Ook het lekken van naam en adresgegevens kan leiden tot ernstige inbreuk. Dat is onder andere waarom die combinatie van gegevens niet publiek hoort te zijn en dit soort ernstige vormen van datalekken gemeld moeten worden en de betrokkenen zelfs geinformeerd moeten worden.

Snappcar probeert hier de situatie te bagatelliseren door er irrelevante andere ernstige vormen van inbreuk die niet mogelijk zijn erbij te betrekken. Het gaat er om wat wel kan. En de kans daarop neemt ook niet af doordat irrelevante andere vormen van inbreuk niet mogelijk zijn.

Ik vind het eigenlijk niet kunnen dat een bedrijf dat de gegevens slecht beschermd zelf een bagatelliserende mededeling doet dat het allemaal wel mee zou vallen voor de personen die het treft. En ook nog op een volledig ontransparante wijze tot een oordeel komt zonder duidelijk te zijn waarom hun stelling de juiste zou zijn.

[Reactie gewijzigd door kodak op 9 juli 2019 18:40]

Ja, want on-prem heb je geen publieke API's :+
Wat heeft de cloud hiermee te maken? Er was gewoon een API endpoint helemaal open. Dus bij het maken van de feature van de endpoint ging men niet eens eerst afvragen of dit een beveiligde endpoint moest zijn.

Ik denk dat men eerst de feature gingen maken (dus zonder beveiliging, want ja dat is makkelijker), nooit meer aan gedacht hadden om het te beveiligen en gewoon live gingen.

Op dit item kan niet meer gereageerd worden.


Apple iPhone 11 Nintendo Switch Lite LG OLED C9 Google Pixel 4 FIFA 20 Samsung Galaxy S10 Sony PlayStation 5 Games

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True