Hacker achterhaalt plaintext-wachtwoorden uit tweedehandscomputers van Tesla's

Tesla-bezitters lopen het risico dat gegevens over hun auto- en entertainmentgebruik in verkeerde handen vallen. Informatie uit de Media Control Unit, waaronder wachtwoorden, worden in plaintext opgeslagen. Die MCU's zijn inmiddels voor weinig geld op internet te koop.

Dat zegt hacker Green The Only. Hij kocht verschillende oude infotainment-units van Tesla-computers op en wist daar informatie uit te achterhalen. Bij een upgrade van een auto worden zulke units vaak verwisseld, waardoor er inmiddels steeds meer voor steeds minder geld op tweedehandsmarktplaatsen zoals eBay worden aangeboden. De hacker ontdekte niet alleen informatie over de gebruiker, maar ook wachtwoorden en toegangstokens voor externe apps.

Green The Only vond onder andere de locaties die gebruikers in hun auto's hadden opgeslagen, en wifiwachtwoorden. Ook kon hij informatie achterhalen van gekoppelde telefoons, zoals agenda-afspraken, en bel- en contactlijsten. Opvallend is dat voor sommige apps zoals Netflix een sessiecookie wordt opgeslagen en voor Spotify zelfs het wachtwoord voor het account. De informatie wordt in plaintext, dus zonder versleuteling, opgeslagen.

Tesla vervangt de computers in verschillende gevallen, bijvoorbeeld als een auto een servicebeurt krijgt en de Media Control Unit v1 wordt vervangen door de tweede generatie v2. Dat gebeurt met name in de Verenigde Staten, waar de v2-versie al beschikbaar is, maar het is niet duidelijk of ook Nederlandse klanten hiermee te maken hebben. Normaal gesproken vervangt Tesla de v1 door een nieuw of een refurbished model als hij stuk is. Ook van klanten die de Full Self Driving-upgrade op de Model 3 of Model Y nemen, is de FSD-hardware in één apparaat geïntegreerd met de MCU. De bestaande MCU wordt dus uit die auto's verwijderd.

Green The Only wist de hand te leggen op vier computers uit de Model 3, S en uit de Model X. Die waren weliswaar stuk, maar hij kon de data toch uitlezen. De hacker gaf zijn bevindingen door aan Tesla. Het bedrijf zei dat het klanten niet op de hoogte zou stellen van het mogelijke datalek. Op Reddit zegt Green The Only dat hij van het bedrijf geen tijdlijn kreeg voor wanneer het met een oplossing zou komen of wat het van plan was te doen. Hij stapte vervolgens met de informatie naar InsideEVs.com. Dat heeft vooralsnog geen reactie gekregen van Tesla.

Het is niet duidelijk of er ook in Nederland MCU's te koop zijn waar data op staat.

Reacties (143)

[Immutable]

Dit is wel leuk te lezen hoe het er aan toe ging in het begin van de ontwikkeling bij Tesla software:
(Verhaal door een Ex Tesla Software engineer:)
https://www.reddit.com/r/...anecdotes_about_problems/

Het verbaast me dus niks. Het zijn gewoon ARM / Intel PC's met Ubuntu distro erop, met allerlei software stacks. Visueel wordt er QT gebruikt, met daaronder een heleboel stacks.

Belangrijkste doelstelling was software leveren, veiligheid & security deden er toen helemaal niet zo toe.

[Reactie gewijzigd door Immutable op 22 juli 2024 22:37]

[Eonfge]

Voor de mensen die thuis op de bank zitten met een Tesla en nu denken, wacht eens, die code zou ik wettelijk mogen inzien...

Hier aanmelden voor de rechtzaak tegen Tesla:
https://sfconservancy.org...calling-all-tesla-owners/

[Immutable]

Klopt Tesla deed ook heel moeilijk betreft de licenties van de gebruikte software stacks. In de opensource community staan ze niet goed te boek. Ik snap wel waarom ze dat doen....
Geen tijd, en resources worden puur gealloceerd op groei. De rest heeft geen prioriteit.
Ze geven geen dividend dus aandeelhouders willen pure groei zien, zoveel mogelijk marktaandeel pakken.

[Reactie gewijzigd door Immutable op 22 juli 2024 22:37]

[Eonfge]

Ik doneer graag een tientje per maand aan de SF: Conservancy om multinationals tot GPL-compliance te dwingen. Dubbel zo als ze zichzelf super geweldig vinden op Twitter, maar ondertussen voortbouwen op gejat werk en beurs manipulatie plegen.

Edit. Onvoltooid tegenwoordige tijd.

[Reactie gewijzigd door Eonfge op 22 juli 2024 22:37]

[MadMarky]

Dit topic is ook een leuk voorbeeld daarvan: Tesla Model S/X raken 'bricked' door worn-out SSD

In de aangepaste Ubuntu distro is niet alle logging uitgeschakeld, waardoor er nog steeds logfiles naar flashgeheugen geschreven worden. Na een X aantal jaar raakt het geheugen hierdoor versleten en doet je MCU het niet (goed) meer.

[Verwijderd]

Dit is later gefixed en de problemen waren niet heel erg. De auto reed er gewoon nog om.

Zolang er mensen werken zullen we altijd dit soort zaken houden.

[Cybje]

In theorie kun je nog rijden inderdaad, maar in de praktijk was het zaak om zo snel mogelijk een Service Center te bereiken. Ik heb het zelf gehad na 4 jaar op m'n Model S en de problemen waren toen o.a.:

• Verwarming was niet meer te bedienen (dit bedien je via de MCU), in mijn geval bleef die continu aan staan en trok dus de accu leeg (ook als de auto op slot was)
• Opladen van de auto lukte niet meer
• Scherm met o.a. snelheidsmeter ging over naar de standaard configuratie (en gaf dus o.a. snelheid in mijlen aan)
• De app op de telefoon kreeg geen verbinding meer, dus bediening van de auto via de app kon ook niet

Het was toen rond het vriespunt, dus de verwarming 24/7 aan trok best veel elektriciteit. Zelfs zonder ermee te rijden was de accu dus in een paar dagen leeg geweest en opladen ging niet meer.

[Tozz]

Het verhaal is wel met een vrij negatieve stemming geschreven. Het begint al met 'runs in a single bottom tier datacenter'. Hiermee lijkt bedoelt te worden dat het niet in de cloud draait. Daar zijn best hele legitieme redenen voor te bedenken, en lijkt me niet echt een probleem. voor zover ik weet is het enige dat niet functioneert zodra de Tesla API stopt met werken de remote functies van de app. Dat lijkt me niet een wereldschokkend probleem. Verderop geeft ie zelfs aan dat er een technische redenen is waarom het niet in de cloud kan draaien.

Het voorbeeld van 'we hebben OpenSSL gepatched om SSL expiry dates te negeren' klinkt misschien niet zo best, maar als het een snelle fix is om een acuut probleem op te lossen lijkt mij daar wenig miss mee. Zolang je het onderliggende euvel maar herstelt daarna. Ook wat dat betreft is het wel een heel negatief opgeschreven verhaal. Hij had ook kunnen schrijven 'het oplossen zou dagen duren dus we kwamen met deze snelle tijdelijke en goed werkende hack'.

Er zal vast genoeg mis zijn met het development van Tesla's firmware, maar dat zal overal gelden. Zeker verbeteringen van processen (code herschrijven) staan zelden op nummer 1 op de prio lijst om de simpele reden dat het geld kost en niet concreet iets oplevert.

Naar mijn idee is dit verhaal iets teveel vanuit een boze ex-werknemer geschreven.

[Immutable]

Het nuance moet er wel degelijk zijn dat dit meer de regel is dan uitzondering bij veel startups. Het gaat om het zo snel mogelijk kunnen leveren, want anders faalt de startup. En je moet bepaalde investering rondes halen. Ik ga er vanuit dat door verschillende leerfases en schandalen ze wel de desbetreffende punten gauw oppakken. Je ziet ook wel dat Tesla uitzonderlijk snel kan leveren, alleen weten we allemaal wel door alle nieuws rondom Tesla dat de auto's bovennatuurlijk veel gebreken hebben. En dat is wel een gevolg van het "startup" en alleen focussen op groei.

Je kunt ook de klanten verwijten dat ze weten dat het een product is van een bovenproportionele grote startup destijds kwam. Ik geloof ook zeker wel dat wat daar geschreven is, nu velen malen beter is. De model 3 heeft grote stappen gemaakt. En de model Y ook.

Het gaat er dan ook om over de oude Model S auto's welke langzamerhand allerlei rare gebreken gaat vertonen welke normaal gesproken niet voorkomen. Dit komt voornamelijk omdat deze auto's uit de vroege "startup" tijdperk komen waar dit verhaal speelde. Geheugen chips welke hun schrijfleeftijd vervroegt bereiken waar geen goede oplossing voor is dan dat deze klant flink mag betalen e.d.
De huidige Model S is hetzelfde model, maar van binnen een HEEL andere auto dan de Model S uit hun startup periode. Je mag echt niet hetzelfde verwachten qua kwaaltjes.

[Tozz]

Je onderschrijft eigenlijk wat ik probeer aan te geven.. Dat tesla hierin niet uniek is en dat Tesla zeker in de periode 2012-2015 het heel zwaar had (financieel gezien) en dat er dus simpelweg geen geld was om verbeteringen door te voeren.

[Creesch]

'runs in a single bottom tier datacenter'. Hiermee lijkt bedoelt te worden dat het niet in de cloud draait.

Bottom tier is simpelweg een ander woord voor "zo goed koop mogelijk". Het hoeft ook niet "in de cloud" te draaien maar redundancy in je infrastructuur in de vorm van spreiding over twee datacenters is toch iets wat je als bedrijf toch wel zou moeten willen.

Het voorbeeld van 'we hebben OpenSSL gepatched om SSL expiry dates te negeren' klinkt misschien niet zo best, maar als het een snelle fix is om een acuut probleem op te lossen lijkt mij daar wenig miss mee. Zolang je het onderliggende euvel maar herstelt daarna. Ook wat dat betreft is het wel een heel negatief opgeschreven verhaal.

Dat is simpelweg beknibbelen op veiligheid, er is geen garantie dat het later wel netjes opgelost zal worden. Sterker nog, mijn ervaring met teams en bedrijven waar dit soort "tijdelijke" oplossingen worden ingezet is dat het vaak gebeurt vanuit haast en er later ook nog steeds geen tijd is om het op te lossen. In het meest positieve geval staat het dan nog ergens onderaan een backlog van een scrum team om ooit eens een keer op te pakken maar wordt het steeds weer naar onderen verplaatst ten gunste van features die mooi scoren op de sprint demo.

Hij had ook kunnen schrijven 'het oplossen zou dagen duren dus we kwamen met deze snelle tijdelijke en goed werkende hack'.

Dat is inderdaad hoe je het zou omschrijven als je het naar hoger management moet verkopen, je het in je CV wil verwerken, etc.

[Reactie gewijzigd door Creesch op 22 juli 2024 22:37]

[Verwijderd]

"Niets is zo permanent als een tijdelijke fix."

[Verwijderd]

Yep, en dit verhaal is ook al redelijk oud (2018). Sommige zaken zullen waar zijn, sommige punten overdreven en sommige zaken zullen achterhaald of verkeerd zijn.

Zeker verbeteringen van processen (code herschrijven) staan zelden op nummer 1 op de prio lijst om de simpele reden dat het geld kost en niet concreet iets oplevert.

Volgens de AI / Autopilot man van Tesla zijn ze nu 'Code 2' aan het schrijven. Die vervangt stukken 'Code 1' o.a. met neural nets. Autopilot draait nu nog in HW2 emulatie modus en ze zijn dus langzaam de code aan het herschrijven en vervangen voor HW3

[wiseger]

Single bottom tier datacenter betekend niet of het wel of niet in de cloud draait, het betekend dat het in een enkel datacenter draait zonder replicatie. Mocht dat datacenter in de problemen komen door bijvoorbeeld brand, dan neemt een ander data center het niet direct over. Je krijgt dan uitval en je bent afhankelijk van het restoren van backups en de beschikbaarheid van een ander datacenter om daar de backups te restoren danwel reperatie van het bestaande data center alvorens daar de backups te restoren. Er zijn geen technische redenen waarom er geen gebruik van een Tier II of Tier III datacenter gemaakt kan worden, het zijn financiele overwegingen.

[naaitsab]

Marktaandeel lijkt het enige belangrijkste te zijn. Kwaliteit/veiligheid en hoe men medewerkers behandeld (ook genoeg over te vinden) lijkt men niet zo belangrijk te vinden.

Plain tekst wachtwoorden zijn in geen enkel bedrijf tegenwoordig goed te praten. Helemaal niet als er allerhande koppelingen in opgenomen zijn.

[Reactie gewijzigd door naaitsab op 22 juli 2024 22:37]

[rob12424]

Vergis je niet. Veel embedded systemen zijn niet met veiligheid in het achterhoofd op gezet. Er zijn. Verschillende mensen I. De Linux community die hier al jaren voor waarschuwen! Ook Android heeft er hierin in het verleden van langs gekregen.

[borbit]

Linux is toch juist met veiligheid in het achterhoofd op gezet? En embedded systemen werken meestal op Linux lijkt mij?

[Sfynx]

Je moet wel iets meer beveiligen dan alleen de kernel (wat Linux is). En ook die kernel heeft regelmatig vervelende lekken gehad.

[Reactie gewijzigd door Sfynx op 22 juli 2024 22:37]

[rob12424]

Ja maar al die beveiliging neemt ruimte in. En kost batterij duur. X en xserver bijvoorbeeld zijn heel oud alle schillen daaromheen ook kwa communicatie worden er daarom vaak uitgesloopt.

Dit is niet altijd beter.

[cracking cloud]

Belangrijkste doelstelling was software leveren, veiligheid & security deden er toen helemaal niet zo toe.

Zoveelste voorbeeld. Wordt tijd dat dit strafbaar wordt gesteld.

[Verwijderd]

Maar het is niet het zoveelste voorbeeld, het is de zoveelste interpretative door iemand op het internet op basis van anonieme bronnen en random blogs op het internet, al met al niet echt een goede sample.

En geen enkele start-up heeft veiligheid als prioriteit. Strafbaar stellen is ook zoiets wat makkelijk te roepen is, maar wanneer is iets prioriteit? Wie gaat alle bedrijven langs of dit zo is? Hoe ga je bewijzen dat het met opzet is gedaan?

[cracking cloud]

Plaintext wachtwoorden opslaan is nalatigheid.

[Verwijderd]

Sterker nog; je gaat bewust het grondwerk dat anderen al hebben gedaan om een minimale beveiliging te hebben links laten liggen. Het is niet zo dat je een hoop moeite moet doen om wachtwoorden niet plain text op te slaan. Legio frameworks voorzien al een standaard hashing voor wachtwoorden.

Sowieso moet veiligheid een gedeelde prio 1 hebben. Immers zijn het niet jouw gegevens waar je mee aan het rommelen bent, en je speelt met het vertrouwen van je klanten. Daarnaast kun je er vanuit gaan dat vroeg of laat je negatief in het nieuws komt omdat er gevoelige data op straat ligt. (waarvan akte).

[d3burt]

Ik ken niet heel veel oplossingen om API's te beveiligen. Hashen heeft alleen zin als je een wachtwoord moet controleren, maar de Tesla moet namens de gebruiker kunnen inloggen en moet dus de credentials hebben. Die kun je encrypten, maar dan moet je ook een mechanisme hebben om het te decrypten zonder dat de bestuurder de hele tijd passwords moet ingeven.

Het kan altijd beter dan plain text passwords opslaan, maar de meeste home grown oplossingen voor dit probleem bieden schijnveiligheid. Het is niet triviaal om dit echt te fixen.

Een goed voorbeeld van een gebruikersonvriendelijke oplossing is Ansible Vault. Ongetwijfeld veilig, maar extreem gebruikersonvriendelijk.

[nobraininvolved]

Dat hoeft niet hoor...
't ligt eraan hoe alles eromheen beveiligd is.
Als ik een plain text wachtwoord in een enorme betonnen bunker leg, met een aantal poppetjes met geweren eromheen, kan ik best zeggen dat 't goed beveiligd is. Ook al is 't ww nog steeds in plaintext.
Veiligheid kun je op meerdere manieren inbrengen.
Ik vraag me dan ook een beetje af hoe makkelijk 't zou zijn om in een bestaande tesla die nog rijdt, die MCU af te tappen voor een niet-professioneel iemand?
eerst moet ie de auto in zien te komen (beveiliging 1), dan moet ie de MCU eruit zien te slopen (zit hopelijk wel goed vast c.q. ver in de auto ingebouwd? (beveiliging 2), dan heeft ie mss speciale apparatuur nodig om er iets mee te kunnen (beveiliging 3), enz enz...
Ik zeg niet dat 't zo is hoor...mss zit er aan de buitenkant van de auto wel een usb poort waar je de info zo uit kunt halen, dan is 't wel onveilig, maar veiligheid hoeft niet altijd in de software ingebouwd te zitten.

[Verwijderd]

Dat is onzin. Een serieuze startup heeft ook beveiliging als prio, want je kunt je, als startup, het risico op negatieve publiciteit (en aansprakelijkheid) niet veroorloven, en je moet nog je best doen om het vertrouwen van je prospecten te winnen.

Daarnaast is het algemeen bekend dat systemen waar gevoelige data in opgeslagen worden voldoende beveiligd dienen te zijn, dus als je ervoor kiest dat niet te doen, dan ben je bewust nalatig, en dat mag best strafbaar zijn (als het dat al niet is).

Ik ben bekend met de code van een aantal startups, en zie dus dat er vaak wel een serieuze poging tot beveiliging is gedaan, tuurlijk zijn er af en toe denkfouten die een deuk in de beveiliging geven, maar in ieder geval straalt het niet de insteek 'beveiliging? Dat doen we later wel een keer.' uit.

[Verwijderd]

Maar denkfouten worden vrij snel door mensen neergezet als 'Oh het was geen prioriteit'. Net als bij Tesla, dit alles is gebaseerd op anonieme bronnen en keyboard warriors, maar 0 bewijs. Ook als start up is een denkfout dus al makkelijk af te straffen door iedere halve zool met internet en een toetsenbord.

[Verwijderd]

Ah, van een anonieme bron op het internet, dan zal het wel zeker de waarheid zijn...

[Verwijderd]

Bijzonder, hé? En aan de reacties te zien twijfelt er niet 1.. Je bent de eerste die ik tegenkom

[Verwijderd]

Was QT niet in begin dat blackberry dat ging ontwikkelen?

[Reinstein]

Qt is van Nokia geweest

[xzaz]

Ik denk niet dat het bij andere leveranciers anders is.

[kimborntobewild]

Verhaal door een Ex Tesla Software engineer:
https://www.reddit.com/r/...anecdotes_about_problems/

Zelden heb ik zulk slecht Engels gezien.

[Ntr-]

Dit is het hele probleem ook met agile werken,
hoe het tegenwoordig in meeste bedrijven gaat is sbel een product lanceren en als eerste te zijn. Vaak wordt er veel voor functionele onderdelen besteed en wordt de non functionele (oa security) zaken vergeten of lager op de lijst gezet.

[Bensimpel]

Plaintext wachtwoorden... Sorry maar dit kan toch echt niet meer...
Er heeft iemand echt mega hard lopen slapen bij de implementatie hiervan.. Verbaast mij niks dat ze bij Tesla security by design niet echt kennen...

[kodak]

Tot voor kort was versleuteling en goed wipen zelfs niet gewoon bij smartphones en pc's. Dan is het helaas niet vreemd dat het bij andere apparatuur zoals entertainmentsystemen, smart tv's, personal health products enz ook niet te verwachten is. Het probleem zit er in dat eigenlijk niemand zich er echt druk om heeft gemaakt. Fabrikanten, eigenaren, gebruikers, dienstveleners hadden allemaal eisen kunnen stellen en afspraken kunnen maken.

[kimborntobewild]

Fabrikanten, eigenaren, gebruikers, dienstveleners hadden allemaal eisen kunnen stellen...

Zelfregulatie zal nooit optimaal goed werken. Het zijn dus overheden die hier vooraf regels hadden moeten opstellen, en die achteraf bij constatering van overtredingen moeten straffen.

[Armin]

Tot voor kort als in voor 2010?

Immers versleuteling is bij zowel Apple als het defunct Windows Phone toch al een paar jaar standaard. Bij Android is het zoals zo vaak OEM afhankelijk, maar ook gangbaar bij veel merken. En zelfs het oude Symbian^3 had versleuteling anno 2010.

Dus nee, dit is gewoon een dikke faal, al ligt de schuld niet alleen bij Tesla, want applicaties zelf horen ook te versleutelen. Maar een flash encryptie is toch wel iets dat al enige tijd bestaat, en elke ARM64 of AMD64 chip hardware support voor heeft.

[Bein Stuyle]

Ja, zou inderdaad niet mogen, hun model S dateert van 2012, toen was hashing ook al een ding

[kodak]

Hashen op die Tesla computer zou pas werken als de hash ook voor de accounts van externe diensten, zoals spotify, het nodig is ook gebruikt kan worden. Het heeft weinig zin om een hash te genereren die je vervolgens niet kan gebruiken om bij je externe account te komen. De vraag is dus meer of encryptie in 2012 een ding was bij verwerken van gevoelige gegevens. Het antwoord is waarschijnlijk nee, net als bij veel andere computers.

[Creesch]

Mja dat is natuurlijk niet helemaal waar, je zou ook prima de partitie met wachtwoorden e.d. kunnen versleutelen zoals dat ook gebeurt tegenwoordig met bedrijfslaptops (bitlocker o.a.) en telefoons.

[Tozz]

Dat werkt niet. Een laptop of een Bitlocker partitie wordt geunlocked doordat de gebruiker een sleutel invoert (een wachtwoord, een USB key, etc). Dat gaat niet in de auto.

Wil je dit oplossen dan zou je moeten afdwingen dat de gebruiker elke keer dat hij de auto instapt een wachtwoord invoert, die dan gebruikt wordt als decryptiekey voor de accountdata. Maar niemand wil elke keer dat hij in de auto stapt een wachtwoord invoeren.

Genoeg mensen hebben om diezelfde reden ook geen wachtwoord op hun telefoon zitten.

Enige alternatief zou kunnen zijn dat iets dat de bestuurder heeft wordt gebruikt als key. Bijvoorbeeld een encryptiekey die in de sleutel zit. Dan zou de sleutel een soort HSM zijn. Is alleen niet echt werkbaar omdat die sleutel op batterijen draait en dan te snel leeg zou zijn. Ook voorzien de huidige sleutels niet in die functionaliteit.

[Creesch]

Enige alternatief zou kunnen zijn dat iets dat de bestuurder heeft wordt gebruikt als key. Bijvoorbeeld een encryptiekey die in de sleutel zit. Dan zou de sleutel een soort HSM zijn. Is alleen niet echt werkbaar omdat die sleutel op batterijen draait en dan te snel leeg zou zijn. Ook voorzien de huidige sleutels niet in die functionaliteit.

Dat lijkt mij eigenlijk een prima alternatief wat ze hadden kunnen toepassen. Je batterijen argument volg ik niet helemaal, ik zie niet in hoe dit anders is dan de vele vormen van digitale autosleutels die er al bestaan en waarom een key toevoegen in dit geval plotseling een probleem zou zijn.

[Tozz]

Het batterij argument is als volgt:

Als de sleutel een HSM is, dan bezit de sleutel als enige de private key. De sleutel moet dan voor elke inlogactie bij een externe dienst geraadpleegd worden om encryptie/decryptie te doen. De sleutel moet dus continue luisteren (radio up houden) om te horen of hij iets moet doen. Dat vreet batterij.

Dat is anders dan huidige autosleutels die alleen reactief werken. Ze zenden misschien eens per zoveel tijd een miniem signaal uit voor keyless entry, maar ze luisteren niet continue of ze zelf iets moeten doen. Dat moet dus anders wanneer ze als HSM worden ingezet.

Wanneer de sleutel alleen als een soort ontgrendeling wordt gebruikt dan staat de private key (maar dan beveiligd met een soort pincode) nog steeds op de MCU. Het is dan aan de MCU om te zorgen dat die pincode niet wordt opgeslagen. Dat is niet zo moeilijk, maar het zet de deur open voor eventuele hacks waarbij die pincode van de sleutel door getamperde firmware alsnog wordt opgeslagen. Dat is geen probleem voor het probleem waar dit artikel over gaat, maar als je dan toch dit gaat oplossen, doe het dan goed.

[ToolBee]

De sleutel van een Tesla kan gewoon leeg raken zonder dat je buiten gesloten wordt.
De key heeft ook iets NFC. Als je de "lege" sleutel tegen de B-stijl aanhoudt ontgrendelt de auto ook.

[Creesch]

Ik betwijfel of dat klopt als ik eerlijk ben aangezien er zaken bestaan zoals fido2 waarmee de key zelf geen connectiviteit hoeft te bezitten.

Zelfs als dat niet geschikt is

Ze zenden misschien eens per zoveel tijd een miniem signaal uit voor keyless entry, maar ze luisteren niet continue of ze zelf iets moeten doen.

Lijkt me dit ene uitstekend moment om de sleutel even "actief" te houden met een timeout en de rest van de tijd inactief.

[mjtdevries]

Precies. Geen enkel probleem. Die digitale autosleutel heeft al een code die gecontroleerd word om te kijken of de auto unlocked mag worden. Dat kan ook meteen je pin zijn voor de "bitlocker" partitie.

Het is helemaal niet zo moeilijk als je wat moeite doet om opties te vinden.

Maar in de tijd dat die Tesla ontworpen werd was er veel minder oog voor security. En zeker in de auto industrie. Dus er heeft simpelweg niemand moeite gedaan om te kijken of het veiliger kan.

En ik ga er vanuit dat je dit probleem bij de meeste autos zult vinden, want die dingen zijn niet eens connected. Dus waarom zou je je over security zorgen maken?

[ToolBee]

Tesla's hebben ook gewoon keyless-entry, dus een transponder "key" die je als eigenaar herkent. Dan kan bv bitlocker toch ook open gaan?

[Verwijderd]

En dan even wachten tot je auto opgestart is?
En hoe zit het met aanvallen hierop? Zijn die simpel en efficiënt af te slaan of hebben we straks Tesla's die blokkeren omdat er iemand met een raspberry pi aan het rondrijden is?

Het is vaak allemaal niet zo eenvoudig als dat men denkt...

[Armin]

Dit is al lang opgelost mensen.

Bitlocker unlocked bij boot, en ook Apple producten booten van een encrypted disk zonder menselijke tussenkomst. Deze systemen detecteren zelf of de integriteit van het systeem in orde is met hardware support waarin de sleutels opgeslagen zijn. Via zaken als secure boot en Apple's equivalent is de pincode/password pas nodig zodra je inlogt. Bij Apple is het zelfs zo dat er meer dan een key is, waardoor bepaalde gegevens pas beschikbaar zijn na inloggen, maar OS functies ook reeds voor 't inloggen. Bij Windows heb je ook zulke systemen voor bepaalde data.

Welnu, je autosleutel fungeert zo. Je Tesla kan dus moeiteloos opstarten/booten/werken (ook remote), zonder tussenkomst van de sleutel. En er is ook geen continue verbinding nodig die batterij zuipt. Maar persoonlijke data is pas toegankelijk na inloggen. En dat eenmalig 'in te loggen' doe je door in te stappen, of de auto van het slot te halen, etc. Ofwel de gebruiker merkt er niets van want het gebruikspatroon is indentiek aan vandaag.

Rukt iemand de printplaat eruit, zal die niet werken in een andere auto, tenzij je alles wist. En ook hier kan dit apart voor user- en systeem data, waardoor de printplaat nog steeds bruikbaar is in een 2e hands omdat de system data gewoon werkt, maar de data naar default/fabrieks toestand reset is.

[Reactie gewijzigd door Armin op 22 juli 2024 22:37]

[Verwijderd]

Een laptop of een Bitlocker partitie wordt geunlocked doordat de gebruiker een sleutel invoert (een wachtwoord, een USB key, etc). Dat gaat niet in de auto.

Een sleutel invoeren in een auto niet werken? Dat doe ik elke dag.
Waarom zou je 'de sleutel' van de auto niet gebruiken als encryptiesleutel? (Zij het in fysieke vorm of in app vorm).

[kodak]

Encryptie is versleutelen. En of je dat toepast op allen de gevoelige gegevens of een hele partitie waar die gegevens op staan is een keuze. Daarom stel ik ook dat de vraag is of encryptie een ding was en niet een specifieke vorm van encryptie omdat er diverse mogelijkheden zijn om het toe te passen.

[D.oomah]

Niet 2012 maar een jaartje later:
https://www.youtube.com/watch?v=8ZtInClXe1Q

[kodak]

Encryptie is al eeuwen een ding. Alleen niet voor iedereen. Dat we online een filmje kunnen aanwijzen waarin iemand zegt dat het verstandig is maakt het verschil helaas niet. Het verschil zit hem er in of fabrikanten, verkopers, kopers etc het een ding vonden. En ik denk niet dat 2013 of zelfs nu daar een goed voorbeeld in is. Hoeveel kopers van producten als on board computers, multimedia apparatuur en andere iot devices verwachten vandaag werkelijk encryptie of voldoende controle over hun persoonsgegevens?

[mjtdevries]

Hoeveel kopers van producten als on board computers, multimedia apparatuur en andere iot devices verwachten vandaag werkelijk encryptie of voldoende controle over hun persoonsgegevens?

Heel veel denk ik.
Dat mensen er niet over nadenken en geen navraag over doen, betekent niet dat ze het prima vinden dat hun password plain-text opgeslagen worden.
Ze gaan er simpelweg vanuit dat het wel netjes gedaan zal worden door de fabrikant.

[EraYaN]

Ik hoop toch dat het op basis van OAuth tokens of iets dergelijks gaat want die basis wachtwoorden zou je helemaal niet moeten opslaan. En dan heeft ook linux de mogelijkheid om keys voor zulk soort storage in TPMs en dergelijke op te slaan.

[kodak]

Zijn de diensten waar je via je entertainment-apparatuur gebruik van kan maken ontworpen om anders te gebruiken dan op je eigen pc, laptop, tablet of mobiel? Waarschijnlijk niet. Men gebruikt die entertainment-apparatuur alsof het reguliere apparaten zijn maar ontwerpt en behandelt ze niet zo.

[EraYaN]

Daarom slaan de meeste (eigenlijk bijna alle) applicaties op je PC ook geen wachtwoorden in plaintext op, maar ook alleen tokens.

[Verwijderd]

Plaintext wachtwoorden... Sorry maar dit kan toch echt niet meer...

Maar de auto moet bijvoorbeeld inloggen op netflix. Hoe ga je dat doen als de inlog code daarvoor niet plain text is? Elke keer manual gebruiker en pasword intypen? Of de data encrypten en de decoder ook in de code hebben? Dat zal veel helpen!

Jouw auto heeft waarschijnlijk ook bluetooth telefoon connectie. Bij de veel auto's houd dat ik dat het hele addresboek naar de auto is gekopieerd en dan MOET het plain text zijn want hoe kan je anders een telefoonmummer gebruiken. Daarom zie je in heel veel tweede hands auto's gewoon nog alle data van de vorige gebruiker.

Allemaal erg veel geschreeuw maar commentaar zoals van jou geeft alleen aan dat je zelf niet goed weet wat er nu echt zichtbaar is.

[Verwijderd]

Vaak hebben dat soort diensten tokens (oauth oid, bestaat al sinds 2006?) waarmee je bijv. eenmalig zou kunnen authenticeren (bij de first-time wizard van je auto oid?) en daarna wordt het token gebruikt voor het verdere verloop.
Tuurlijk, met het token heb je dan wel toegang, maar dat zijn in ieder geval niet je gebruikersnaam en wachtwoord. En daarnaast hebben die dingen ook gewoon een TTL en beperkte toegang tot functionaliteit (zo kun je zo'n token bijvoorbeeld niet gebruiken om je gebruikers gegevens oid aan te passen).

En wat betreft bluetooth; Een hoop autoradios halen gewoon elke keer bij het openen van het adresboek het spul op van je telefoon. Wordt niet opgeslagen.' Houdt wel in dat als je je bluetooth uitzet je geen telefoonboek hebt. Maar ja, bellen gaat dan ook niet.

[WoutervOorschot]

Het lijkt toch ook al lang niet meer te kunnen, gezien het om oude infotainment spullen gaat?

Maar nee, ook toen had het niet mogen gebeuren inderdaad.

[MacPoedel]

Er is niet gezegd dat op de nieuwe infotainment computers de paswoorden wel gehashd worden geen inloggegevens bewaard worden, die nieuwe infotainment computers vind je gewoon nog niet op de tweedehandsmarkt. De oude vind je net terug omdat die bij upgrades vervangen worden. De ouderdom van de infotainmentcomputers is ook heel relatief, er is hier sprake van computers uit de Model 3, die kwam in 2017 op de markt, dus dit is helemaal niet zo lang geleden.

En omdat Tesla hier niet transparant over wilt communiceren, weten we nu niet of er ondertussen nieuwe software is die de inloggegevens veiliger bewaart.

Edit: @frozensky_ Je hebt helemaal gelijk, hashen van een paswoord voor een externe service kan niet werken. Even opgezocht en de Spotify Web API gebruikt OAuth 2.0 (https://developer.spotify...ides/authorization-guide/) voor de authenticatie dus zou eigenlijk niet nodig moeten zijn om inloggegevens te bewaren. Ik ben nog aan het bijleren over API's implementeren dus is nog vrij nieuw voor me . Met de Web API kun je nog geen audio afspelen, maar die heb je wel nodig voor de authenticatie. Van wat ik begrijp bestaat de Web Playback SDK nog maar sinds 2018 (is nu ook nog beta) en kan het zijn dat Tesla dus iets bij elkaar gesprokkeld heeft, daarvoor waren er alleen een iOS en Android SDK. Beetje nadeel van eigen platform draaien, was handiger geweest dat Tesla Android Auto en Apple Carplay ondersteunt, dan moest men ook geen eigen applicatie ontwikkelen.

[Reactie gewijzigd door MacPoedel op 22 juli 2024 22:37]

[frozensky_]

Voor de duidelijkheid, ik wil niets goedpraten, maar...

> Er is niet gezegd dat op de nieuwe infotainment computers de paswoorden wel gehashd worden

Je kan niet hashen als je deze wachtwoorden wil gebruiken om op een externe service in te loggen. Het hashen van de wachtwoorden gebeurd normaal gesproken in de database waar je inlogt. Lokaal, op de client, zijn wachtwoorden meestal in "plaintext" nodig om in te loggen (of inderdaad via een session cookie, certificaat of andere authenticatie). Indien een session cookie of device koppeling niet mogelijk is via de API van de service, kan je vrijwel niet anders dan wachtwoorden gebruiken. Die zouden dan wel ge-encrypt op geslagen moeten worden. Of via een of ander secure storage device ergens vandaag getoverd moeten worden. Wellicht via een remote token, (afstandbediening/mobiele telefoon), dus er zijn zeker wel methodes om dit veilig te doen, maar er komt iets meer bij kijken.

[mjtdevries]

zijn wachtwoorden meestal in "plaintext" nodig om in te loggen

Maar dat is geen argument om die wachtwoorden ook plaintext op te slaan. Je moet ze uiteraard met encryptie opslaan en als je ze gaat gebruiken dan decrypt je ze eerst om vervolgens in te loggen.

[HitDyl]

Green the Only heeft toegang tot de nieuwe MCU's. Hij gebruikt deze namelijk om nieuwe features uit te lekken via twitter. Hij heeft dus wel de mogelijkheid dit te onderzoeken. En ik gok dat dit ook wel is gedaan. Het is alleen een beetje vreemd dat Green geen woord rept over welke MCU's getest zijn. Maar in het artikel lees je dat Netflix sessie cookies aanwezig zijn in de MCU. Dus het lijkt wel degelijk ook recentere MCU's te betreffen. MCU1 had namelijk alleen Spotify.

[Tozz]

Misschien mis ik iets, maar hoe zou je dit moeten doen dan?

De auto moet inloggen bij Spotify of Netflix. Het heeft daarvoor een username-/password combo nodig. Die moeten dus ergens in die auto staan.

Dan kun je dat encrypten, maar dan heb je een sleutel nodig. Die sleutel moet ook ergens in die auto staan.

De auto heeft verder geen input van de bestuurder nodig om te kunnen starten. Dus een pincode of patroon tekenen zoals op je telefoon kan ook niet gebruikt worden als sleutel

[Reactie gewijzigd door Tozz op 22 juli 2024 22:37]

[HitDyl]

Klopt. Volgens mij is het aardig uit zijn verband getrokken. Het is overigens niet eens duidelijk of het om plaintext wachtwoorden gaat. Dat is namelijk wat Tweakers schrijft maar het artikel van InsideEv heeft het niet over plaintext. Dat de wifi wachtwoorden toegankelijk zijn voor de MCU kom je niet omheen, versleuteld of niet. Verder zijn er overigens geen wachtwoorden opgeslagen van diensten als spotify en netflix. In die gevallen gaat het om sessie cookies. Eveneens logisch dat deze op de MCU aanwezig zijn. Dit is niet anders bij andere linux computers.

[edeboeck]

Klopt. Volgens mij is het aardig uit zijn verband getrokken. Het is overigens niet eens duidelijk of het om plaintext wachtwoorden gaat. Dat is namelijk wat Tweakers schrijft maar het artikel van InsideEv heeft het niet over plaintext. Dat de wifi wachtwoorden toegankelijk zijn voor de MCU kom je niet omheen, versleuteld of niet. Verder zijn er overigens geen wachtwoorden opgeslagen van diensten als spotify en netflix. In die gevallen gaat het om sessie cookies. Eveneens logisch dat deze op de MCU aanwezig zijn. Dit is niet anders bij andere linux computers.

Het is wel wat Green The Only op Twitter schrijft:

quote: https://twitter.com/greentheonly/status/1257051371804733447

In particular if you log into spotify - the password is stored in plain text. gmail and netflix are stored as a cookie but still give a potential attacker access. The of course all recent calendar events and your phone book and calls history too.

[HitDyl]

Sorry, klopt, dat was me nog niet duidelijk op het moment van schrijven. Het stond niet in het artikel. Deze informatie moeten we dan wel tot op heden even op de blauwe ogen van Green geloven.

[MarkII]

Je zou de sleutel (of een afgeleide daarvan) van de keycard kunnen gebruiken?

[Tozz]

De keycard heb je normaliter niet nodig. dat is een soort 'reservesleutel' bij de Model 3. Normaliter gebruik je je telefoon. Maar bij de S/X zit een gewone autosleutel zoals je die bij elke (moderne) auto krijgt.

[Fijinees]

Een wachtwoord invoeren is niet zo lastig hoor. Kan ook met voice.

[Tozz]

Je wil elke keer dat je in je auto stapt een wachtwoord invoeren om te voorkomen dat mijn MCU ooit in een container beland die iemand dan eruit vist en op eBay zet? Nee dankje, zoveel gedoe is mijn Spotify account niet waard.

[D.oomah]

Misschien naief, maar hoe doet mijn computer dat dan? Die logt in bij spotify, steam, email en meer tijdens startup zonder mijn input. Hetzelfde voor mijn telefoon, na een restart heeft hij alleen een pin nodig voor mijn simkaart. Daar hoef ik ook niet elke keer mijn spotify en google wachtwoord in te vullen.

Lijkt mij dat tesla hetzelfde systeem kan gebruiken voor hun auto's.

[Tozz]

Je computer heeft ergens die gegevens staan. Waarschijnlijk in geval van Windows staan die accountgegevens in de Windows registry, al dan niet encrypted met een key die in de .exe zit (en die er wel uit te halen is met een beetje wilskracht)

Je telefoon is een ander verhaal, als je een pincode moet invoeren om de telefoon te unlocken (wat anders dan de SIM unlocken) dan is die pincode de toegang naar de encryptiesleutels. Zonder pincode kan de telefoon kan niet bij de beveiligde data.

als je alleen een SIM-unlock pin hoeft in te geven en geen telefoon unlock pin dan is je telefoon niet wezenlijk anders dan je Windows voorbeeld of een Tesla MCU.

[mvrhrln]

Windows heeft idd voorziening voor het crypten van dit soort zaken.
(vroegere versies heette dit protected storage,, tegenwoordig cryptprotectdata api, dpapi)

[EraYaN]

Je slaat normaliter alleen een token op nadat je een (OAuth) authenticatie flow met de service doorlopen hebt. Niet de originele wachtwoorden en gebruikersnamen. Dan kun je wel toegang lekken tot het account maar heb je in ieder geval geen last van de hergebruikte wachtwoorden die mensen over het algemeen hebben.

[Tozz]

Ik zie dat inderdaad Spotify en Netflix OAuth ondersteunen. Maar volgens mij loop je dna tegen het probleem aan dat hier al eerder is genoemd, namelijk dat deze tokens periodiek verlopen en je dan weer je wachtwoord moet invoeren.

In mijn specifieke geval gebruik ik auto-generated wachtwoorden van KeePass. Niet iets dat ik graag om de 4 weken wil invoeren in de auto omdat de token is verlopen.

[EraYaN]

Je hoeft niet periodiek je wachtwoord opnieuw in te voeren (anders zou de spotify applicatie dit ook moeten) maar de token worden ververst als de applicatie gebruikt wordt voordat ze verlopen (met het dan geldige token wordt een nieuw token gemaakt). En mochten die lekken kan de service die token intrekken want de service weet bij welke sessie die horen, en het originele wachtwoord is niet uitgelekt.

[Verwijderd]

Vaak is het met apps op mobiele telefoons zo dat je eenmalig je gebruikersnaam en wachtwoord opgeeft, en daarna, elke keer als je die app opent ben je ingelogd.
Verreweg de meeste apps slaan die gebruikersgegevens niet op, maar gebruiken een authenticatie mechanisme in de API om een token te krijgen.
Dus de eerste keer authenticeren met gebruikersgegevens is om een token te krijgen.
Dit token wordt dan opgeslagen. Er kan gekozen worden om een TTL op dit token te zetten waardoor je eens in de zoveel tijd je gebruikers gegevens opnieuw in moet voeren om toegang te krijgen.

De auto heeft verder geen input van de bestuurder nodig om te kunnen starten. Dus een pincode of patroon tekenen zoals op je telefoon kan ook niet gebruikt worden als sleutel

Zou het? Dus iedereen kan bij zo'n auto het portier opentrekken er mee wegrijden?
Tuurlijk heb je een extern token nodig om toegang te krijgen tot de auto, en dit zelfde token zou een secrets DB kunnen unlocken.

Hoe je het ook went of keert, het is gewoon niet acceptabel dat tegenwoordig dit soort dingen gebeuren.

[Caayn]

Dat is wel heel slordig. Zowel dat de wachtwoorden in plain text staan als dat de computers niet eerst gewiped worden.

Wordt de data op zijn minst verwijderd/overschreven wanneer een systeem reset wordt uitgevoerd? Of is het voldoende voor eigenaren om uit te loggen?

[latka]

Waarom blijven we dit "slordig" noemen. 30 jaar geleden was het slordig. Is het inmiddels niet gewoon nalatig of erger nog: crimineel?

[Fijinees]

Dat dus.

Wie heeft het ontworpen, wie bied die dingen aan op de markt. Dit is in Europa een datalek en beboetbaar.

[MvGroenigen]

Is GDPR niet vooral ontworpen voor bedrijven die data/persoonsgegevens opslaan van consumenten?

In dit geval is het de consument die zijn eigen gegevens opslaat in zijn eigen apparaat/auto.

Als ik mijn adres / pincode / wachtwoord op een papiertje schrijf zijn de pen en papier fabrikanten ook niet aansprakelijk. Pas wanneer een bedrijf die papiertjes gaat verzamelen komt de GDPR om de hoek.

Ik ben het er totaal mee eens dat dit slordig is en zou moeten worden aangepakt.. maar juridisch kan dit wel eens heel lastig zijn.

[kodak]

In de reacties op de tweet van de onderzoekers staat dat een factory reset voldoende zou zijn.
De vraag is wie die reset had moeten doen en waarom men dat niet heeft gedaan en waarom de klant daar geen invloed op zou hebben.

Als je naar een goede garage gaat tonen ze bij vervanging je de onderdelen en leggen ze uit wat die betekenen en ze er mee gaan doen. Bij de inruil of sloop hoef je daar al helaas minder of niet op te rekenen.

[CEx]

Ik vind het niet wipen verhaal erger dan de plain text voor Spotify eigenlijk.

[bbob]

De hacker gaf zijn bevindingen door aan Tesla. Het bedrijf zei dat het klanten niet op de hoogte zou stellen van het mogelijke datalek.

Apart volgens EU wetgeving zouden ze dit normaal toch moeten melden. Neem aan dat er in de EU ook zaken vervangen worden.

Het niet melden is nogal arrogant te noemen.

[HitDyl]

De 'data lek' vindt pas plaatst als iemand zijn MCU op Ebay zet zonder de SD kaart te verwijderen. Als iemand zijn windows laptop op Ebay zet zonder encryptie (geformateerde of niet), dan kan ik ook de sessie cookies en contacten er uit halen. Maar dat lijkt me niet een data lek toe te wijzen aan de keten Windows -> Browser -> Netfix. En ik neem aan dat dit voor nog veel meer devices opgaat.

[bbob]

In het artikel staat toch dat de onderzoeker spul gekocht heeft waaruit gegevens gehaald zijn. Dus ja er is een lek als deze 2de hands apparaten door Tesla verkocht zijn.

[HitDyl]

Tesla verkoopt de MCU's niet tweedehands. Je mag hem na upgrade laten vernietigen of mee naar huis nemen. De MCU's op Ebay zijn dus van de eigenaar van de auto waar deze uitkwam. Hij mag deze natuurlijk gewoon verkopen. Maar verwijder dan de SD kaart. Daar zou Tesla beter in moeten adviseren bij het teruggeven van de oude unit.

[paoper]

Tesla geeft helemaal niet zomaar de unit mee naar huis in de meeste gevallen. Het lijkt er niet op dat deze units overgekocht zijn van de vorige eigenaars..

[Verwijderd]

Uit oorspronkelijk artikel:

According to Green, much like with a warranty replacement, you don't get to keep the old parts when you perform the FSD retrofit: Tesla claims this is for free. That apparently changes when you do the MCUv2 upgrade or if you had to replace the MCUv1 for another one in places where this retrofit is not yet offered. Green saw a TMC forum thread saying you can pay a $1,000 ‘core charge’ to keep your old computer. We could not confirm that with Tesla.

Daarnaast gaat het ook om units die uit total-loss auto's getrokken worden door bijv. het sloopbedrijf.

[mr_evil08]

Dus als je auto gestolen wordt moet je dus ook nog zorgen gaan maken dat je accounts wachtwoorden gereset worden.

[tweaknico]

Dat zul je in de digitale wereld met alles moeten aannemen.
Niets nieuws hier.

[bbob]

als ze idd in plaintext opgeslagen zijn zoals bij tesla schijnbaar het geval is, moet je je idd zorgen maken.

[Zer0]

Ook als ze encrypted opgeslagen zijn zou ik de wachtwoorden aanpassen. Ze zijn niet voor niks opgeslagen, ze worden gebruikt om te verbinden met diensten zonder dat je het wachtwoord in hoeft te vullen. Dus zolang je de wachtwoorden niet wijzigt kunnen ze er dus gebruik van blijven maken.

[Verwijderd]

Heel slecht van Tesla dat ze de mcu niet netjes wipen. Nog slechter van Spotify dat ze het wachtwoord plaintext opslaan ipv een sessie token...

[Zer0]

Wat heeft Spotify hier mee te maken? Tenzij zij de app geschreven hebben, hebben ze geen invloed op wat Tesla uitvreet.

[xoniq]

Denk dat het een app van Tesla zelf is met een API van Spotify. Net als dat apps Spotify integratie aan kunnen bieden, zoals navigatie apps. Staat spotify verder buiten behalve ja en nee zeggen tegen de login.

[HitDyl]

Volgens het artikel van InsideEv worden er helemaal geen Spotify wachtwoorden plaintext opgeslagen.

Het zou volgens Green en InsideEv gaan om:

all saved wi-fi passwords, calendar entries from the phone, call lists and address books from paired phones, Netflix and other stored session cookies.” Netflix session cookies '

Dit lijken mij overigens logische gegevens voor een linux computer. Je kan de wifi wachtwoorden gaan hashen. Maar de computer moet ze lokaal alsnog ontsleutelen.

[Zer0]

Aangezien de wachtwoorden van een linux systeem zelf niet in plain text opgeslagen worden moet dat voor wifi wachtwoorden ook geen probleem zijn.
WPA-supplicant heeft gewoon de mogelijkheid om een preshared keys te gebruiken, en biedt tools om een text wachtwoord te converteren naar PSK
Het is in ieder geval in deze tijden niet logisch om ze plain-text op te slaan.

[HitDyl]

Wifi standaarden en netwerken zijn niet mijn expertise. Maar als ik google op 'Recover wifi password linux'. Dan vindt ik wel degelijk simpele methodes om dit te doen. Bijvoorbeeld https://fossbytes.com/find-saved-wifi-passwords-linux/ en https://www.lifewire.com/...swords-with-linux-4120820 . Dan zou het niet gek zijn dat dit of iets soortgelijks ook mogelijk is met de MCU. Helaas heeft Green nog niets losgelaten over hoe hij het zou hebben gedaan.

[Zer0]

Tja, ook niet alle linux-distrubuties slaan de wachtwoorden goed op, maar dat betekent nog niet dat het daarom handig is. Maar zelf in de voorbeelden die je geeft is minimaal root access nodig.
Het opslaan van wachtwoorden op een filesysteem staat overigens helemaal los van WiFi standaarden.

[HitDyl]

Als ik zo het internet een beetje afstruin dan lijkt elke distro dit wel te doen, ook ubuntu. Tesla maakt gebruik van dezelfde software en drivers als deze distros. Dus dan is het eigenlijk niet gek dat het wachtwoord plaintext op de MCU staat. Net zoals dat blijkbaar voor een willekeurige linux laptop waarvan de harde schijf niet met een persoonlijk wachtwoord encrypted is. Iets wat met je auto nogal omslachtig is. Dat je root toegang nodig hebt maakt niet uit wanneer je de filesystem kan benaderen van buitenaf. (Het is een SD kaart). Dat neemt niet weg, dat als je het wachtwoord niet hoeft op te slaan. Het wel gek is dat de libraries die distros en ook tesla gebruik van maken, dit wel doen.

[BoekaBart]

Tsja... de Netflix oplossing (access key) is denk ik nog de mooiste, als die tenminste af en toe expired. Maar dat willen mensen ook niet, dan moeten ze telkens hun wachtwoord intikken.
Maar gehasht opslaan *kan* helemaal niet, het betreft hier immers geen server, maar een client voor die diensten. Encrypted opslaan kan wel, maar goed, de sleutel daarvan zal toch OOK in de computer moeten zitten wil hij hem gebruiken. Was hooguit wat obfuscatie geweest.

Nee, hier is eigenlijk niet zo veel wat ze conceptueel beter hadden kunnen doen... behalve dat het geheugen niet gewiped wordt / kan worden bij vervanging of defect.

Of Netflix/spotify/andere diensten vragen of ze ipv user/pass aub de public key van de auto willen supporten als authenticatie. Kennelijk was dat geen optie.

[Caayn]

Encrytie sleutels kan je prima in een secure enclave opslaan. Heb je de hardware in handen dan is het nog steeds een lastige klus om de encryptie sleutels boven water te halen.

[Pepernoot]

Gooi het dan op zijn minst even door Bcrypt of iets dergelijks...

[HitDyl]

@TijsZonderH Kan je onderbouwen dat het om plaintext wachtwoorden gaat. Het artikel van InsideEV heeft het namelijk niet over plaintext wachtwoorden. Wat ik lees is

all saved wi-fi passwords, calendar entries from the phone, call lists and address books from paired phones, Netflix and other stored session cookies.” Netflix session cookies

Dat lijken mij logische gegevens voor een linux computer. Het lijkt dus enkel om wachtwoorden te gaan van wifi netwerken en het artikel zegt niks niet over hoe die waren opgeslagen, maar dat zal in vergelijkbare wijze zijn als andere linux computers.

[TijsZonderH]

Dat zegt hij zelf op Reddit.

[HitDyl]

Vreemd dat hij dat niet openbaart in het artikel zelf. Ben toch wel erg benieuwd naar wat bewijs hiervan. Want een Spotify wachtwoord is inderdaad niet logisch. Het enige wat er voor de MCU nodig is, is de oauth token.

[TijsZonderH]

Het artikel is niet van zijn hand, hij heeft contact opgenomen met InsideEVs.com en die hebben er vervolgens iets over geschreven. Weet je zeker dat de oauth nodig is? Of is wat je vermoedt? Want mij lijkt het ook onlogisch maar zo zegt hij het wel.

[HitDyl]

Het lijkt er op dat je met de public api van Spotify dmv oauth authenticatie geen muziek kan afspelen. Het zou dus kunnen dat Tesla een private api van Spotify gebruikt die mogelijk het wachtwoord nodig heeft. Dat zou in ieder geval dan verklaren waarom het wachtwoord op de MCU staat. Doet Tesla hier dan iets heel geks, ik denk het niet. Het ongelukkige is natuurlijk wel dat degene die hun MCU op Ebay zetten niet beseffen dat ze een linux computer zonder wachtwoord op Ebay hebben gezet. Tesla zou de schijf met een wachtwoord kunnen encrypten. Maar dan zou je je wachtwoord elke keer moeten invullen in de auto.

[Ventieldopje]

Daarom laat ik mijn auto ook altijd open, anders moet ik elke keer de sleutel er in doen

Maar je reinste onzin toch voor een tech bedrijf (want dat is het meer). Wel van alles kunnen met je key fob maar dat niet?

[edeboeck]

Vreemd dat hij dat niet openbaart in het artikel zelf. Ben toch wel erg benieuwd naar wat bewijs hiervan. Want een Spotify wachtwoord is inderdaad niet logisch. Het enige wat er voor de MCU nodig is, is de oauth token.

Green The Only schrijft het alleszins op Twitter (bewijs ervan staat daar niet bij):

quote: https://twitter.com/greentheonly/status/1257051371804733447

In particular if you log into spotify - the password is stored in plain text. gmail and netflix are stored as a cookie but still give a potential attacker access. The of course all recent calendar events and your phone book and calls history too.

[HitDyl]

Dit was inderdaad onduidelijk en het door Tijs vermelde Reddit 'artikel' staat het ook in de reacties. Echter zonder een vorm van bewijs. Maar dat moeten we dan tot op heden even op de blauwe ogen van Green geloven.

[Aanwezig]

"Hackers"

[TijsZonderH]

Ik probeer de term hackers niet alleen te gebruiken voor slechte doeleinden. Iemand die computers koopt en die uit elkaar haalt om info te achterhalen, ook als ie dat met goede bedoelingen doet, is wmb een hacker. 'Een tweaker' had ook gekunnen maar dan wordt het wat te meta.

[Fijinees]

Vandaar toch ook de 2 woorden, hacker en cracker.

[TijsZonderH]

Cracker vind ik persoonlijk een foeilelijk woord. Maar belangrijker, als je dat onderscheid gaat maken zeg je eigenlijk dat iedere hacker juist weer goed is. Dat is juist weer niet de bedoeling.

[kimborntobewild]

Cracker vind ik persoonlijk een foeilelijk woord. Maar belangrijker, als je dat onderscheid gaat maken zeg je eigenlijk dat iedere hacker juist weer goed is. Dat is juist weer niet de bedoeling.

Juist om onderscheid te maken, lijkt mij dat juist wel de bedoeling. Maar goed, het woord cracker is uitermate impopulair geworden (ik denk vooral omdat journalisten altijd alle crackers en hackers op één hoop gooide: hackers). Dus kan je nu om onderscheid te maken spreken van white hat en black hat.
De white hats stellen problemen aan de kaak en maken ze openbaar; de black hats misbruiken de systemen die ze enteren voor geldelijk (of anderszins) gewin.

[Reactie gewijzigd door kimborntobewild op 22 juli 2024 22:37]

[mjz2cool]

Nee oke, het is 1 hacker.