Gegevens van 296.000 Toyota-klanten uitgelekt via websitebroncode op GitHub

Er zijn gegevens van 296.000 Toyota-klanten uitgelekt. Dit komt doordat een deel van de broncode van de Toyota Connect-website vijf jaar lang beschikbaar is geweest via een openbaar GitHub-account. In de broncode zat een key die toegang verschafte tot de server met klantgegevens.

Toyota Connect is een app waarmee Toyota-bezitters informatie over hun voertuig kunnen zien. Via de officiële website van de app kunnen gebruikers een account aanmaken. De autofabrikant legt uit dat het desbetreffende GitHub-account van het bedrijf de Toyota Connect-website heeft gemaakt. Dit account bleek echter openbaar te zijn. Hierdoor was de broncode voor iedereen toegankelijk van december 2017 tot en met 15 september 2022, de dag waarop Toyota achter het lek kwam. Op dezelfde datum is het GitHub-account privé gemaakt. Twee dagen later is de key in de broncode veranderd.

De uitgelekte gegevens bestaan uit de e-mailadressen en klantnummers van 296.019 klanten. Andere gegevens, zoals namen, telefoonnummers en betaalgegevens, zijn niet uitgelekt, zegt Toyota.
De fabrikant heeft naar eigen zeggen onderzoek laten doen door beveiligingsdeskundigen. Daaruit is nog niet gebleken of derden toegang hebben gehad tot de server. Toch kan Toyota niet uitsluiten dat er misbruik is gemaakt van het lek en daarom heeft het de getroffen klanten op de hoogte gebracht.

Reacties (48)

[avec_style]

Je vind hier de engelse vertaling terug van de communicatie van Toyota.
https://global-toyota.tra...x_tr_hl=en&_x_tr_pto=wapp

Toyota heeft ook een webformulier beschikbaar gesteld waarmee je kunt checken of jouw e-mail adres ook geraakt is door de datalek. Na het invullen van het formulier zou je een mail moeten krijgen met de gevraagde info. Let op: formulier is in het Japans!

https://translate.google....m/pub/co/contact-tconnect

[schrikbeeld]

Ik heb een vraag over deze hack gesteld aan mijn Toyota dealer (Van Gent, Ede) en kreeg al heel snel het volgende antwoord terug:

Beste meneer xxxxxx,

Dank voor uw bericht.

Bij mijn weten is er geen actueel datalek wat Europese en dus ook onze klanten betreft.

We heb ik vorige week het onderstaande bericht gelezen over hetzelfde datalek als waar tweakers over bericht. Zij hebben wel navraag gedaan bij de PR afdeling van Toyota Nederland en zij geven hierin aan dat het geen klanten in Europa betreft. Zie de volgende link:

https://automotive-online...tgegevens-mogelijk-gelekt

Bent u met dit bericht voldoende beantwoord en gerustgesteld? Anders hoor ik u graag.

Voor nu een fijne avond!

Met vriendelijke groet,
Van Gent Autobedrijf

[Netrunner]

Ik heb alles weten te vertalen naar Engels. Stel dat ik op de lijst sta, wat gebeurt er dan?

[avec_style]

Dat weet ik helaas ook niet. Ik heb zelf het formulier ingevuld en daar een bevestigingsmail van gekregen (in het Japans). Ik wacht nu op hun vervolgmail.

Maar ik denk niet dat je veel kunt doen als je op de lijst staat. Je moet er gewoon rekening mee houden dat jouw data doorverkocht kan worden. Of dat hackers proberen jou te benaderen voor phishingpraktijken.

[secret2000]

Ik maak me soms best zorgen over de privacyrisico's van de verregaande koppeling van informatiesystemen met het internet. Datalekken zijn aan de orde van de dag en niet alleen bij amateuristische partijen maar ook bij gerenommeerde bedrijven en overheden. Toch blijft de trend om steeds meer systemen met gevoelige systemen te koppelen en via het internet te ontsluiten. Als klant of burger is het lastig om te bewijzen wat de schade is van een datalek en blijf je in onzekerheid achter. Serieuze sancties voor het maken van fouten met beveiliging ontbreken. En ondertussen is het steeds lastiger om overheidsdiensten te gebruiken zonder DigiD en wordt er gewerkt aan een met internet verbonden elektronisch patiëntendossier dat je niet meer kan weigeren.

[fifanoob]

Wordt het niet een x tijd dat je als particulier hier een schade vergoeding kan krijgen?
Misschien dat het bedrijven dan wat meer motiveert om hun shit goed te fixen.

Want wat zijn de financiële consequenties nu voor dit bedrijf? Wat is dan hun motivatie om hier meer geld tegen aan te gooien?
De schouders worden opgehaald en we gaan weer verder met de dag.

Net als dat gemeentes opeens je e-mail adres hebben gelekt. Iets met meerdere adressen in de cc wat iedereen kan zien..
stel je daar vragen over om iemand te verantwoorden, dan word je van het kastje naar de muur gestuurd.
Maar als ik een aantal privé e-mail adressen die ik weet van hoge ambtenaren en politicussen openbaar dan weet ik nu al dat ik binnen 24 uur een agent voor de deur heb staan.

[JeroenH]

Toyota mag op meer vlakken wel eens wat doen aan privacy-bescherming. Toen ik mijn gebruikte Prius bij de dealer kocht, zat de boordcomputer nog vol met gegevens van de vorige eigenaar. Haar naam, adres, lijst met laatste navigatiedoelen, contactpersonen uit haar telefoon, etc.

Ik heb het maar gewoon gewist allemaal, maar fraai is het natuurlijk niet.

[mjtdevries]

Is het de verantwoordelijkheid van Toyota om die data te verwijderen, of de verantwoordelijkheid van de vorige eigenaar?
Het zou wel een mooie service zijn als ze dat doen om mensen tegen zichzelf te beschermen.

[JeroenH]

Vind ik wel. Zo'n ding krijgt onderhoud, wordt tip top schoongemaakt, enz. Dan vind het ik niet "schoonmaken" van de boordcomputer uit de toon vallen. Zou slechts één extra vinkje op de checklist zijn.

[uNoTopia]

Lijkt mij meer een kwestie voor de handelaar/autogarage, niet voor Toyota als fabrikant. Die weet namelijk niet of en wanneer een auto verkocht wordt.

[Bert2000]

Leaseplan ook, kreeg een tijdelijke ford fiesta, met zelfde gegevens nog in de navigatie.

[YGDRASSIL]

Precies hetzelfde bij mijn huisselectie tweedehands bmw. Ook complete adresboek vorige eigenaar..

[Dannyyy]

Ooit had ik een volkswagen polo en daar stonden ook alle gegevens in van de vorige eigenaar.

[sys64738]

Wauw. Das je een publieke GitHub repo gebruikt zonder daar bij stil te staan of je er uberhaupt van bewust te zijn, is al vrij ernstig. Maar dan ook nog keys in je sourcecode die toegang geven tot je prod servers. Das wel heel ernstig.

Zelfs al zou je repo private zijn dan nog hebben al je devs en andere mensen met toegang tot je repo dus vrije en anonieme toegang tot je productie servers. Jikes.

[Frikandel]

Ik denk dat het je zal verbazen bij hoe veel bedrijven ontwikkelaars gewoon directe toegang tot een productie database of server hebben. Pas als applicaties echt veel gebruikers krijgen (denk boven de miljoen) gaan sommige bedrijven er pas aan denken dit te limiteren. En dan nog steeds is dit niet altijd netjes geregeld.

[wiseger]

Nee hoor. Bij heel veel bedrijven is dit streng verboden. Daar is dev/uat strikt gescheiden van prod. Daar scant men code op hard coded accounts / passwords / certificaten.
Aantallen gebruikers doet er totaal niet toe.

[divvid]

ook gewoon bij OSS code behorend bij een klein non-profit project doen we dit al hoor. Kwestie van awareness

[supersnathan94]

Directe toegang tot een DB is soms ook gewoon noodzakelijk om Ops te kunnen doen. Soms moet je gewoon even kunnen debuggen. Ik ben dan ook niet tegen directe toegang. Ik ben wel tegen anonieme directe toegang. Als je in je ontwerp rekening houd met auditlogging is het wat mij betreft geen enkel probleem. En dan ook zorgen dat die logging lang genoeg beschikbaar is en daar actief naar gekeken wordt (periodieke controles en vragen stellen). Liefst met 4 eye principle.

Je hebt uiteindelijk ook gewoon te maken met een stukje mutual assured destruction. Als jij er met de data vandoor gaat is dat ruk voor mij, maar betekent ook dat je geen VOG meer gaat krijgen dus succes met de rest van je carrière.

Voor mij dan ook reden genoeg om er voor nog geen miljoen gekke dingen mee te gaan lopen doen.

Maar ja hardcoded tokens moet je er gewoon in graveren dat dit ook echt niet kan. Is ook tooling voor om dit voor een aantal zaken te doen (beetje standaard .gitignore bijvoorbeeld)

Github maakt het gelukkig ook steeds makkelijker om dit te voorkomen door bijvoorbeeld repository secrets. Hoef je de tokens alleen maar daar in te zetten en kun je ze met github actions als env var gebruiken in je deployments bijvoorbeeld.

[mrdemc]

Debuggen doe je natuurlijk niet op productie, maar je hoeft geen toegang te hebben tot de gegevens wanneer je ergens DB toegang toe hebt. Als je een eigen gebruikersnaam hebt, kan het (in ieder geval bij bijv. MSSQL) op gebruikerniveau ingesteld worden dat specifieke velden niet zichtbaar zijn voor jou qua waarde.
Zie ook bijv.:
https://learn.microsoft.c...ing?view=sql-server-ver16

[supersnathan94]

Debuggen moet soms wel op productie. Want bug ergens. En soms moet je dingen met de hand aanpassen omdat er 1 dingetje niet goed is gegaan. Of één of andere specifieke edge case (zoals van tevoren niet bedacht hebben dat een int32 als ID niet zo handig is) waardoor je gewoon even moet zien wat de staat van productie is.

En bepaalde velden afschermen kan dan ook een hulpmiddel zijn om een audit netjes door te komen. Ik weet alleen niet of dat bij zaken als Postgres ook kan. Ik werk namelijk eigenlijk nooit met MSSQL.

[mrdemc]

Debuggen doe je dan op een kopie van de productie-omgeving. Patches moet je eigenlijk ook via de normale weg doen, anders heb je kans dat je een bug herintroduceert bij een volgende release.

Voor PostgreSQL is dat niet standaard, maar er is wel een extensie voor:
https://www.postgresql.or...design-for-postgres-2452/

[Reactie gewijzigd door mrdemc op 26 juli 2024 18:47]

[supersnathan94]

Debuggen doe je dan op een kopie van de productie-omgeving.

Inclusief data? Want dat is dus waar het om gaat. Dat het dan niet in productie staat maakt dan niet zo veel uit.

Daarnaast is het geheel afhankelijk van je workflow. Ik heb situaties waar die workflow is ingeregeld (in de vorm van OTAP), maar ben zelf ook juist met de versimpeling van dergelijke zaken bezig dmv cloud en preview environments (waarbij OTA dus een enkele omgeving is geïsoleerd van andere zaken).

Tweede punt is dan ook jog wag je verstaat onder debuggen. Vanuit exceptionlog opzoeken wat er precies in je db terecht is gekomen waarom dat specifieke ding fout gaat valt daar ook gewoon onder. En daarna ga je dag met die gegevens dan reproduceren ja.

[Blokker_1999]

Een foutje is snel gemaakt

[Martinspire]

Emails en klantnummers zeggen weinig, dus qua datalek is het niet echt indrukwekkend lijkt me. Maar het is wel een dingetje wat voorkomen had kunnen worden.

[sys64738]

Wie zegt dat er echt alleen maar klantnummers en email-adressen zijn buit gemaakt? Ja, Toyota. Maar ik vind het altijd grappig dat bedrijven die hun zaakjes zo slecht in orde hebben, altijd wel snel en met stelligheid kunnen zeggen dat er niets of vrij weinig is buit gemaakt.

[Christoxz]

altijd wel snel en met stelligheid kunnen zeggen dat er niets of vrij weinig is buit gemaakt.

Het is de vraag of ze open kaart spelen, maar het is niet per definitie lastig om achter te komen tot waar er toegang was.
Neem aan dat de key alleen toegang had tot een DB zonder naam gegevens.

En ook is het niet 'snel', er zit 3 weken tussen het lek & het pers bericht.

It was discovered that the published source code contained an access key to the data server, and by using it, it was possible to access the e-mail address and customer management number stored in the data server.

[Menesis]

Dat is toch amateurisme? Credentials in je got repo proppen….

[Hatsekie_D]

Absoluut. Gebeurt bij geen enkel ander groot bedrijf.

[gimbal]

Ik snap die reactie totaal niet. Wil je stellen dat "grote bedrijven" nooit amateuristisch kunnen zijn?

Nee, elk bedrijf heeft het vermogen om de ontwikkeling uit te besteden aan beunhazen.

[Hatsekie_D]

Dat bedoel ik juist niet, mijn opmerking was sarcasme.
Er zitten regelmatig fouten van een dergelijk kaliber in software, bij bedrijven van elk formaat. Ook bij bedrijven die niet in de categorie 'beunhazen' vallen.
Ik bedoel eigenlijk ook gewoon te zeggen dat een dergelijke fout snel gemaakt is.

[uNoTopia]

No offense, maar het zou veel prettiger lezen als je dat dan als opmerking plaatst in plaats van een sarcastische post. Dan voorkom je onduidelijkheid, reageren anderen in ieder geval on-point én het is in algemene zin ook beter voor de 'sfeer' hier in de commentsectie

[mangahuisman]

Had meteen door dat het sarcastisch was.....

[dasiro]

een risico van open source, onzorgvuldig geschreven/gereviewde code kan misbruikt worden, zelfs al was die nooit bedoelt om te worden gepubliceerd

[gimbal]

We moeten dit allemaal lezen en voor onszelf inzien: jaarlijkse security audits en pentesten zijn duur en vreselijk irritant (want ze komen altijd met een waslijst aan zeuropmerkingen)...

En zo noodzakelijk.

[Anonymoussaurus]

Er zijn al oplossingen zoals secret scanners die voorkomen dat je code kan committen als er secrets in staan.

[RRX]

Hmm, ik had een aantal weken geleden dat ik ineens een mail kreeg dat mijn auto verwijderd was uit mijn Toyota account. Ik heb Toyota toen gemaild en die konden het niet verklaren. Zou dat stiekum zijn gedaan ter voorkoming van verder misbruik?

[Yzord]

Mooi man, open source. Sommige devs nemen het wel heel letterlijk haha.



Edit: zo dan, een grapje mag niet meer op “vriendelijk Tweakers”?

[Reactie gewijzigd door Yzord op 26 juli 2024 18:47]

[HitDyl]

De developer heeft een key in de broncode laten zitten. Daar zit je fout, niet het feit dat de code openbaar was.

[Yzord]

Dat zei ik toch?

[HitDyl]

Heeft 0 met opensource te maken.

[jaenster]

Als ik al onze klant gegevens in onze code base commit, is het iig niet voor de hele wereld om in te zien, gezien het closed source is. Dus ja, dit specifieke issue is alleen z'n groot issue bij open source.

Alleen was dit niet de bedoeling om open source te zijn, zo ver ik het article snap.


@IStealYourGun / @Ludewig ik snap dat het niet de bedoeling is om dat te committen in een welke repo dan ook. Mijn punt is dat het je het in een opensource repo gelijk deelt met de hele wereld

[Reactie gewijzigd door jaenster op 26 juli 2024 18:47]

[IStealYourGun]

Secrets en keys horen niet thuis in een version control systeem. Om nog maar te zwijgen dat dat je de key's regelmatig moet vervangen.

[Ludewig]

Closed source code wordt ook regelmatig gelekt. Het is gewoon niet handig om niet-encrypted keys en wachtwoorden in je code te hebben staan.

[Byte]

Gewoon een nieuwe term introduceren: 'open database'

[jaenster]

Oh je bedoeld een blockchain?

[Anonymoussaurus]

Behalve dat je in een public permissionless blockchain geen private keys opslaat...