'Berijdersgegevens van 52 leasebedrijven waren toegankelijk via server' - update

Beveiligingsbedrijf ESET heeft ontdekt dat de gegevens van mensen die een leaseauto rijden op een centrale server toegankelijk waren. Het gaat om namen, adressen, leasecontracten en bekeuringen die in te zien waren bij in totaal 52 leasebedrijven.

ESET-directeur Dave Maasland zegt tegen het AD dat het om de gegevens van 180.000 tot 250.000 leaserijders gaat. Het beveiligingsbedrijf vond de gegevens toen het op zoek was naar een nieuwe leasemaatschappij. Zo was het binnen 'een paar minuten' mogelijk om toegang tot de server te krijgen, al legt ESET niet uit op welke manier dat mogelijk was. Maasland zegt tegen RTL dat het 'een kwestie van cijfers aanpassen' was en dat het bij de kwetsbare software om LeaseWise ging.

Na ontdekking van het lek informeerde ESET de getroffen bedrijven, waarna het lek werd gedicht. Het is onduidelijk of er misbruik van de gegevens is gemaakt. Het Verzekeringsbureau Voertuigcriminaliteit laat aan het AD weten dat adressenlijsten waarop staat welk type auto op welk adres aanwezig is van waarde kunnen zijn voor criminelen. Bijvoorbeeld om de auto's of onderdelen ervan te stelen.

Volgens Maasland waren ook andere gegevens in te zien, bijvoorbeeld kilometerstanden en de locatie van de opslag van winterbanden.

Update, 09:35: Een gepubliceerde blogpost bevat meer informatie over de manier waarop ESET toegang kon verkrijgen tot de gegevens. Daaruit blijkt dat er in één ASP.Net-portaal de sessie van een andere gebruiker over te nemen was door session prediction. Dat was mogelijk door bepaalde id's steeds te verhogen.

Ook in een tweede portaal was het mogelijk om een volgnummer in de url te verhogen en zo toegang tot de gegevens van een anders persoon te krijgen. Door het aanpassen van een query was het bovendien mogelijk om een csv-lijst met data van meer dan 3400 bestuurders op te vragen. Nadat bleek dat de gegevens van verschillende maatschappijen op één server stonden, waren deze ook door middel van een aangepaste query op te vragen.

Reacties (144)

[Slurpgeit]

Voor de technische details: http://www.thenewfrontier...aarheid-van-leaseportalen

[henk1994]

Lees dan vooral ook de pdf die daar gelinkt staat met hoe ze het gevonden hebben: http://www.thenewfrontier...s/Portaal-A-Portaal-B.pdf

[Thirler]

Zeer boeiend om te lezen (niet heel veel technische kennis nodig). Wel duidelijk dat je geen grote hacker hoeft te zijn om hier bij te kunnen.

Portaal A was nog een beetje oplettendheid voor nodig om te achterhalen hoe je de sessie van iemand anders kunt overnemen. Portal B echt triviaal (gewoon een ID in de URL aanpassen om alle informatie van een andere user te zien, inloggen niet eens nodig). En daarna nog letterlijke SQL mee kunnen sturen ook, en dus alles aan de database kunnen vragen wat je wilt (geen slimme injectie query nodig).

Moet wel zeggen dat het aantal beschikbare lease rijders in de database, als ik het goed begrijp een schatting is. Ze hebben die van 1 maatschappij opgehaal (3400), en geconstateerd dat het 52 maatschappijen zijn en komen dan op 176.000. Dat kan heel veel afwijken, als je net een grote of een kleine maatschappij hebt, dan zit je er ver naast. (merk op dat dit artikel 180k- 250k noemt, dat is mogelijk een andere bron)

[Reactie gewijzigd door Thirler op 22 juli 2024 22:12]

[Linqer]

En vergeet ook zeker niet de andere kant van het verhaal te lezen, inclusief het stukje dat niet genoemd wordt in de pdf namelijk dat ze pas konden starten met 'hacken' nádat ze eerst een inlog hadden gekregen die toegang bood tot het portaal.

Zo ontzettend knap is het dus allemaal ook weer niet en bij lange na al helemaal niet spannend. Een hoop herrieschoppers, daar bij ESET.

[Anoniem: 120539]

Vrijwel elke leasemaatschappij biedt aan de berijders een portal (vaak Dashboard genoemd) aan. Het aantal potentiële misbruikers is daarmee net zo groot als het aantal geraakten door deze kwetsbaarheid.

M.a.w.: elke klant kon de gegevens van elke andere klant inzien.
Dat het allemaal niet 'zo ontzettend knap' is zoals je terecht stelt maakt dit probleem niet minder erg, maar juist erger; een kind kon de was doen.

[Slurpgeit]

Wat overigens niet helemaal klopt. Voor het testen is inderdaad een account gebruikt, maar als je de links wist kon je die ook zonder authenticatie benaderen.

Los daarvan, elke willekeurige leasemaatschappij die je een mail stuurt geeft je binnen een half uur een Demo account.

[Reactie gewijzigd door Slurpgeit op 22 juli 2024 22:12]

[Anoniem: 636203]

De login zou alleen voor de desbetreffende gebruiker informatie moeten teruggeven, en onder geen beding voor andere gebruikers. Dat is gewoon knullig gebouwde software.

[Fleximex]

Lees dan vooral ook de pdf die daar gelinkt staat met hoe ze het gevonden hebben: http://www.thenewfrontier...s/Portaal-A-Portaal-B.pdf

Bedankt voor het linken. Soms heb je met dit soort dingen geen zin het te lezen (veel te lang of te complex). Maar je leest er in 5 minuutjes doorheen en snapt meteen hoe en wat er mis is met de beveiliging. Erg fijn uitgelegd en eigenlijk belachelijk simpel.

[supersnathan94]

Ben nu halverwege, maar schrik me helemaal kapot. De fouten die hier in zitten zijn echt zo knullig dat is niet normaal. Custom session ID management gebruiken ipv de vertrouwde en bewezen manier die standaard aanwezig zijn, direct object reference, SQL building in javascript en niet de applicatie kant.

En dan wordt dit als pakket verkocht aan 52 verschillende leasemaatschappijen. Wat een drama.

[capsoft]

Ik ben te lui efficiënt om het javascript in het portaal aan te passen, dus ik heb zojuist gemaild naar mijn leasemaatschappij dat mijn achternaam tegenwoordig
'); drop table leaserijders; -- is
https://xkcd.com/327/
Maar ik schrok ook.

[CAPSLOCK2000]

Ben nu halverwege, maar schrik me helemaal kapot.

Schrik je? Echt waar? Nieuw in de IT zeker...

Sorry, ik bedoel het niet lullig, maar ik heb af en toe zin om keihard "ik zei het toch!" te schreeuwen.

Deze ellende duurt nu al jaren en nog steeds is het kwartje* niet gevallen en nog steeds zijn mensen verbaasd dat er iets slecht is beveiligd.

Ga er maar van uit dat alles slecht is beveiligd. Heel slecht. In de beveiliging werken we niet met onschuldig tot het tegendeel is bewezen. Nee, alles is onveilig tot is bewezen dat het aan de minimumeisen voldoet.

Daarom ben ik zo fel tegen de meeste vormen van data verzamelen, de kans dat er iets mis gaat is gewoon te groot. Hoe meer je verzamelt, hoe duurder en moeilijker het wordt om het goed te doen.

* Het kwartje is een antieke munt uit de tijd dat dit soort fouten nog acceptabel waren. Bij sommigen is het nog steeds niet gevallen.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 22:12]

[supersnathan94]

Nouja verbaasd ben ik niet, maar dat het zo erg zou zijn wist ik niet. Dit is gewoon security 101.

[psyBSD]

het kan nog erger...

[supersnathan94]

Valt weer echt vies tegen helaas. Dit zijn toch echt wel programming no go's.

Die database hangt waarschijnlijk sowieso helemaal open en bloot aan het internet zonder enige vorm van controle en dan zo je queries uitsturen is echt raar. Met een kleine 2 uurtjes werk heb je daar een prima service omheen in Java met een paar rest endpoints. Standaard spring boot applicatie is al voldoende om in ieder geval de queries af te kunnen dekken als immutable.

[robertpNL]

Wat een grove fouten. Ik schrik er wel van.

Daarom, verplichte kost voor iedere webbouwer: de 10 meest kwetsbaarheden tot webapplicaties en de applicatie ook altijd daarop testen.

[MSalters]

Dat is geen lijst die ik echt serieus kan nemen. Het mixt oorzaken (A1 "Injection") en gevolgen (A6 "Sensitive Data Exposure"). En de items zijn dusdanig vaag bechreven dat je ze niet kunt testen.

[robertpNL]

Doel is het promoten van meest voorkomende veiligheidslekken van webapplicaties. Kennis daarvan helpt je website beter te beveiligen en zaken zoals in deze met de leasemaatschappij te vorkomen.
Dit PDF beschrijft je meer over de meest 10 security items met voorbeelden.

[Reactie gewijzigd door robertpNL op 22 juli 2024 22:12]

[Nik Du Bois]

injection kan ook sensitive data vrijgeven, maar ze zijn niet per sé gekoppeld.

injection kan een van de toegangswegen naar de data zijn, sensitive data exposure is dan weer zorgen dat bijvoorbeeld je wachtwoorden deftig gehashed zijn, en je slechts enkele records kan opvragen of er gaat een alarm af. Ik ben akkoord dat dit geen checklist is en dat er meer interpretatie nodig is dan enkel de titeltjes lezen en zien of je er aan gedacht hebt, maar security is nu ook eenmaal geen heel simpel iets.

de owasp top 10 is echt wel de referentie in de industrie op het vlak van web threats. Er wordt wel nog gewerkt aan de 2017 versie.

[MSalters]

XSS (ander item op de lijst) kan ook sensitive data vrijgeven; en beiden kunnen gebruikt worden om botnets mee te maken. Bijna elke combinatie van oorzaak en gevolg is mogelijk.

En dat zo'n matige lijst dan de "referentie in de industrie" is, is misschien wel de verklaring waarom we zo vaak dit soort verhalen zien.

[dnrb]

Voor A1 kan je natuurlijk wel in de broncode kijken of alle argumenten geparameteriseerd worden verwerkt en niet tot een string worden samen gevoegd. Resharper geeft een Alert als je mogelijk code schrijft die kwetsbaar is voor SQL injectie. Maar ik vrees dat dit bijvoorbeeld in PHP dit niet zo makkelijk te detecteren is.
Sensitive data exposure, lijkt mij meer een gezond verstand kwestie, N.A.W.. gegevens zijn bijvoorbeeld gevoelige info. Btw percentages niet.

[Dilkooo]

Wel grappig dat mensen die blijkbaar zo weinig verstand van zaken hebben, het uberhaubt is gelukt om een werkende applicatie op te leveren.

[Anoniem: 420148]

Met een beetje Stackoverflow copypasta kom je blijkbaar dus al een heel eind...

[Nimrodx]

Je moet echt je best doen om zulke slechte code te vinden op stackoverflow

[Anoniem: 420148]

w3schools!

[Nimrodx]

Ik heb even de PDF gelezen maar dit is toch te gek voor woorden. De fouten die gemaakt zijn zijn echt om te janken. Het lijkt wel of de portals door 3 stagiairs gemaakt zijn, die SQL die ook gewoon in de client als string beschikbaar is, wtf heh

[hotabibber]

http://www.ad.nl/binnenla...jders-op-straat~a6405aba/

Hier de link naar het artikel in het AD. Hier wordt het uitgebreider beschreven als hier op Tweakers.

[Anoniem: 954895]

-verwijderd-

[Reactie gewijzigd door Anoniem: 954895 op 22 juli 2024 22:12]

[Slavy]

Is er een lijst beschikbaar om welke leasebedrijven het gaat? Dan kan ik namelijk kijken of ik verdere stappen moet ondernemen of niet (lees: leasebedrijf aanspreken waarom ze mij niet geïnformeerd hebben).

[henkjobse]

Beetje zoeken via Google lijkt de lijst op te leveren die je zoekt: https://www.google.nl/sea...ilter=0&biw=1920&bih=1107 Best wel veel leasemaatschappijen dus.

[Thc_Nbl]

Dat is een mooie, bedankt.
Verschrikkelijk hoeveel van die sites ook met http werken en niet https..
Allemaal beboeten lijkt mij.

[jp]

Even nagevraagd bij "mijn" leasemaatschappij, en Leasplan geeft in ieder geval aan hier niet door getroffen te zijn: https://twitter.com/JeanPaulMars/status/894448761908363264

[MiesvanderLippe]

"... en dat het bij de kwetsbare software om LeaseWise ging."

[SunnieNL]

Van de website:

LeaseWise maakt het mogelijk om snel, accuraat en op basis van actuele gegevens het operationele gedeelte van autoleasing te beheren en aan te sturen.
Het pakket wordt door meer dan 150 leasemaatschappijen gebruikt.

150 leasemaatschappijen.. dat zijn er wat meer dan 52

[MSalters]

Het is voorstelbaar dat de andere 98 die app achter een reverse proxy hebben staan, met een fatsoenlijke whitelist, of in elk geval op een andere server. Deze 52 leasemaatschappijen deelden 1 server.

[swhnld]

Volgens mij is er van Leasewise zowel een online (cloud) als offline (lokaal geinstalleerde) versie.

[T7D_Sneezy]

Niet alle leasemaatschappijen gebruiken/zijn aangesloten op de module I-Wise

[ATS]

Naam van een softwarepakket is toch niet hetzelfde als de naam van een leasemaatschappij?

[kozue]

Tenzij het custom software is die door 1 bedrijf gemaakt en gebruikt wordt.

[ATS]

Dan nog is het niet hetzelfde, en is er hooguit een 1:1 relatie. Ik maak me sterk dat je als leaserijder weet welk softwarepakket je leasebedrijf gebruikt.

[xajorkith]

Aangezien in de kop van het bericht al staat dat het om 52 leasebedrijven gaat is dat niet zo in dit geval.

[MiesvanderLippe]

Excuseer als ik ongegrond aannam dat je die relatie zou kunnen leggen als consument.

[nils83]

Hier staan alvast hun referenties met een aantal klanten:

https://carwise.nl/referenties/

[bussie66]

Welke cowboys hebben dit systeem onderhouden?

Tijd om op zoek te gaan naar een andere baan lijkt mij.

[418O2]

Dit zal, zoals zo vaak, geen keus van de developers zijn geweest gok ik. Daarbij zou je bij software op deze schaal een externe audit moeten laten doen, maar dat zal het management ook te duur hebben gevonden

[ACM]

Het is ook niet ongebruikelijk dat het management dat gewoon niet zo goed weet/begrijpt en er van uit gaat dat IT "het wel regelt". Als er dan geld nodig is of een beslissing van het management, dan is het vaak wel weer de technische kant van het bedrijf die dat het beste weet, kan beoordelen en zou moeten kunnen uitleggen.

Automatisch de developers en systeembeheerders buiten schot plaatsen vanwege "management" is in ieder geval in mijn ogen net zo onterecht als die opmerking van bussie66 waar je op reageert

En als het dan per se om geld moet gaan, dan kan er natuurlijk nog naar de wettelijke plicht en de hoogte van de boetes gewezen worden. En daarnaast nog aandragen dat - zeker in dit geval - als er ook nog daadwerkelijk schade geleden wordt door bijvoorbeeld verzekeraars (want diefstal dure auto's vereenvoudigd), werkgevers of berijders, dat er dan daarbovenop nog kans op schadeclaims is... Dan is die 5k-50k ('t is maar net wat je wilt laten doen) voor een externe audit nog zo gek niet.

[MrHankey]

Automatisch de developers en systeembeheerders buiten schot plaatsen vanwege "management" is in ieder geval in mijn ogen net zo onterecht als die opmerking van bussie66 waar je op reageert

Maar het is wel een management dingetje. Deze software is niet devops ontwikkeld lijkt me, te oud. Dus de specs werden niet gezet door de devs zelf maar door 'het management'.

[Pyrone89]

Ik bespeur een trend hier dat ontwikkelaars blijkbaar onfeilbaar zijn en alles altijd op 'het management' wordt afgeschoven.

Natuurlijk maken (voornamelijk oudere generatie) managers fouten wanneer het op IT aankomt (of op het gebied van hun eigen beloning vs die van hun werknemers). Maar ik vind dit echt te makkelijk. Tenzij je er zelf bij was kun je dit soort dingen simpelweg niet zo stellen. Eigenlijk ben je dan zelf onderdeel van het probleem door zelf te denken 'dat regelt het management wel'.

Geloof me, als je goede managers (je hebt overal rotte appels) duidelijk aangeeft wat de kosten zijn vs eventuele baten (in dit geval zijn de baten het niet krijgen van dikke boetes, imagoschade etc etc.) dan staat die manager aan jouw kant. Wat ik echter merk in mijn dagelijkse praktijk is dat heel veel IT'ers dit niet goed over kunnen brengen en blijven hangen in 'dat is technisch beter, dat is veiliger, zo hoort het, zo doen anderen het'. Zo werkt het helaas niet in bedrijven: daar moet een kostenafweging worden gemaakt, vanwege de aandeelhouders (dus als je al op iemand boos wilt worden moet je daar zijn). Dan is het cruciaal dat jij als manager de juiste informatie krijgt om de juiste beslissing te maken. Je kunt daarbij niet op de blauwe ogen van de ontwikkelaar vertrouwen, want anders kan dit door elke afdeling worden misbruikt voor hun eigen doel om meer budget te krijgen.

[Cronax]

Ik blijf het interessant vinden dat wanneer een ontwikkelaar zegt "dit is technisch beter/dit is veiliger/zo hoort dit" dat de eerste reactie van management vaak is om te denken dat de ontwikkelaar waarschijnlijk overdrijft en dat het vast sneller, simpeler en goedkoper kan. Die ontwikkelaar is aangenomen om zijn of haar expertise, maar als vanuit die expertise een aanbeveling gedaan wordt om iets aan te scherpen of om ergens meer tijd voor te nemen dan weet management het ineens beter. Vervolgens wordt verwezen naar "we moeten toch geld verdienen". Ik snap dat je op een gegeven moment genoegen moet nemen met "goed genoeg" maar je komt altijd op minder kwaliteit uit dan waar je op mikt, dus als je vanaf het begin af aan al op die "goed genoeg" mikt dan ga je gewoon problemen tegen komen.

Alser dan even later een hack plaatsvind, dingen crashen, of het onderhoud toch wel erg veel tijd en geld kost dan word er ineens gedaan alsof dat uit het niets komt.

Ik wil niet beweren dat ontwikkelaars onfeilbaar zijn, verre van. Wat ik wel wil aangeven is dat het misschien tijd wordt om mensen te gaan vertrouwen op de expertise waar ze voor aangenomen zijn.

Daar komt dan nog bij dat de deadlines bijna altijd belangrijker worden geacht dan de kwaliteit van hetgeen er opgeleverd wordt en dat een groot deel van de bedrijfswereld nog steeds voor een dubbeltje op de eerste rang wil zitten. Het 'neeftje/nichtje van de baas' wordt vaak ook wel voldoende geacht om de klus te klaren en van goed testen voor we het live gooien willen we al helemaal niets horen.

[Reactie gewijzigd door Cronax op 22 juli 2024 22:12]

[MrHankey]

Wat je beschrijft heet value based management.. das toch een management ding? Of je moet de developers hier bewust van maken

[ACM]

Het is heel lastig van buitenaf een oordeel te vellen daarover. Uiteindelijk is het management natuurlijk gewoon verantwoordelijk voor alles wat het bedrijf doet, maar intern kunnen ze natuurlijk wel weer verwachtingen hebben over bepaalde taken.

Sowieso lijkt het me niet per se nodig om te moeten specificeren dat alleen klant X bij gegevens van klant X kan komen, hooguit door te specificeren dat de gegevens 'beveiligd moeten zijn'.
En ik kan me al helemaal niet voorstellen dat ze hebben gespecificeerd dat klant X bij de gegevens van klant Y mag komen en dat die developers dat dan klakkeloos hebben geimplementeerd (hoewel, als ze geoutsourced hebben weet je maar nooit).

Of misschien besefte gewoon niemand dat deze beveiligingsverantwoordelijk bestond of niet dat er uiteindelijk niet was die dat op zich nam. Op zich heel kwalijk, maar zou me ook weer niet echt verbazen.

[Anoniem: 455617]

Het is heel lastig van buitenaf een oordeel te vellen daarover. Uiteindelijk is het management natuurlijk gewoon verantwoordelijk voor alles wat het bedrijf doet, maar intern kunnen ze natuurlijk wel weer verwachtingen hebben over bepaalde taken.

Het management (de bestuurders die ingeschreven staan in de KvK) is per definitie (strafrechterlijk en privaatrechterlijk) accountable voor wat het bedrijf doet. Zij kunnen zich dan ook niet verbergen achter het argument dat ze er geen kaas van hebben gegeten en dit aan de IT-ers hebben over gelaten.

Dat staat echter los van de verantwoordelijkheid van de developers. Deze horen uit hoofde van hun functie op de hoogte te zijn van de regels (zoals wbp) en ze behoren over de expertise te beschikken om dit correct te doen. Deze developers zijn dus op z'n allerminst incompetent of op z'n ergst crimineel nalatig.

Wat dat betreft is het hoog tijd dat er eens een paar van dit soort figuren tesamen met hun management een tijdje op vakantie gaan in de bijlmer bajes zodat hun collega's zich beter realiseren wat hun verantwoordelijkheden zijn en ook doorkrijgen dat het weglopen/ontwijken/negeren van die verantwoordelijkheden ook daadwerkelijk consequenties heeft. Helaas is ons OM hierin veel te laks en laat het alles over aan de AP die op haar beurt ook veel te laks is en haar macht niet gebruikt.

Deze verantwoordelijkheden komen zowel bij de individuele lease maatschappijen als de software leverancier/data verwerker terug. Die kunnen zich ook niet achter elkaar verstoppen met argumenten als "dat moet de lease maatschappij regelen" of "dat is taak van de software leverancier".

Voor de software leverancier/data verwerker is deze verantwoordelijkheid klip en klaar. Voor de leasemaatschappijen ligt het iets ingewikkelder. Zij zullen in het algemeen geen toegang hebben tot de broncode van de software leverancier. Hierdoor neemt hun aandeel in de verantwoordelijkheid wel wat af. Ze zijn echter verplicht de juiste maatregelen te nemen om hun klantgegevens te beveiligen, ook en zelfs juist op het moment dat ze die uit handen geven. En als dat niet inhoudelijk kan dan moet het fallback scenario gebruikt worden, dus gecertificeerde software of eisen van en controle van resultaten van externe audit van de software. Indien ze dat niet aantoonbaar hebben gedaan neemt hun aandeel in de verantwoordelijk juist weer toe.

[MSalters]

Het management (de bestuurders die ingeschreven staan in de KvK) is per definitie (strafrechterlijk en privaatrechterlijk) accountable voor wat het bedrijf doet.

Het hele idee achter de BV (en NV) als rechtspersoon is nu juist dat het bedrijf als rechtspersoon aansprakelijk is, en niet de bestuurders of aandeelhouders. Dat is de absolute basis van bedrijfsrecht.

[Anoniem: 455617]

[...]

Het hele idee achter de BV (en NV) als rechtspersoon is nu juist dat het bedrijf als rechtspersoon aansprakelijk is, en niet de bestuurders of aandeelhouders. Dat is de absolute basis van bedrijfsrecht.

Bijna correct. Het klopt dat het bedrijf als geheel aansprakelijk is (dus de rechtspersoon blabla BV of blabla NV). Dat verminderd echter niet de persoonlijke aansprakelijkheid van de bestuurders (dat geld in het bijzonder voor diegenen die ingeschreven staan in de KvK als bestuurder).

Anders is een BV/NV niks meer dan een juridisch schild voor criminelen die daardoor onkwetsbaar worden. Zou handig zijn, je richt XTC B.V. op en dat bedrijf produceert en verkoopt dan XTC pillen, de winst keer je aan jezel uit. Wanneer de politie uiteindelijk het bedrijf oprolt blijf jij als eigenaar van buiten schot met al je crimineel verdiende geld. Zal niet zo gebeuren.

[MSalters]

Je originele stelling was dat onwetendheid van de bestuurders geen excuus is. En ook dat XTC voorbeeld is geen uitzondering. Een bestuurder van een onderneming waarin XTC gemaakt wordt is niet _qualitate qua_ aansprakelijk. Zou ook mooi worden, als de CEO van Akzo alle chemici in zijn bedrijf moet controleren op nevenactiviteiten.

Nee, ook voor bestuurders geldt dat je gewoon het strafrecht moet volgen, en bewijs tegen de persoon in plaats van de functie moet verzamelen. Eigenlijk de enige uitzondering is Sarbanes–Oxley, vandaar dat accountants van grote bedrijven daar zo op gefocussed zijn.

[Game_overrr]

Om eerlijk te zijn vind ik het een competentie van de devver om dit te begrijpen en in die hoedanigheid ook door te geven aan het management. Daar is het zaak hoe dit gebracht wordt uiteraard. Het management zelf heeft dan de verantwoordelijkheid dit op te pakken en ergens zal er een middleman moeten zijn om deze te te laten communiceren

[cracking cloud]

Lijkt me wel erg makkelijk om maar meteen management de schuld te geven zonder dat we alle details weten. Waar het hier om lijkt te gaan is het aanpassen van een id in de query string waardoor ze ineens in de omgeving van een andere klant zaten. Dat is gewoon slecht programmeerwerk. Ik heb dat ook wel eens gezien bij de beheer omgeving van een grote bungalowpark vergelijking site. Dat zijn programmeurs zonder een duidelijk besef van security. Zoiets dichttimmeren is echt niet veel werk (source: ik bouw zelf systemen waar dat wel gewoon gescheiden is)

[kozue]

Uuid's ipv een auto-increment integer gebruiken scheelt al een hoop. Er zijn genoeg gegevens die niet direct achter een login zitten, bv omdat een klant erbij moet en klanten geen account hebben (want erg klantvriendelijk is het niet om iedereen overal een account op te dringen). Als je dan links emailt naar deze gegevens met daarin een integer die op een klantnummer lijkt is het een koud kunstje deze aan te passen, maar probeer maar eens een uuid van iemand te raden.

[EgMaf]

Zo gepiept met brute force. Je hebt het immers over publiek toegankelijke links die per email verstuurd worden.

[Anoniem: 890159]

Dan heb je daartegen natuurlijk de oude truc van het steeds langer laten duren van de login: eerste verzoek van een IP adres - meteen antwoord goed of fout. Bij fout - 2 seconden wachten, bij weer fout 4 seconden, dan 8, etc. Dat bruteforcen gaat je niet lukken maar je pest iemand die een keer per ongeluk iets fout intypt niet heel erg.

[EgMaf]

Het probleem is dat het hier juist om directe links gaat, geen login nodig.

[Anoniem: 890159]

Dan wacht je na een fout 2 seconden met het doorsturen van de pagina (of 404 error) naar dat IP. Na 2 fouten 4 sec, etc.

[The Zep Man]

Zo gepiept met brute force.

Een UUID is 128 bit. Ga jij in die getalruimte maar proberen om de 250.000 waardes te vinden.

Maar goed, enkel UUID's gebruiken is security through obscurity. Bij een softwarepakket met zulke lekken zoals genoemd in het artikel verwacht ik dat ook hierbij nooit is stilgestaan.

[CH4OS]

Uuid's kunnen van alles zijn, hoeft echt niet per se 128 bit sterk te zijn.

[MSalters]

Nee, een UUID is precies 128 bits, dat kan niet "van alles" zijn. Het formaat is goed gedefinieerd.

Het echte probleem is dat niet elke UUID random is. Sterker nog, een gebruikelijk formaat is om de 48 bits van je MAC te gebruiken, plus een timestamp.

[Mythling]

Dan is het geen UUID: https://en.wikipedia.org/wiki/Universally_unique_identifier

[CAPSLOCK2000]

Lijkt me wel erg makkelijk om maar meteen management de schuld te geven zonder dat we alle details weten.

Heel kort door de bocht is het management altijd verantwoordelijk. Het management ziet toe op wie er wordt aangenomen en ontslagen, welke (veiligheids)procedures worden gevolgd, wat de werkwijzen zijn, op welke punten mensen worden beoordeeld en maakt een afweging tussen risico's en kosten.

De programmeurs hebben duidelijk zitten rommelen, maar de markt is helaas helemaal vergeven van de rommelaars. Een IT-bedrijf huur je nu net in om het kaf van het koren te scheiden. Een "normaal" bedrijf dat een slechte programmeur inhuurt kan ik begrijpen, een IT-bedrijf dat dit soort mensen in dienst heeft is een kwakzalver.

[himlims_]

Dit is gewoon slecht programmeer werk, management weinig mee van doen.

[Palomar]

Management kan er wel voor zorgen dat een derde partij kwaliteitscontrole doet op de code of op andere manier een beveiligingsscan. Belangrijke zaken als informatiebeveiliging moet je nooit toevertrouwen aan 1 persoon/partij.

[Corodix]

Inderdaad slecht programmeer werk, maar het management heeft ook zeker steken laten vallen. Blijkbaar heeft het management net zo weinig verstand van security, en hoe om te gaan met persoonsgegevens, als de programmeurs daar. Anders hadden ze onder andere wel regelmatig een audit laten uitvoeren. Het klinkt ook alsof ze geen testers hadden, of in ieder geval geen testers die verstand hebben van security, anders waren ze een aantal van deze fouten zeker wel tegengekomen.

Dit klinkt voor mij als zeer slecht programmeerwerk, en als een management laag die de veiligheid van persoonsgegevens niet serieus genoeg neemt, mogelijk expres om zo geld te besparen op testers/audits/etc. Als het management ook geen steken had laten vallen dan waren de fouten van deze programmeurs nooit op een live omgeving terecht gekomen.

[himlims_]

Daar wordt niet over nagedacht of is kennis niet aanwezig, zij kunnen alleen (juiste) beslissing nemen door goed geïnformeerd te worden.

Was dit geaudit of goed terug gekoppeld (vanuit IT) was dit waarschijnlijk ook niet gebeurd.

[418O2]

Helaas heeft niet elke developer dit gevoel van trots en krijgen zeker niet alle developers de ruimte om zulke dingen goed te fiksen.

[Motrax]

Ik ben benieuwd wanneer ik persoonlijk op de hoogte wordt gesteld dat mijn gegevens zijn gelekt... oh wacht... dat gaan ze zeker niet doen

Overigens is dit artikel net niet compleet: Volgens Verzekeringsbureau Voertuigcriminaliteit is het bekend dat criminele autobendes adressenlijsten en typen auto's in handen heeft en daarmee rondshoppen. Een dergelijk lek bij de leasemaatschappijen gaat hierbij niet helpen...

[adje123]

Hoe weet jij of je onderdeel ervan bent?

[MiesvanderLippe]

Omdat de organisatie waar het om gaat in het artikel genoemd word.

[Tankiej]

Waar dan? Ik zie alleen de naam van de software genoemd worden, nergens welke leasemaatschappijen deze software gebruiken..

[kozue]

Er wordt gesproken over een "centrale server", oftewel om 1 bedrijf dat diensten aanbiedt aan leasemaatschappijen (met zelfgeschreven software). De enigen die deze software gebruiken zijn dus klanten van dat bedrijf, en die staan gewoon op hun website genoemd (referenties). Natuurlijk kan het zijn dat er nog meer leasemaatschappijen waren die niet tussen de referenties staan, maar degenen die er in staan gebruiken het sowieso.

[Tankiej]

In de referenties staan er maar 6, daar blijven dus nog 46 over die (nog) niet bekend zijn.

[GEi]

Scroll ook door de nieuwsitems, iedere klant lijkt apart te worden verwelkomt.

[Skit3000]

Lijkt er op dat je hiervoor wel ergens al ingelogd moest zijn? Dat maakt de impact van het lek al minder groot.

Maar goed, zolang er überhaupt iemand (zoals een database administrator) gelijktijdig toegang kan hebben tot alle ongecodeerde gegevens kan een lek ontstaan.

[MiesvanderLippe]

"Het beveiligingsbedrijf vond de gegevens toen het op zoek was naar een nieuwe leasemaatschappij. " doet het niet klinken alsof ze bij de klant binnen stonden.

[Skit3000]

Je kan ook tussen de regels door lezen. Er is nu een link naar een blogpost waarbij staat dat er via een portaal ingelogd moest worden zoals ik dus al opmerkte.

[kozue]

En hoe wil je een database gaan beheren als een dba nergens bij kan? Lijkt me logisch dat alle gegevens gewoon toegankelijk zijn voor een dba, en op passwords na is het ook zinloos alles te gaan encrypten. Immers moet het nog steeds leesbaar zijn door de applicatie zelf, en dat is waar de lekken normaal gesproken in zitten. De meeste databases zijn niet direct vanaf het internet bereikbaar maar alleen via de applicatie, en die laat alles gewoon op het scherm zien.

[MSalters]

Dat is een klassieke denkfout. Een DBA hoeft niet bij unencrypted klant-data te kunnen. Daar is geen simpelweg geen business reden voor. En in een heleboel sectoren waar securiy serieus wordt genomen is toegang tot data voorbehouden aan diegenen die er uit hoofde van hun functie toegang toe moeten hebben. Een DBA mág dan niet eens toegang hebben.

Op dezelfde manier mag een applicatie met ingelogde user ook alleen bij de data van die desbetreffende user. Data van andere users moet encrypted blijven.

[Skit3000]

Juist. Sterker nog, wat als de DBA een backup maakt op een USB stick, en die raakt zoek? Of die backup gaat naar een testomgeving waar opeens de developers er ook bij kunnen, en waar later klanten op getraind worden, of welke vrijgegeven wordt als demo-omgeving voor nieuwe klanten?

Alles is te voorkomen door vanaf stap één encryptie toe te passen op recordniveau.

[Skit3000]

Waarom moet de data leesbaar zijn door de applicatie zelf? De enige die belang heeft bij het kunnen lezen van de gegevens is de ingelogde klant zelf.

De data had gewoon met één sleutel per actor gecodeerd kunnen worden. De eerste actor is de klant zelf, die al zijn eigen gegevens mag kunnen zien. Een andere actor is bijvoorbeeld het geautomatiseerde proces dat de kilometerstanden uit mag lezen om zo facturen te kunnen sturen, maar die hoeft dan weer niet de privégegevens van de bestuurder te zien maar enkel de gegevens van de werkgever. Een derde actor is het proces dat een factuur naar de privépersonen stuurt wanneer zij een boete hebben gekregen, waarbij zij dus wel aan de hand van het kenteken de adresgegevens van de bestuurder mogen terughalen, maar niet de gegevens van eerdere boetes mogen zien.

Ik denk dat het zelfs nog verder uitgesplitst moet worden, waarbij de beheerder van een database nooit zelf de mogelijkheid mag hebben om gegevens van meerdere klanten simultaan te verwerken. Als je dan bij een webshop iets besteld, zou je een willekeurig bestelnummer moeten krijgen dat je daarna zelf doorgeeft aan je pakketbezorger, zodat zij het op kunnen halen en bij jou thuis brengen zonder 1) dat de pakketbezorger weet wat ze bezorgen en 2) zonder dat de webshop weet wie een bepaalde bestelling heeft geplaatst. Als je betalingen ook op een dergelijke manier verwerkt, kan één gelekte database nooit meer tot resultaat hebben dat je NAW gegevens plus welke gegevens daar ook aan gekoppeld zijn, tegelijk op straat komen te liggen.

[Roflmaker]

Sessie kon je ook overpakken / gokken

[Skit3000]

Dat je je eigen sessie aan kon passen was al duidelijk voor de update van het artikel, mijn opmerking ging er alleen over dat je al ingelogd moest zijn wat toen nog niet duidelijk stond opgeschreven.

[Blommie01]

Wel grappig om de vacature die op de site staat te lezen... Ze zoeken een starter, maar als je verder leest heb je al een behoorlijk wat kennis voor een MBO-er nodig... De pagina is ook een kopie van een eerdere "vacature programmeur" als je goed kijkt.

https://carwise.nl/vacature-service-engineer-starter/

Uiteraard wel marktconform salaris. Lees: "wij betalen zo weinig mogelijk"

Ik kan me wel voorstellen dat het ergens behoorlijk mis is gegaan.

[Reactie gewijzigd door Blommie01 op 22 juli 2024 22:12]

[Muttley]

Nou, er staat ook: Vakkennis onderhouden van jezelf en je directe collega’s
Schijnt nodig te zijn....

[Reactie gewijzigd door Muttley op 22 juli 2024 22:12]

[Maxxi]

Citaat: 'Je begrijpt onze ‘Afspraak=Afspraak’ mentaliteit.'
Wat bekend dit überhaupt? Als je een deadline hebt dan mag je die niet schenden?

Zal de kwaliteit niet ten goede komen.

[Anoniem: 632601]

Tja toevallig ken ik de leverancier, als je maar met een heel klein team werkt. (lees 1 programmeur)
Dan is een vorm van kwaliteitscontrole wel heel lastig.

[Blommie01]

Onvoorstelbaar toch... Maar zal wel een sr. programmeur met een marktconform salaris zijn

Dubbeltje op de eerste rang en proberen zo veel mogelijk geld te verdienen/over te houden.

[Reactie gewijzigd door Blommie01 op 22 juli 2024 22:12]

[HarryL]

Dit is wel bizar
Ben benieuwd of de getroffen Leasemaatschappijen ook een bericht sturen naar de "getroffen" leaserijders.

[kevinwalter]

Zojuist een mail gehad van SternLease dat zij niet getroffen zijn!

"Leasemaatschappij SternLease niet getroffen door CarWise datalek
Geachte heer,
Beveiligingsbedrijf ESET bevestigde gisteren dat de software LeaseWise, van CarWise ICT, een datalek bevat waardoor de gegevens van duizenden leaserijders toegankelijk waren. Inmiddels is het lek gedicht. Graag verzekeren wij u dat SternLease geen gebruik maakt van de LeaseWise software.
Zorgeloos rijden is een van onze belangrijkste doelstellingen. Naar aanleiding van dit nieuws vonden wij het gepast om u hierover te informeren.
Met vriendelijke groeten,
SternLease"