Mercedes-Benz lekt per ongeluk eigen broncode via GitHub

Autofabrikant Mercedes-Benz heeft per ongeluk zijn eigen broncode gelekt via GitHub. Dat kwam doordat het GitHub-token van een medewerker in een public repository terecht was gekomen. Het token is inmiddels ingetrokken en de repository is offline.

Het lek werd deze maand ontdekt door beveiligingsonderzoeker Shubham Mittal, die nieuwssite TechCrunch op de hoogte bracht. Volgens Mittal zou het token iedereen onbeperkte toegang kunnen geven tot de GitHub Enterprise Server van Mercedes. Daarop staan onder meer belangrijke documenten, broncode en wachtwoorden van de autofabrikant, schrijft Techcrunch op basis van het door Mittal aangeleverde bewijs. Het is niet bekend of er klantgegevens in de repository aanwezig waren.

TechCrunch had het lek maandag gemeld bij Mercedes-Benz. Woensdag bevestigde een woordvoerder aan de site dat het token was ingetrokken en de repository offline was gehaald. Volgens het bedrijf ging het om een menselijke fout en is er een onderzoek naar het lek gaande. Het is nog niet duidelijk of het lek is ontdekt door andere partijen.

Reacties (120)

[Microwilly]

Gebruik zelf veel GitHub ( voor kleine projectjes ) Maar is dit wel verstandig voor Mercedes Benz i.v.m. bedrijfs geheimen.

[Reactie gewijzigd door Microwilly op 22 juli 2024 20:39]

[CyBeR]

Gebruik zelf veel GitHub ( voor kleine projectjes ) Maar is dit wel verstandig voor Mercedes Benz i.v.m. bedrijfs geheimen.

GitHub Enterprise waar het om gaat is de self-hosted versie van GitHub. Dat is gewoon een platform wat je op je servers host en dan heb je een privé git host met de interface van github.

Het probleem was dat de toegangsgegevens daarvoor van een medewerker in een normale, publieke, repository terecht zijn gekomen.

[pang-frang-punk]

Nee, GitHub enterprise is het enterprise cloud model van GitHub dat werkt met extra functionaliteiten, afgescheiden van de rest van GitHub op bepaalde vlakken, maar nog steeds volledig cloudgebaseerd afneembaar.

[CyBeR]

Nee, GitHub Enterprise Server (wat in het artikel staat) is self-hosted op je eigen servers. Dat is een harde vereiste voor veel organisaties van het kaliber Mercedes.

Jij hebt het over GitHub Enterprise Cloud, ook een mogelijkheid.

[Reactie gewijzigd door CyBeR op 22 juli 2024 20:39]

[swtimmer]

Bij ons is die Github server ook nog eens niet toegankelijk voor het internet. Ik zou verwachten dat bij MB deze ook alleen via VPN/netwerk te benaderen is.

[pang-frang-punk]

Och, goeie opmerking inderdaad, dankjewel. Dit was eventjes een kwestie van informatiebubbel doorbreken.
Het was duidelijk weekend op het moment van posten. En ik had nog geen koffie op.
Groet!

[Skywalker27]

Nee die managers willen alles in de cloud hebben het interesseert ze niet of het secret is of niet.

[vgroenewold]

Ahhh dat detail had ik ook gemist. Heel interessant, dan ga je bijna denken aan een copy paste actie ofzo.

[PdeBie]

Waarom niet? Doet Microsoft toch ook met bijvoorbeeld visual studio code?

[Microwilly]

Visual studio code is opensource ^^ + USA
Dacht meer Mercedes Duits bedrijf. Misschien tech waar Amerikaanse bedrijven iets aan hebben.

[Reactie gewijzigd door Microwilly op 22 juli 2024 20:39]

[langestefan]

Toch bizar dat dat nog steeds kan gebeuren. Helemaal met alle automatische token/secrets/password scans die GitHub aanbiedt (en welke MB ook zelf zou moeten hebben).

[Archcry]

Nja, er zijn ook automatische tools om SSL certificaten automatisch te laten renderen maar je ziet toch ook nog steeds websites van (grote) bedrijven waar het SSL certificaat verloopt. Om maar even een voorbeeld te noemen.

De core business van Mercedes is ook niet software maar het bouwen van autos. Waarschijnlijk is software daarom ook een ondergeschoven kindje in de organisatie.

[Reactie gewijzigd door Archcry op 22 juli 2024 20:39]

[langestefan]

Automotive is juist een van de meest veeleisende afdelingen qua kwaliteit waar je als software engineer zou kunnen werken. Een moderne auto doet zonder software doet niks meer, minstens net zo belangrijk als het mechanische deel.

[laurxp]

Helaas is dit in de praktijk lang niet altijd het geval. Denk bijvoorbeeld aan de Jeep die via wifi te crashen was, of Tesla-medewerkers die klanten bespieden. Er komen zat auto's op de weg met dodelijke softwarebugs.

Het "kritieke" gedeelte maakt vaak gebruik van platforms als AUTOSAR - en de mensen die met AUTOSAR moeten werken zijn er niet bepaald blij mee. Ik denk dat een stukje willekeurige code wel duidelijk maakt dat het hier niet om de crème de la crème van de software-industrie gaat. Zelfs Volvo is er niet heel blij mee en actief op zoek naar alternatieven.

En infotainment is in essentie niet veel anders dan Android als je geluk hebt, embedded Linux, of als je pech hebt een zelfgebakken monster. Het is niet levenskritisch, dus daar zal ook niet bijzonder veel geld naar software-kwaliteit gaan.

Dus nee, automotive is niet de wereld waar je de best mogelijke software zal vinden.

[Reactie gewijzigd door laurxp op 22 juli 2024 20:39]

[TheVivaldi]

Infotainment is juist vaak QNX.

[Mielemuis]

Heb zelfs nog Windows CE gezien als infotainment,
Dit wordt vaak uitbesteed aan fabrikanten als LG of TomTom die dan in-house hun voorkeurs platform hebben

[bzzzt]

Infotainment is juist vaak QNX.

Volgens mij steeds meer Android auto of een andere Linux gebaseerde oplossing.
En soms dubbel: mijn Volvo doet beide (QNX voor het weergeven van het kilometerteller scherm en een vage Linux distro voor auto's met een eigen sausje voor het infotainment scherm inclusief GPL en curl licentie die je via de menu's op kan roepen).

[laurxp]

Verrek, ik wíst dat ik iets aan het vergeten was. Laten we dat voor het gemak maar onder "embedded Linux" scharen.

[Zebby]

Wat dacht je van de ID lijn die hoe lang klaar stond maar niet kon uitrollen door software problemen?

Autofabrikanten zouden voor software engineers on par moeten gaan staan met de grote IT spelers van de wereld.
Zie jij ze ooit genoemd staan? Tesla misschien de uitzondering.

Het is een bende. Dat is niet zo zeer de schuld van de engineers, maar wel van de geldhaaien. Vroeger merkte je minder van de fouten omdat alles nog mechanisch werkte wat belangrijk was. Nu er steeds meer naar software verhuist hou ik mijn hart vast.

[peewee.]

Vroeger had je een Volkswagen Kever met een 1200 cc motortje waarmee je blij mocht zijn als die de 1 op 10 haalde.

[Skywalker27]

VW is tegenwoordig gewoon een software bedrijf hoor en dat wordt alleen maar meer. Onze IT afdeling is de laatste tijd gegroeid niet normaal meer.

[blackSP]

Software problemen zijn helaas niet beperkt tot de automotive industrie.

https://duckduckgo.com/?q...ware+failures&df=y&ia=web

[laurxp]

Uiteraard niet!

Ik reageer puur op de claim dat het de "meest veeleisende afdelingen qua kwaliteit waar je als software engineer zou kunnen werken" is. Er zijn zát andere industrieën waar men software schrijft die complete bagger is, maar niemand claimt dat ze daar software van hoge kwaliteit schrijven.

[PTR]

Die reddit reactie is een prachtig stuk dev leed!

"Hey thanks for spending all that time learning all that cool stuff that we can't use, here's the MSPaint equivalent of embedded software development platforms, we need Mona Lisa by lunch."

Treurig dat autosar blijkbaar precies het tegenovergestelde doet van wat het idee van een standaard/platform zou moeten zijn.

[Reactie gewijzigd door PTR op 22 juli 2024 20:39]

[yatogami28]

Komen ook zat software in andere markten met vergelijkbare bugs.

Heeft niks specifieks met auto sector te maken. Mensen fouten gebeuren altijd

[langestefan]

Dat zijn veel if-statements...

[Pep7777]

En daaromheen nog een heleboel conditional compilations tot in switch cases aan toe en dan ook nog global variables. En nog erger ik kan geen unit test bespeuren

[Geneuzel]

'Dus nee, automotive is niet de wereld waar je de best mogelijke software zal vinden.'

TomTom (en microsoft e.d) gaan u binnenkort verbazen...

[Jack77]

Weet er iemand eigenlijk welke broncode publiek toegankelijk was?

Want zonder extra uitleg, kan het even goed om code van een reservatie-systeem ofzo gaan. Ook niet top. Maar veel minder schadelijk dan controlling software van een voertuig.

[Barsonax]

De vraag is of het management dat ook zo ziet en dat betwijfel ik.

[Raymond Deen]

Ondergeschoven kindje? Software afdeling van elk automerk werken ook gewoon professionals neem ik aan.
Dit is gewoon slordig. Als je dan ziet dat er ook wachtwoorden en belangrijke documenten in de repo zitten dan verdient degene die dat zo bedacht heeft toch een stevig woordje met zijn of haar leidinggevende, want dat hoort sowieso niet in één repo bij elkaar te zitten.

[Webgnome]

Het zijn net mensen. En mensen maken fouten. Of dat bewust is of niet. Is irrelevant.

[Raymond Deen]

Ja, mensen maken fouten. Daar heb je helemaal gelijk in, maar ik hhad het niet over bewust of onbewust.

Fouten opnieuw maken die de afgelopen tijd al vaker - met rampzalige gevolgen - gemaakt zijn, en die door de tooling te gebruiken en standaarden te volgen, te voorkomen zijn, is gewoon niet goed te praten.
Je hebt het bij software, ook al is het een autofabrikant, tegenwoordig over het hart van het bedrijf en product en dan hoor je daar ook naar te acteren.

Kom op zeg, één github-token publiekelijk toegankelijk en je hele bedrijf ligt te grabbel?!? Hoe verzin je het in hemelsnaam? Zo'n token zegt helemaal niets over waar je vervolgens moet kijken om het daadwerkelijk te gebruiken. Dat betekent dat er wel wat meer info openbaar was dan alleen het token.

Daarnaast vind ik het nogal vreemd dat je zomaar op een GitHub Enterprise Server, self hosted dus, kunt komen zonder firewall bescherming oid.

Hier zijn echt meerdere forse steken laten vallen.

[lennartvdd]

Firewall ja. Waarom als je het self-hosted neerzet niet op een gesegmenteerd en afgeschermd netwerk?
En wachtwoorden in git… ugh..

[Verwijderd]

Webgnome schreef:

Het zijn net mensen. En mensen maken fouten. Of dat bewust is of niet. Is irrelevant.

En omdat elk weldenkend mens dat weet, én omdat er om de cloud geen slotgracht zit, nemen weldenkende mensen gepaste mitigerende maatregelen. Zoals (én/én) het verplicht laten volgen van trainingen, minstens 4 ogen, checklists, audits, red/blue teams etcetera.

Als je dat allemaal niet wilt of te prijzig vindt, was de stap naar de publieke cloud wellicht toch niet zo'n goed idee. Want in die publieke cloud kan elke fout van slechts één medewerker enorme consequenties hebben voor een heel bedrijf.

[vgroenewold]

Ik snap eigenlijk sowieso niet waarom ze een publieke cloud gebruiken. Je kan dit soort zaken toch prima zelf regelen en uitzetten naar alle ontwikkelaars? Eventueel in je eigen cloud.

[Kenhas]

Volgens het artikel gebruiken ze GitHub Enterprise Server en dat is, voor zover ik weet, een self-hosted oplossing.
Maar om één of andere reden stond er een toegangstoken, waarmee je toegang kreeg tot die interne github, op de publieke github.

Je mag het nog zo dicht timmeren, als je dan je paswoord op internet zet, ben je er niet zoveel mee

[vgroenewold]

Ja dat las ik verderop idd, daar valt dan weinig aan te doen. Behalve je engineers verbieden github te gebruiken.

[Verwijderd]

vgroenewold schreef:

Ik snap eigenlijk sowieso niet waarom ze een publieke cloud gebruiken. Je kan dit soort zaken toch prima zelf regelen en uitzetten naar alle ontwikkelaars? Eventueel in je eigen cloud.

Precies. Reken maar dat concurrenten nieuwe automodellen ASAP reverse engineeren zodra die op de markt komen, maar daar kan je weinig tegen doen.

Als cybercrims éérder de hand kunnen leggen op dit soort "warez", hebben meerdere concurrenten, verspreid over deze aarbol, daar vermoedelijk flink geld voor over.

Maar sowieso zou ik ook (de software van) onze vrienden in noord-Amerika niet de laatste kroonjuwelen van het bedrijf blind toevertrouwen (of het allemaal precies zo gegaan is als in Wikipedia opgetekend weet ik niet, maar industriële spionage is verre van nieuw (#Echelon #Erercon #Kenetech #1999)).

[Reactie gewijzigd door Verwijderd op 22 juli 2024 20:39]

[blinchik]

Helemaal mee akkoord. Maar je hebt ook managers, dev-tools, automation, allerlei zaken die je aan git koppelt en soms worden producten nog maar enkel in de cloud aangeboden. Atlassian Jira is bijvoorbeeld vanaf dit jaar niet meer on-premise beschikbaar. Ik vind het ook een zeer slechte evolutie, maar het is niet meer zo zwart-wit om dingen uit de cloud te houden.

[tdj_go]

Jira data center is als on-premise optie beschikbaar, maar wel bijna net zo duur als de cloud.

[blinchik]

Jira server was on premise beschikbaar, en bijna zo duur als de cloud.

Nu is er inderdaad wel een Datacenter editie die nog on-premise is, maar die is onbetaalbaar en veel duurder dan de cloud: 17k voor 50 man

[DDX]

Je linkt nu naar jira service management.
Jira zelf is datacentre nog een stuk duurder/instap vanaf 500 licenties nml :
44 duizend dollar https://www.atlassian.com...a/pricing?tab=data-center

[Immutable]

Ja je moet bepaalde code publiceren. Iets met licenties.

[grosny]

in de huidige tijd moet je voorzichtig zijn als klokkenluider, toch relevant dat het nu gebeurd

[Chevy454]

Professionals, wat zijn dat? Zijn dat mensen met geweldige coding skills of zijn dat mensen die weten hoe het tandwieltje in het geheel werken?

We hebben meer als genoeg coders die code kunnen schrijven maar de achterliggende ideeën niet zien en bijgevolg onbedoelde pitfalls maken.

Dan is de specificatie fout zeg je dan. Wie maakt de specificatie, een expert professional? Is dat iemand die weet hoe software werkt of iemand die weet hoe het tandwieltje in de machine zit zonder te weten uit welk materiaal het tandwiel is gemaakt?

....


Het is een nachtmerrie de automotive industrie omdat het verbranden van dinosap niet sexy is en elektrische strijkijzers minder boeiend is als vliegtuigen. (We verliezen heel veel mensen aan aerospace en mensen vinden die hun kunnen vervangen is nagenoeg onmogelijk want niet sexy en weten niet hoe iets werkt)

[Reactie gewijzigd door Chevy454 op 22 juli 2024 20:39]

[Raymond Deen]

Er is een wijd spectrum aan mensen werkzaam in de it. Het zijn niet allemaal developers, maar onder andere ook engineers die omgevingen opzetten en beheren waarbinnen de software moet draaien en bewerkt worden.
Ik weet uit eigen ervaring als developer hoe goed en hoe slecht deze omgevingen soms ingericht zijn. Soms is het helemaal dicht gespijkerd en moet je voor toegang tot een resource expliciet toestemming vragen en soms staat het open voor de hele wereld.
Als het een bedrijf betreft van de laatste categorie dan hebben ze serieus last van verkeerde prioriteiten en laat ik dat uit professionele trots ook zeker weten.

[glennoo]

Zelfs SSL certificaten vereisen soms nog wat handwerk tegenwoordig.

[elmuerte]

X.509 ("SSL certificaat" is op behoorlijk wat niveaus een verkeerde term) zijn om verschillende idiote redenen vaak nog steeds niet eenvoudig.
ACME heeft het probleem gefixen voor de rest van de wereld, maar het oorspronkelijke stukje heeft nog steeds verschrikkelijke moeite om ACME te omarmen.

[readefries]

Alleen op publieke repo's gaat dat automatisch, anders moet je GitHub Advanced Security afnemen...

[david-v]

Dat kwam doordat de GitHub-token van een medewerker in een public repository terecht was gekomen

Ik vraag me dan toch af waar het fout is gegaan, want een token in je repository zou dan toch opgemerkt moeten worden?

[readefries]

Ik vermoed dat het ooit op organisatie of enterprise niveau uitgezet is met een policy, en is dat nooit aangepast...

[langestefan]

Dat had zichzelf terugverdient met het voorkomen van deze blunder

[bzuidgeest]

Wat bizar is, is dat er nog mensen zijn die denken dat het 100% te voorkomen is.

Bij alles waar mensen bij betrokken zijn worden fouten gemaakt. Niets wat wij maken is perfect, niets dat de natuur maakt is perfect. De systemen worden complexer, de kans op een fout hoger. Een fout in imperfecte software, en bit flip in imperfecte hardware of beide.

Shit happens.

Kans is een bel curve. De piek kan nog zo smal zijn er zijn altijd de uitersten, de uitzonderlijke uitzonderingen.

[maxboone]

Wat een dooddoener zeg, het is prima mogelijk om iets te bouwen dat 100% werkt in dit scenario. Waar maak je uit op dat dit een uitzonderlijk scenario was?

Al is het een fringe / edge case kun je het prima onacceptabel vinden dat die niet is gevangen door het systeem.

Wanneer een rempedaal van een auto er mee stopt of een deur uit een vliegtuig valt zeggen we ook niet "ach mensen zijn niet perfect."

Overigens - in het Nederlands is het as far as I'm aware geen "bel curve" maar een (normaal)verdeling, in dit geval neem jij aan dat het normaal verdeeld is maar in de realiteit zal het wel scheef zijn.

[Reactie gewijzigd door maxboone op 22 juli 2024 20:39]

[bzuidgeest]

Waaruit maak jij op dat het niet uitzonderlijk was?
Edge cases gaan er altijd zijn. De comment waarop ik reageer stelt verkapt dat het mogelijk moet zijn om het altijd 100% goed te hebben en dat is gewoon niet reëel.
En net als Mercedes of jou voorbeeld van een vliegtuig deur, doen we dan onderzoeken en verbeteren. Ik zeg nergens dat je dat niet moet doen. Maar dat helpt niet voorkomen dat er niet ergens anders weer een edge case opduikt. En dan kom je weer terug bij af.
Je verbeterd wanneer het fout gaat en je bereid je voor op dat het fout gaat.
De oorspronkelijke vraag, "waarom gebeurd dit nog steeds", is beantwoord met dat er altijd edge cases zijn. Je verbeterd en move on.

En ja bel curve of zo was een vernederlandsing/beetje Engels. Je begreep prima wat ik bedoelde.

[maxboone]

De term bell curve is als term niet correct en een onnodig anglicisme. Je doelt denk ik op een normaalverdeling, waaruit meteen duidelijk wordt dat je aanneemt dat de kans op het lekken van een API key normaal verdeeld is.

Gezien men actief hier tegen werkt zal deze eerder rechtsscheef verdeeld zijn. In andere woorden: Wat wil je er überhaupt mee zeggen, en klopt het wel? Dat ik het persoonlijk begrijp betekent niet dat anderen dat ook doen.

Een m.i. betere verwoording zou zijn: "Al doen we het zo goed en gaat het zo vaak goed, er blijft altijd een kans bestaan op een uitzondering zoals deze."

Verder, on topic - ongeacht of je het als een "edge case" benadert kun je prima stellen dat het bizar is dat dit gebeurt met de technologie van nu en dat deze specifieke fout 100% afgevangen had moeten zijn. Het artikel en gelinkte artikel stellen duidelijk dat de key opdook in een routine scan, hier was dus niets uitzonderlijks aan.

Tuurlijk kan het gebeuren, want mensen maken fouten en daar kunnen we (terecht) verontwaardigd op reageren. Het is w.m.b. een enorme dooddoener om dan kansberekening of menselijke fouten erbij te trekken - vraag je dan af wat dit geval uitzonderlijk maakt en onderbouw daarmee je punt.

[langestefan]

Daar zijn dus de code/secret scanning filters voor. Die filteren tokens er zo uit en houden de commits tegen (ik gebruik het zelf op mijn open source repositories op GitHub). Sowieso is het dom om 1 token te hebben die werkelijk overal bij kan. Je kunt er beter vanuit gaan dat het een keer mis gaat, en je daar dan zo goed mogelijk op voorbereiden.

[bzuidgeest]

Dat zijn imperfecte tools. Als je denkt dat het 100% alles voorkomt, heb je niets van mijn comment begrepen.
Ik weet van die tools af. Leuke dingen, gebruik is heel verstandig, maar zoals alles hebben ze beperkingen. En mensen met houdingen zoals jij, die denken dat de tool alles oplost, komen nog al eens in situaties waar Mercedes zich nu in bevind. De werkelijkheid is hard.

En GitHub heeft als alle tools admin accounts en die kunnen overal bij, soms zijn die dingen gewoon nodig voor bepaalde processen.

[bzuidgeest]

Tuurlijk is het "persoonlijk", het was jou opmerking waar ik op reageer . Beetje raar dat je denkt dat reacties op comments niet persoonlijk zijn.
Wat je echt bedoeld is dat je geen weerwoord had, dus gooi je het op een "aanval".
Ik verdedig mijn stelling, dat is geen aanval, dat is hoe discussie werkt.

Het was persoonlijk geweest in de trant die jij claimed als ik iets over je kapsel of moeder had gezegd. Ik spreek echter alleen over de claims die je maakt in je comment

[langestefan]

Een private key verwerk je niet. En hoezo specifieke usecsse? Het lekken van keys is juist waarom je secret scanning gebruikt.

[bzuidgeest]

Nooit iets in een config bestand gezet tussen andere dingen, nooit iets verwerkt in een encoding als base64, voor transport en opslag?
Er zijn tal van manieren om het standaard format van zo een key te veranderen dat een scanner hem niet herkent, maar een mens wel. Ligt er maar net aan hoe ze hem wilde inzetten.
Je focust je op de dingen die jij gezien hebt een normaal vind een kan je blijkbaar niets anders voorstellen. Misschien wilde iemand een bestand laten negeren door de scanner en pakte ze de verkeerde. Niet anders dan dat mensen soms iets verkeerds in gitignore zetten, waardoor er teveel bijkomt of verdwijnt.
Er zijn tal van manieren waarop scannen kan falen. Blind vertrouwen op zo een tool is een enorme fout. Het is maar gereedschap ingesteld en gemaakt door mensen.

Je vroeg hoe zo een fout nog steeds gemaakt kan worden, ik heb je dat nu een paar keer vertelt, voorbeelden gegeven. En er zijn nog duizend voorbeelden meer. Misschien had de scanner en config fout, was deze even offline, zit er een bug in de scanner, had deze geen toegang meer tot een repo etc etc.
Ongelukken gebeuren anders zag de wereld en heel anders uit. Werd er nooit een gezond mens ziek, faalde er nooit een rem op een auto. Hadden we nooit oorlog

Mercedes onderzoekt dit en zal correcties maken, dat is hoe mensen en bedrijven leren.
Volgende week vind een ander bedrijf of individu een nieuw mogelijkheid om dingen fout te doen op een manier die jij een de scanner nog niet kennen. Dat is hoe de echte wereld gaat, niets is perfect, ook jou werk niet, ook mijn werk niet. Ook de scanner niet.

[langestefan]

Nooit iets in een config bestand gezet tussen andere dingen, nooit iets verwerkt in een encoding als base64, voor transport en opslag?
Er zijn tal van manieren om het standaard format van zo een key te veranderen dat een scanner hem niet herkent, maar een mens wel. Ligt er maar net aan hoe ze hem wilde inzetten.

Het gaat om een private key. Nee die zet je niet om in base64, dat is ook niet wat er gebeurt is. Ik weet ook wel dat zo'n scanner niet alles er uit zou pikken, en ik heb ook nooit gezegd dat je ze blind moet vertrouwen, dat maak jij er van. Het gaat mij puur om het committen van private keys, dat kan met zo'n scanner niet gebeuren.

[machiel]

Tokens zouden verboden moeten worden

[Tapijtmepper]

Zou je hiermee bv. de software van je eigen wagen kunnen aanpassen?

Heb gemerkt dat veel in-car entertainmentsystemen op Linux draaien en het voelt toch fout aan dat je er dan niet echt aan kan prullen als Tweaker. Ja, los van garantie en je eigen auto wat om zeep helpen, zou het toch fijn zijn.
Ik heb bv. altijd al wat dingen willen veranderen aan mijn Skoda Fabia (menustructuur, mp3-speler,...).

[TNG128MB]

op marktplaats.nl vind je al kerels die de mbux unlocken voor €40

[FPSUsername]

Het werkt allemaal op QNX, net even iets anders dan je gebruikelijke Linux machine. Ondertussen gebeurt er zeer veel in de VAG wereld van infotainment systemen (met patches zodat je alle functionaliteit kan vrijspelen en de laatste kaarten erop kunt installeren, maar ook toolboxes waarmee je in het systeem kunt poken). Ik heb dit echter nog niet gezien bij andere grote fabrikanten (zoals Toyota).

Veel van het spul voor VAG infotainment systemen (van Harman, Delphi, Panasonic, etc) is gewoon publiekelijk beschikbaar. Lees dus goed en ga geen dingen aanschaffen van 3e partijen die deze gratis hacks doorverkopen (zoals thenavman).

[Reactie gewijzigd door FPSUsername op 22 juli 2024 20:39]

[Lejavh]

Volgens mij is “prullen aan je autocomputer” niet helemaal de bedoeling aangezien veiligheid in een auto altijd het belangrijkste moet zijn. Denk dat dat de reden is dat fabrikanten dat niet toestaan.

[unreal0]

Dat heeft niet per se wat met je infotainment te maken

[svenM]

Als ze het goed doen staat de infotainment natuurlijk los van de belangrijke systemen

[bzuidgeest]

Infotainment en cruciale systemen zijn gescheiden. En bug in de muziekspeler mag niet de remmen crashen.

[dasiro]

met een titel als "co-founder and chief technology officer of RedHunt Labs" zou je denken dat hij het mooi bij de onderzochte partij meldt, maar daar is geen spoor van te vinden in het artikel, dus loopt hij ermee naar de pers die dan zelf inziet dat er bij het slachtoffer een melding van moet gemaakt worden. Ik heb een heel dubbel gevoel bij zulke aandachtszoekers. Het zou anders zijn als hij het gemeld had en geen gehoor had gekregen, maar dan zou dat zeker vermeld zijn geweest in het bronartikel.

[laurxp]

Van het bron-artikel:

Shubham Mittal, co-founder and chief technology officer of RedHunt Labs, alerted TechCrunch to the exposure and asked for help in disclosing to the car maker.

Dus ja, flinke kans dat hij inderdaad geen gehoor kreeg bij Mercedes-Benz.

[HollowGamer]

Weet iemand wat voor technologie ze gebruiken? Best interessant om te weten.

Voor mij zou iedere site wel opensource mogen zijn, of een gedeelte ervan zoals auth. Ja, het kan worden gebruikt voor minder leuke dingen, maar tot nu toe zie ik toch echt veel CVEs worden gestuurd t.o.v. closed source.

[Dj-sannieboy]

Belangrijke documenten en broncode in een repository begrijp ik, maar wachtwoorden? Voor wachtwoorden zou ik een vault of hsm verwachten.

Verder zou het gebruiken van een tool als credscan dit soort zaken kunnen voorkomen.

[Reactie gewijzigd door Dj-sannieboy op 22 juli 2024 20:39]

[Sandeman1967]

Het zou ook nog kunnen dat de 'fout' bij github ligt. Ze hebben volgens mij een tijdje terug een migratie doorgevoerd. Ik kreeg ook meldingen van github over een niet veilige repository bij 1 of 2 van mijn oude repositories...

[Roel1966]

Ik weet niet maar zoiets had ik mij nog bij een goedkoop automerk enigszins kunnen voorstellen maar niet bij een merk als Mercedes. En tja door dan 1 menselijke fout dat er dan meteen toegang zou kunnen bieden tot een complete Gifthub server met belangrijke documenten.

Hopelijk dat de software in hun auto's beter beveiligd is en je niet opeens per ongeluk de complete auto op zijn kop zet.

[NotWise]

De prijs en merkbeleving van een automerk heeft helemaal niets van doen met dit verhaal. Dit is een menselijke fout en mensen maken nu eenmaal fouten.
Wat zijn volgens jouw goedkope automerken?

[Roel1966]

De prijs en merkbeleving van een automerk heeft helemaal niets van doen met dit verhaal.

Nou, ik weet niet maar je zou toch zeggen dat Mercedes genoeg geld heeft voor een goede beveiliging.

Dit is een menselijke fout en mensen maken nu eenmaal fouten.

Zeker, maar dat dan meteen een complete Gifthub server 'open' staat door 1 menselijke fout ?

Wat zijn volgens jouw goedkope automerken?

Ik zit dan meer te denken aan merken als b.v. Dacia die relatief goedkoop zijn.

[NotWise]

Zeker, maar dat dan meteen een complete Gifthub server 'open' staat door 1 menselijke fout ?

Er sterven dagelijks mensen door fouten van anderen. Er gebeuren zelfs rampen. Google eens menselijke fout en ramp. Je krijgt een hele waslijst. De Tsjernobyl ramp was ook een menselijke fout.
Je bent verdorie (als het klopt) van 1966, je zou nu zo langzamerhand een beetje moeten snappen hoe dingen werken. Ik vind het werkelijk naïef.

Er bestaat geen 100% garantie dat alles altijd goed loopt, al gooi er miljoenen tegenaan. Zie de maanlander van de Japanners, deze heeft 100 miljoen gekost en is ontworpen door top techneuten. Ding staat nu niets te doen op de maan omdat de zonnepanelen niet werken.

Dacia is overigens een submerk van Renault.

[Roel1966]

Je bent verdorie (als het klopt) van 1966, je zou nu zo langzamerhand een beetje moeten snappen hoe dingen werken. Ik vind het werkelijk naïef.

Klopt, ik ben van 1966 maar je zou juist zeggen dat men geleerd heeft van fouten. Daarnaast kan je techniek van toen niet meer met nu vergelijken ( of misschien wel ). Waar ik op doel is niet zozeer die menselijke fout maar wel dat dan zo'n complete server open staat.

[david-v]

De grote van de organisatie staat niet in relatie tot de kwaliteit van hun systemen en software. Alleen pure software huizen hebben dat redelijk goed voor elkaar, en die maken om wel eens fouten.

Juist bij kleine bedrijven kan je heel snel iets heel goed neer zetten als je de juiste kennis/mensen hebt. Bij grote bedrijven gaat dat heel langzaam is mijn ervaring, waardoor je altijd achterloopt op de feiten.

[pretraket]

Oef, een stagiair zal wel een slechte dag hebben gehad bij Mercedes

[david-v]

Nou, ik praat het niet goed maar aangezien dit allemaal mensenwerk is. Het kan iedereen wel overkomen. Daarom moet je dit soort zaken proberen te voorkomen. Onder andere door automatisch laten checken of je een wachtwoord of token bij je code bewaard in je repository

[SPee]

Misschien dat het bij een junior developer kan gebeuren. Maar die zou dan niet zoveel toegang met zijn token moeten hebben.
Voor een ervaren developer verwacht ik dat hij hier wel goed mee weet om te gaan. En een beetje descipline heeft om erop te letten. (En het dus zelf ontdekt zou hebben)
Helaas kom ik veel te vaak developrs tegen die die basale dingen niet goed doen. Ervaren, maar toch vaak "oh ja, vergeten", "hoe moet dat?", etc. Zucht

[david-v]

Dat is ook wat ik bedoel met mensen werk. Soms is het nalatigheid, onvoorzichtig of clueless (hoezo mag dat niet in de repository.? ), maar soms zijn het ook zeer ervaren mensen die wel eens een fout maken (en dat moet je nou eenmaal accepteren, want we zijn allemaal mensen). Het enige wat echt helpt is procedures en de bijbehorende technische oplossingen. Wachtwoorden en tokens in vaults, controle bij elke push of er wachtwoorden of tokens meegaan met de code enz.

En dan nog heb je kans dat het een keertje misgaat. Dit bij Mercedes lijkt iets erger dan een foutje omdat in de private repositories ook secrets stonden. Die horen daar niet te staan. Dus dat is al een misser, maar het openbaren van je sourcecode wat al erg genoeg is

[SuperDre]

Het lek werd deze maand ontdekt door beveiligingsonderzoeker Shubham Mittal, die nieuwssite op de hoogte bracht

Wat een eikel om dit eerst en alleen te melden aan de media ipv eerst netjes melden bij de persoon die de fout heeft gemaakt, of dus bij Mercedes. Die gast verdient dan weinig respect wat mij betreft.

[laurxp]

Van het bron-artikel:

Shubham Mittal, co-founder and chief technology officer of RedHunt Labs, alerted TechCrunch to the exposure and asked for help in disclosing to the car maker.