Beveiligingsbedrijf: veel Android-apps voor auto's zijn onveilig

Beveiligingsbedrijf Kaspersky heeft een presentatie op de RSA-conferentie gehouden over de veiligheid van Android-apps voor auto's, waarmee bijvoorbeeld de deuren te openen zijn. De zeven onderzochte apps bleken verschillende beveiligingsproblemen te hebben.

De onderzoekers beschrijven hun bevindingen in een blogpost. Zij hebben populaire apps van verschillende autofabrikanten onderzocht, maar maken de identiteit van de fabrikanten niet bekend. Zij zeggen wel hun bevindingen met de bedrijven gedeeld te hebben. Zij keken onder andere naar bescherming tegen reverse engineering, controle op root-permissies en een integriteitscontrole op gewijzigde code.

Zij kwamen erachter dat geen van de onderzochte apps maatregelen neemt tegen reverse engineering, waardoor een kwaadwillende partij eenvoudig de code van de app kan onderzoeken en kwetsbaarheden kan vinden. Daarnaast ontberen alle apps een integriteitscontrole, waardoor eventueel aangepaste code niet opgemerkt wordt. Volgens de onderzoekers zou een aanvaller bijvoorbeeld kwaadaardige code in een app kunnen injecteren en deze als legitieme app in de Play Store kunnen zetten.

Een controle of de telefoon rooted is, voeren de apps ook allemaal niet uit. Dat brengt risico's met zich mee, omdat malware op een telefoon met root-toegang veel schade kan aanrichten volgens de onderzoekers. Bovendien worden de wachtwoorden van de gebruiker in twee van de zeven gevallen onversleuteld opgeslagen. Ook bescherming tegen phishing door middel van een kwaadaardige overlay ontbreekt in alle gevallen.

Doordat de apps bijvoorbeeld de autodeuren ontgrendelen of de motor kunnen starten, kan een kwaadwillende partij mogelijk veel schade aanrichten. De onderzoekers zeggen dat er tot nu toe nog geen malware ontdekt is die zich richt op autoapps. Het zou echter niet moeilijk zijn om malware te ontwikkelen die een configuratiebestand van een dergelijke app doorstuurt naar een command and control-server. Een verklaring voor de afwezigheid van dergelijke malware zou kunnen zijn dat het momenteel nog niet economisch interessant is om deze te ontwikkelen.

De bevindingen per app

Reacties (48)

[P1nGu1n]

Overdreven post van Kaspersky. Commentaar op de genoemde problemen:

App code obfuscation
Slecht dat dit niet aan staat, dit hoort eigenlijk standaard te zien voor iedere app. ProGuard support is ingebouwd in de Android Gradle plugin en dus zeer eenvoudig in te schakelen en te configureren.

Unencrypted username and password
Gegevens (extra) veilig opslaan in Android is een hel. De keystore (vergelijkbaar met de keychain in iOS) is een drama en kent vele haken en ogen. Overigens is de data folder van applicaties afgeschremd in Android en hebben alleen maar de app zelf en het systeem toegang toegang tot de gegevens, als je die 'normaal' op slaat. Met root toegang kan je hier wel bij, maar daarmee is in feite alles mogelijk...

Overlay protection
Overlay protection (AKA tapjacking protection) is kinderlijk eenvoudig te implementeren (zelf al eens gedaan in een app), onbegrijpelijk dat ze dat niet doen.

Root detectie
Root is nooit 100% te detecteren. Als iemand wil, kan die het toch wel verbergen, je hebt immers toch al een soort god-mode.

App integrity check
Wat willen ze hier mee bereiken, dat je de app niet kan modden? Als je de app toch aan het modden bent, sloop je meteen die integrity check eruit...

Al met al, code obfuscation en tapjacking protectie moeten ze echt toepassen. Root detectie en integrity check zijn overrated en een perfecte oplossing voor het encrypted opslaan van gegevens is er niet in Android. Overdreven post van Kaspersky.

[Reactie gewijzigd door P1nGu1n op 28 juli 2024 15:15]

[Anoniem: 85014]

Integrity check zit in de package manager. M.a.w de software die de software installeert. Niet in de software zelf.

Encrypted gegevens opslaan kan de software zelf implementeren. Het hoeft daar geen slechte keystore voor te gebruiken (als de standaard niet voldoet).

Voorts zou men van mij de hele software in een container moeten draaien. Iets zoals Flatpak of Linux Lightweight Containers. Misschien dat Android dat nog niet kan. Dan is Android niet geschikt als besturingssysteem voor auto's.

[P1nGu1n]

Integrity check zit in de package manager. M.a.w de software die de software installeert. Niet in de software zelf.

Dat is een signature check en niet waar ze hier op doelen. Re-signen en de package manager is weer tevreden.

Encrypted gegevens opslaan kan de software zelf implementeren. Het hoeft daar geen slechte keystore voor te gebruiken (als de standaard niet voldoet).

Hoe zie je dit voor je? De key waarmee het encrypt moet ook ergens worden opgeslagen.

[Reactie gewijzigd door P1nGu1n op 28 juli 2024 15:15]

[Anoniem: 85014]

Wat zou je denken van de key in de sleutel van de auto op te slaan? De auto leest je sleutel nu toch al uit voor gelijkaardige doeleinden, op gelijkaardige manier, om te weten of de motor mag starten (bij een moderne auto met een modern sleutelsysteem).

Je kan bij deftige package management systemen aangeven welke package repositories je vertrouwt. Als jij zo'n package resigned dan zal een deftig package management systeem jouw resigned package niet accepteren. Want je kan je resigned package niet valideren t.o.v. een public key van een geregistreerde vertrouwde repository.

Dit is standaard in RedHat (OpenSuse, RedHat, Fedora, Mer, etc) en Debian (Ubuntu, etc) package management. Als jij een random repository toevoegt aan apt.conf en voor die repository heb je geen vertrouwde sleutel geaccepteerd, dan zal apt-get je telkens waarschuwen dat je software aan het installeren bent die je niet hebt vertrouwd. Als je daar ja op antwoord dan heb je het natuurlijk zelf gedaan als je gecompromiteerd wordt. Als je er juist mee werkt dan zullen die (standaard) package management systemen geen software waarmee getampered is installeren.

[P1nGu1n]

Wat zou je denken van de key in de sleutel van de auto op te slaan? De auto leest je sleutel nu toch al uit voor gelijkaardige doeleinden, op gelijkaardige manier, om te weten of de motor mag starten (bij een moderne auto met een modern sleutelsysteem).

Maar bIj het gebruik van de app komt er helemaal geen autosleutel aan te pas? Alles gebeurt met en op je smartphone, dat is net het lastige qua security.

Je kan bij deftige package management systemen aangeven welke package repositories je vertrouwt. Als jij zo'n package resigned dan zal een deftig package management systeem jouw resigned package niet accepteren. Want je kan je resigned package niet valideren t.o.v. een public key van een geregistreerde vertrouwde repository.

Dit is standaard in RedHat (OpenSuse, RedHat, Fedora, Mer, etc) en Debian (Ubuntu, etc) package management. Als jij een random repository toevoegt aan apt.conf en voor die repository heb je geen vertrouwde sleutel geaccepteerd, dan zal apt-get je telkens waarschuwen dat je software aan het installeren bent die je niet hebt vertrouwd. Als je daar ja op antwoord dan heb je het natuurlijk zelf gedaan als je gecompromiteerd wordt. Als je er juist mee werkt dan zullen die (standaard) package management systemen geen software waarmee getampered is installeren.

Package manager in het geval van Android is normaal gesproken de Play Store.

[Reactie gewijzigd door P1nGu1n op 28 juli 2024 15:15]

[Anoniem: 85014]

Mja je zegt twee keer achter elkaar: de veiligheid van de automobilist kunnen we niet waarmaken omdat ... Android.

Dus dan is Android ongeschikt als besturingssysteem voor een auto.

Android is niet het enige dat bestaat he.

[P1nGu1n]

Mja je zegt twee keer achter elkaar: de veiligheid van de automobilist kunnen we niet waarmaken omdat ... Android.

Ik zeg niet dat er een probleem is, dat zegt Kaspersky. Ik zeg dat het probleem wel mee valt. Wat betreft veilig info opslaan is er zeker ruimte voor verbetering. Die keystore is instabiel en onbetrouwbaar.

Dus dan is Android ongeschikt als besturingssysteem voor een auto.

Dit gaat dan ook niet over Android als OS voor een auto, maar een app op je telefoon om de auto te bedienen. Android Auto is overigens ook een prachtig stukje software

Android is niet het enige dat bestaat he.

Maar wel waar dit artikel over gaat

[Reactie gewijzigd door P1nGu1n op 28 juli 2024 15:15]

[cruysen]

Zoals ik het artikel ook lees gaat het over de telefoon Apps die je deur ontgrendelen. Dus niet de software die eventueel o.a. op je autoradio draait.
Dus het gevaar waar over gesproken wordt is dat je auto gestolen kan worden door deze onveilige apps


En waarom moet het gebruiker en paswoord gegevens in de telefoon bewaard worden? Waarom niet het commando encrypten met het paswoord en laat de auto controleren of dit klopt. Het paswoord kan dan ook nooit uitgelezen worden uit de code op je telefoon! (Alleen via een overlay, maar dat is bij een PC ook met een keylogger )
Dacht dat de PIN verificatie bij de bank ook zo werkte...

[Reactie gewijzigd door cruysen op 28 juli 2024 15:15]

[Patriot]

Jij bent met een heel ander soort beveiliging bezig in je hoofd dan waar dit artikel over gaat. De beveiliging in het artikel gaat niet over de gebruiker beschermen tegen kwade derden, maar over de app beschermen tegen kwade gebruikers.

[cruysen]

Klopt, daarom ook het 2e gedeelte. Door geen inlog gegevens in/met de App op te slaan voorkom je dat de app onveilig is. (zoals in het artikel omschreven: In APP 2#:... the username and password are stored as plain text in the prefs file.{?????????}.xml file)

[Reactie gewijzigd door cruysen op 28 juli 2024 15:15]

[totaalgeenhard]

Als je root hebt maakt alles wat daarna komt helemaal niets meer uit.
Backdoor van kernel en processen is niet te detecteren en dus afvangen/rerouten/bekijken van processen dus ook niet.

App code obfuscation

is geen beveiligingsmaatregel. Als code op zichzelf staand al niet deugd dat maakt "obfuscation" ook niet uit, bovendien kost het niet veel moeite omdat ongedaan te maken.

App integrity check

als je root bent maakt dat ook niet uit.

Eigenlijk komt het erop neer dat je Android e.d. gewoon niet voor dingen moet toepassen waar mensenlevens mee in gevaar komen.

[P1nGu1n]

App code obfuscation
is geen beveiligingsmaatregel. Als code op zichzelf staand al niet deugd dat maakt "obfuscation" ook niet uit, bovendien kost het niet veel moeite omdat ongedaan te maken.

Hier ben ik het niet mee eens. Dit is een onomkeerbaar proces (alleen met de mapping.txt die proguard genereert). Decompilen van een Dalvik Executables is eenvoudig (dex2jar, jadx, baksmali, etc.). Maar voor deobfuscation ken ik geen techniek. Alleen apk-deguard komt een beetje in de buurt, maar geeft weinig bruikbare resultaten.

Dus weet je een manier, please let me know! Zou ik goed kunnen gebruiken

[totaalgeenhard]

In China 10 usd per file.

Goed zoeken. O.a. paypal gooit account meteen dicht als ze er achterkomen dus ze zijn voorzichtig.

https://www.google.nl/search?q=deobfuscation+apk

[Reactie gewijzigd door totaalgeenhard op 28 juli 2024 15:15]

[Qauters]

Obfuscation is zeker niet onomkeerbaar, je krijgt weliswaar de originele namen niet meer terug maar met genoeg debugging kan je zelf namen bedenken. De rest van de obfuscation (denk aan flow-obfuscation, string-obfuscation, integer-obfuscation, meerdere obfuscation technieken die decompilers lastig vallen), zijn allemaal te verwijderen. Het belangrijkste is vooral dat het aantal mensen die dit kunnen veel kleiner is en daarom je de kans een heel stuk kleiner maakt dat je code gekraakt wordt.

Een mooi voorbeeld is Pokémon go, dit was binnen de kortste keren gere-engineerd, vervolgens hebben ze hulp ingeschakeld om dit te voorkomen en nu is er nog maar een select gezelschap die dit gedaan heeft en dit daarom ook private houdt. Hiermee los je dus wel degelijk problemen op, alhoewel dit niet betekent dat je dan ook 100% veilig bent.

[ikt]

Root detectie kan door Android worden afgehandeld met Safety Net. Wanneer het apparaat geünlocked wordt, geroot en/of er aan de systeempartitie wordt gezeten, merkt Safety Net dit op. Het is een lopende race waar Google altijd voor loopt op de community, dus het is een redelijk veilige manier die ook nog eens makkelijk te implementeren is, wanneer er zorgen zijn over het toestel waar de app op werkt.

Pokémon Go is een app die dit bijvoorbeeld gebruikt

[P1nGu1n]

Ook SafetyNet is te omzeilen, bijvoorbeeld door te rooten met Magisk en suhide.

[Reactie gewijzigd door P1nGu1n op 28 juli 2024 15:15]

[ikt]

Magisk is recentelijk geüpdated naar een versie die SafetyNet kon omzeilen, maar hier doe je dingen via Magisk die je nog apart hebt geflasht. Voor een aanvaller is het veel moeilijker om SafetyNet te omzeilen, bijvoorbeeld nadat er root-toegang is verkregen tot het doelwit. Mochten autofabrikanten dit implementeren, dan is er al een grote aanvalsvector weg.

Met fysieke toegang tot het Android-toestel kun je toch al bijna alles, dus de aanvalsvector van buitenaf elimineren is hier een redelijke oplossing.

[Anoniem: 636203]

Je kan de app toch niet modden? De signature wordt namelijk genomen over de hash van de hele app (alle bestanden).

[P1nGu1n]

Je kan apps zeker wel modden. Meestal wordt de Dalvik Executable (.dex in de APK) decompiled met behulp van baksmali naar smali code, deze kan je aanpassen en weer compilen met de tool smali. Voor het aanpassen van resources (drawables, colors, layouts, strings, dimens, etc.) wordt doorgaans apktool gebruikt.

Vervolgens kan je de apk opnieuw signen met je eigen certificaat met behulp van jarsigner of apksigner. De nieuwe signature komt wel weer overeen met de aangepaste inhoud. Omdat het gebruikte certificaat anders is, kan je de aangepaste APK niet installeren over de originele, maar een normale installatie kan wel, omdat de signature gewoon valid is.

[Anoniem: 636203]

Ok, maar dan ben je feitelijk een nieuwe executable aan het maken op basis van een andere. Feit is dan dat je goede obfuscation moet gebruiken.

[Dual Infinity]

[q]Gegevens (extra) veilig opslaan in Android is een hel[q/]
Hoezo?

Je kunt gewoon de account manager gebruiken voor credentials:
https://developer.android...ounts/AccountManager.html

Zie o.a.:
- http://stackoverflow.com/...ing-username-and-password

[Jerie]

Overdreven post van Kaspersky.

In 2 seconde peak zag ik al meteen dat ze het hadden over unencrypted login. Unencrypted username is geen enkel probleem. Dat heb je op Tweakers ook.

[partsineed]

Ik vind t eigenlijk wel diep triest dit.
Iedere dag dan wel week van dit soortgelijke berichten.
Idd gelukkig zijn er watchdogs

[Anoniem: 85014]

Er wordt echter voorlopig nog veel te weinig mee gedaan. Het zal letterlijk wachten worden tot er doden vallen, eer men dit serieus begint te nemen. Daarna zal het vele jaren duren eer alle bestaande modellen en toepassingen aangepast of verdwenen zijn.

Dat zal er oa. voor zorgen dat bv. autonome wagens trager werkelijk gaan worden. Dus als die industrie snel vooruit wil komen, zal het net voor keurmerken en regulering moeten lobbyen. Net niet tegen.

[partsineed]

Heb je gelijk in.
Hele concept van zsm op de markt brengen.
Centjes zijn binnen, en ach dat hun wat overkomt, bijzaak.
Zo komt het over, vind t echt erg jammer.

[Anoniem: 85014]

En zo zit 90% van de software industrie in elkaar. Spijtig genoeg. Het is voor mij als programmeur zelfs erg moeilijk me te positioneren bij die 10% die het wel probeert goed te doen (mijn truck daarvoor is me te specialiseren in embedded - maar die IoT cowboys zijn ook dat segment aan het verzieken, helaas).

Verantwoordelijkheid opnemen zit er veel de overgrote meerderheid van de softwareontwikelaar-industrie spelers absoluut niet in. Bv. upgrades voorzien, daarvoor met deftige en standaard package management systemen werken (die cryptografisch signen), de software in containers draaien of dat mogelijk maken, of heel gewoon eens NIET beslissen de privacy van uw gebruikers volledig te willen verkrachten, etc

[partsineed]

Embedded daar ben ik ook voorstander van, is dat dan zo moeilijk of kost het ze teveel ?
IoT is ook leuk.maar wat je zegt dat word ook ver...cht.

Hoop dat we snel verbetering gaan zien voor dat er ongelukken gebeuren of voordat je auto er met jouw vandoor gaat.

[Anoniem: 867213]

Alles is moeilijk en duur als je het goed wilt doen. Dat betekent dat je bij -elke- keuze die je maakt de afweging moet maken tussen de voordelen, nadelen, mogelijke risico's en kosten om die af te dekken.
Dat nadenken alleen al kost tijd, en dus geld.
Bij IoT, maar ook bij WordPress zie je flatsflatssnelklaar, en blijkbaar dus nu ook bij auto's.

[kimborntobewild]

Tja, het ontbreekt duidelijk aan regulering en controle daarop. Hoort bij vrije markteconomie-denken.

[Arrogant]

Waar wil je precies regulering en controle op?

[kimborntobewild]

In dit geval natuurlijk op veiligheid.

[Arrogant]

Wat je dus wil is een aanpassing op iets wat al bestaat: het E-keurmerk.

[kimborntobewild]

Dan stelt dat keurmerk dus weinig voor. Of het keurmerk zit er gewoon niet op. Eén van beide, of allebei.

[Mic2000]

Fijn dat er bedrijven zijn die deze systemen tegen het licht houden en dit publiekelijk bekend maken. Ik denk dat het goed is om problemen als deze te blijven bespreken totdat het gemeen goed / vereiste is voor elke auto / android ontwikkelaar.

[Macshack]

I.p.v. dat Google nou gaat onderzoeken of anderen wel hun lekken op tijd dichten op hun eigen platformen. Kan Google beter onderzoek doen naar zijn eigen platformen, infrastructuur en de apps die daar op draaien. Maar daar nemen ze geen tot weinig serieuze verantwoordelijkheid voor. Het zijn altijd andere partijen die dit soort dingen aan het licht brengen. Maar als ik zo het lijstje lees waar een gemiddelde programmeur bij Android allemaal aan moet denken om zijn app veilig te maken sta ik toch enigszins versteld. Android moet gewoon zo werken dat het alleen apps kan draaien die aan de veiligheids- en privacynormen voldoet. Kan Android dit niet valideren dan zou het Google sieren om hier iets op te verzinnen. Maar ja, Apple was alleen maar arrogant, vervelend en dichtgetimmerd. Tot nu toe lijkt het er alleen maar op dat het beter voor de consument was dan die schijn-open houding van Google. Android ditchen en naar Windows mobile gaan of zo. Maar Android moet echt afgelopen zijn zo onderhand.

[chimnino]

K begrijp die behoefte voor t altijd maar alles willen connecten nog steeds niet... T gescheiden houden van systemen houd dingen ook veilig. Mijn tv, koelkast, was- en droogmachine, thermostaat of auto zal iig nooit n virus of hack bevatten....

[real[B]art]

Dat is simpelweg een vorm van klantenbinding. Je mooie slimme Toon thermostaat wordt een hele dure domme thermostaat op het moment dat je besluit niet langer klant bij Eneco te willen zijn. En zo werkt het met veel meer producten.

[chimnino]

Mooi, slim en Toon in 1 zin... hahahaha

[cruysen]

Niet om een discussie tussen IOS en Android te starten. Maar zijn de IOS apps van die merken ook onveilig aan deze criteria? Of zijn die niet getest door Kaspersky?

[LodanMax]

Het verschil tussen Android en iOS is dat er bij iOS altijd een medewerker naar de code en app kijkt voor deze bijgewerkt wordt in de store.

Daarnaast heb je ook nog eens kosten welke betaald moeten worden om apps in de appstore te publiceren, rendert Apple de apps vervolgens ook nog eens waardoor je de bestanden niet los meer kan inzien.

Het is wel een heel terechte vraag, want bepaalde andere veiligheidspunten zijn nog wel van toepassing welke niet goed ontwikkeld kunnen zijn. Maar de app namaken met een soortgelijke naam, is bij Apple door de controle duurder en veel lastiger.

[PureTryOut]

“Geen obfuscation”. Nou en? “Security through obscurity” is de slechste beveiliging die er is, niemand moet daar gebruik van maken. Het mooiste zou zijn als al deze apps open-source waren, dan kon iedereen zoeken naar beveiligingsproblemen om deze zelf op te lossen of te melden. Waarom denkt de business world daar zo anders over?

[real[B]art]

Code obfuscation maakt reverse engineering ontzettend veel moeilijker en tijdrovender, dus duurder. Het is hetzelfde als een middelmatig slot op je fiets: als iemand het echt wil, houdt dat slot hem niet tegen, maar er zijn nog driehonderd andere fietsen om je heen met simpelere of geen sloten.

[_Thanatos_]

Een controle of de telefoon rooted is, voeren de apps ook allemaal niet uit. Dat brengt risico's met zich mee, omdat malware op een telefoon met root-toegang veel schade kan aanrichten volgens de onderzoekers.

Bullshit. Een PC is ook "rooted", en dat gaat ook gewoon goed. Bouw je app gewoon solide, en installeer geen crap.

[sxbrentxs]

Buiten het feit dat dit rapport overdreven is en de helft van de checks weinig tot geen waarde bieden, blijft ik bij het feit dat als je zo'n een lek en overheersend OS gebruikt, je never te nimmer een goeie app kan krijgen dat op een sensible manier z'n veiligheid kan behouden.

Dat gezegd hebbende, ik vind het onvoorstelbaar dat die apps uitgekomen zijn en toegelaten worden door autofabrikanten op hun auto's zonder enig gedachte voor veiligheid van de auto's zelf. Tesla kan 't, en die zijn net begonnen. Waarom de rest niet? (retorisch)

[sugarlee89]

Wat dacht je dan haha. Android is een en al onveilig. Is het schoolvoorbeeld van onveiligheid. Kun je nog beter netscape 1.0 en windows 95 draaien. Zit je veiliger en af en toe ctrl alt del drukken omdat er weer een bsod op je scherm komt. Gewoon ctrl alt del toetsen op je stuur integreren.