Onderzoekers weten encryptiesleutels uit Qualcomm-socs te achterhalen

Beveiligingsonderzoekers hebben een lek ontdekt in chipsets van Qualcomm waarmee het mogelijk is om privédata en encryptiesleutels van het apparaat af te luisteren. De bug zit in miljoenen Android-toestellen, maar er is inmiddels een patch beschikbaar.

De bug zit in de Qualcomm Secure Execution Environment of QSEE, een hardwarematig afgesloten deel van een chipset waar cryptografische sleutels op een veilige manier kunnen worden opgeslagen. Het QSEE is een Trusted Execution Environment, een onderdeel van de chips dat volledig los hoort te staan van de rest van de chipset. De functie wordt doorgaans gebruikt om wachtwoorden veilig op te slaan zonder dat de rest van Android er toegang toe heeft. Het lek zit in zeker 37 socs, waaronder die uit de veelgebruikte Snapdragon 200- 400- 600- 700- 800-series.

Volgens Keegan Ryan, beveiligingsonderzoeker bij de NCC Group, lekken er bij veel Qualcomm-chips kleine hoeveelheden data naar buiten via de memory cache. Door die te analyseren kan hij de sleutels uit de QSEE aflezen. Hij gebruikte daarvoor een tool die in veertien uur de cache uit kon lezen. Een aanvaller heeft geen fysieke toegang nodig tot de telefoon om de hack uit te voeren, maar wel roottoegang. Dat is volgens Ryan met malware te regelen. De onderzoeker voegde de daad bij het woord en liet zien hoe de hack in het echt te misbruiken is door een P-256-sleutel te achterhalen uit een Nexus 5X.

Het is niet de eerste keer dat er een bug wordt gevonden in QSEE. In 2016 wist een beveiligingsonderzoeker het systeem te misbruiken om de schijfversleuteling van Android te omzeilen. Qualcomm is op de hoogte van het nieuwe lek en heeft inmiddels een patch uitgebracht. Die is doorgevoerd in de april-update van Android. Fabrikanten moeten die wel zelf nog doorvoeren naar de desbetreffende telefoons.

Alle details van het lek staan beschreven in de paper Hardware-BackedHeist: ExtractingECDSAKeys from Qualcomm’s TrustZone.

Reacties (41)

[rogier1974]

nu een alu-hoedje vraag, als de patch al zo snel beschikbaar is, is het dan een foutje by design, dat simpel op te lossen was of een oeps, wij zijn ontdekt probleem.

Alex3 en caipirinha, bedankt voor jullie reacties.

[Reactie gewijzigd door rogier1974 op 22 juli 2024 20:01]

[TijsZonderH]

Het lek werd al in maart vorig jaar aan Qualcomm doorgegeven, in oktober is het officieel opgelost, nu pas worden details naar buiten gebracht. Goede responsibe disclosure op deze manier

[wtellier]

Ik vraag me af of google dit probleem, als ze dit zelf hadden gevonden, ook al na 90 dagen kenbaar zou hebben gemaakt in haar project zero-programma, ook al zou dat veel op android-gebaseerde telefoons kwetsbaar maken. Of geldt dit enkel voor niet kwetsbaarheden waar google geen tot weinig last van heeft?

[TijsZonderH]

Ik vermoed wel dat ze dat zsm intern zouden oplossen...

[djwice]

ChromeOS en Android beheerd Google zelf, dus in jou hypothetische geval zouden ze zelf een security update kunnen uitbrengen en distribueren voordat ze de disclosure geven na 90 dagen.

[Titan_Fox]

Vind een half jaar nog rijkelijk voor een patch.

[Alex3]

Ze hebben kennelijk eerst Qualcomm op de hoogte gebracht alvorens het openbaar te maken.

[caipirinha]

Ik heb zelf ook een kast vol alu hoedjes maar het gepubliceerd krijgen van een paper kost een paar maanden tot een jaar of langer.
Bug is vast al direct gemeld aan qualcomm zodat ze bij publicatie meteen de patch konden verspreiden.

[Mavamaarten]

Er is een ongeschreven regel dat je bij het ontdekken van een belangrijk beveiligingslek eerst de vendor contacteert alvorens je je bevindingen publiceert (een zogenaamde grace period). Hierbij geef je ze de kans om het issue te fixen alvorens je mogelijk de veiligheid van anderen hun systeem in gedrang brengt.

[rogier1974]

Er is idd geen tijdlijn gegeven tussen het ontdekken en het patchen van het lek, de intentie van het zolang mogelijk stil houden begrijp ik dan ook wel. :-)

[Mavamaarten]

Een aanvaller heeft geen fysieke toegang nodig tot de telefoon om de hack uit te voeren, maar wel roottoegang.

Indrukwekkend, maar dit maakt het wel echt heel moeilijk om in the wild te misbruiken.

[ManIkWeet]

Nouja er zijn best veel gebruikers die hun apparaat geroot hebben, dus die lopen (zoals altijd) een wat hoger risico op een aanval hiermee.

[RebelwaClue]

Of juist niet, aangezien mensen die rooten, ook een root manager hebben zoals Magisk of SuperSu en dus een popup krijgen voor een applicatie die root toegang vraagt. Als apps root toegang kunnen krijgen via exploits, wordt deze manager achterwege gelaten en ziet de gebruiker geen popup.

[Rudie_V]

Maar als de malware een eigen hack uitvoert om root toegang te krijgen, kunnen ze de rootmanager en diens meldingen dan ook niet uitschakelen? Een hack vraagt volgens mij niet op de nette manier roottoegang zoals apps dat doen en die de rootmanager op kan vangen en tonen.

[RebelwaClue]

Ik weet niet hoe malware root toegang 'vraagt'. Volgens mij gebeurt dat automatisch zodra er toegang gevraagd wordt naar de system partitie.

[Verwijderd]

Oh. Nou.
Ik dacht dat er standaard 'su' wordt gebruikt.
Maar wanneer je zelf 'shellcode' kunt uitvoeren en via een andere weg door laagjes in de functie 'boom' verhoogde, of eigenlijk op diepere laag, functies kunt aanroepen op 'systeem', 'hardware' of 'kernel' niveau dan kun je minstens zoveel als op een al geroot systeem waar het eventueel gemakkelijker kan doordat 'su' beschikbaar is maar dan zonder de bekende popup.
Malware of 'root technieken' vragen dan ook helemaal niks, ze exploiteren code/design fouten.

Bijvoorbeeld door op userniveau een bestand te schrijven die op een lager niveau door het systeem foutief geïnterpreteerd wordt en daardoor data uitvoert als ware code in je geheugen, om maar een voorbeeld te geven.

Het is natuurlijk de kunst om dergelijke fouten te vinden... Gebruikers die veel software verhoogt hebben lopen op eem geroot systeem vergroten dan wel het potentieel raakvlak aan mogelijke fouten en die programmatuur kan dan ook misbruikt worden doordat ze toegang hebben tot een anders afgeschermt systeem.

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

[RebelwaClue]

Als malware root toegang kan verkrijgen door exploits en niet het SU systeem gebruikt (dat wordt idd gebruikt, vandaar de naam SuperSU), dan maakt het ook niet uit dat de gebruiker al root toegang heeft aangezien dit systeem toch gebypassed wordt. Hier is dus wel een wezenlijk verschil met bv KingRoot die via een exploit root (su) toegang krijgt.

[Verwijderd]

Klopt... Als je zelf root kunt verkrijgen dan hoef je zeker geen andere omwegen te vinden of gebruiken.
Maar je raakvlak kan wel groter zijn op een geroot systeem die meerdere, potentieel breekbare, services als root heeft draaien.

[P_Tingen]

Indrukwekkend, maar dit maakt het wel echt heel moeilijk om in the wild te misbruiken.

Slecht nieuws in de zin erna:

Dat is volgens Ryan met malware te regelen

[Reactie gewijzigd door P_Tingen op 22 juli 2024 20:01]

[TijsZonderH]

Lijkt mij persoonlijk nog steeds niet iets dat iedere huis-tuin-en-keukenhacker even kan doen, maar degenen die aanvallen van dit kaliber uitvoeren zijn dat sowieso niet lijkt me

[air2]

Als er eenmaal een tool is die dit kan, kan iedere scriptkiddie die verspreiden. Een OS schrijven is ook niet wat iedereen kan, maar dagelijks maken miljarden mensen gebruik van een OS. Datzelfde principe gaat hier ook op.

[Mavamaarten]

Tja, in de praktijk is dat toch anders. Het bewijs is dat universele rooting tools eigenlijk bijna nooit werken.

[Jerie]

Dan nog blijft de attack complexity high

[Ed Vertijsment]

Ik denk dat je dat onderschat, "rooten" van telefoons is nog steeds populair. Onverstandig IMHO, maar populair. Vaak wordt met die mogelijkheid ook gebruik gemaakt van alternatieve app stores waar code signing, reviewing en validatie wellicht een stuk minder aanwezig zijn. Dat maakt het nogal gemakkelijk exploitbaar voor een shady app bouwer die een gratis versie van een betaalde app aanbied (plus een evil payload).

Zolang mensen dus hun telefoon niet rooten is er niet zoveel aan de hand. Als je dat wel doet ben je zonder die patch op die SoCs een beetje een sitting duck.

Al met al, je draait op je Windows niet als Admin, en je *nix niet als root. Waarom zou het op je telefoon wel verstandig zijn?

[RebelwaClue]

Wat is er anders dan root op je Android tov admin onder Windows of root onder Linux?
In alle drie de gevallen is root/admin toegang niet standaard aan en draait ook niet elke app standaard met root access. Pas als het nodig is, komt er een popup. Alleen bij Windows/Linux moet er dan ingelogd worden en bij Android alleen een bevestiging (mits Magisk/SuperSu erop staat).

[Ed Vertijsment]

De vraag is echter waarom je op die knop zou drukken om wat uit voeren.

Weet je wat die code gaat doen en vertrouw je de aanbieder ervan?

Zeker op je mobile device zou ik daar heel voorzichtig mee zijn. Daarnaast kan ik mij eigenlijk niet echt een goede use case bedenken om dit te willen.

Besides, het feit dat het enabled is is al een attack vector.

[Reactie gewijzigd door Ed Vertijsment op 22 juli 2024 20:01]

[RebelwaClue]

De vraag is echter waarom je op die knop zou drukken om wat uit voeren.

Weet je wat die code gaat doen en vertrouw je de aanbieder ervan?

Dat is natuurlijk absoluut een goede vraag die alleen de gebruiker kan beantwoorden. Maar deze vragen gelden net zo bij Windows/Linux/MacOs. En helaas is de zwakste schakel vaak de gebruiker die overal ja op klikt.

En ja mobiel moet je extra oppassen met root, daarom staat het ook niet standaard aan. Maar ik kan genoeg use cases bedenken (daarom heb ik ook zelf root geinstalleerd op mijn telefoon) om het wel te willen.

[cdwave]

Bijvoorbeeld om malware te kunnen spotten, om drivers toe te voegen aan het OS, om te zorgen dat je gewoon ext4 bestandsystemen kunt lezen, om te zorgen dat mDNS werkt, om bijzondere hardware aan te sturen, ...

Redenen te over om root te willen zijn op een telefoon (of een PC).

En misschien wel gewoon omdat ik het niet eerlijk vind dan Google meer op mijn telefoon kan doen dan ikzelf.

[trenjeska]

Een patch die de helft (minimaal) van de huidige gebruikers nooit zal krijgen.

[Fermion]

De helft zou al veel zijn....

[trenjeska]

Klopt, ik was positief ingesteld vandaag.
Ik vrees inderdaad ook voor een veel kleiner deel aan gepatchde andriods en
[samenzweringsmodus] juichende veiligheidsdiensten [/samenzweringsmodus]

EDIT
wat is hier ongewenst aan? Zelfs off-topic is het niet echt, maar valt over te discussiëren.
Dit zijn de kwetsbaarheden waar veiligheidsdiensten in geïnteresseerd zijn.

[Reactie gewijzigd door trenjeska op 22 juli 2024 20:01]

[Titan_Fox]

Mijn Galaxy Note 4 heeft Android 9 (LineageOS 16.1) met de patch van April 2019. De "Vendor Security Patch" is echter van 2017. Nu is mij niet helemaal duidelijk of hier Samsung of Qualcomm wordt bedoeld.

[RebelwaClue]

Wel even goed om te weten dat de onderzoekers een Nexus 5X met Android 7.1.1 N4F26T getest hebben. De Nexus 5X heeft nog ondersteuning voor Android 8.1 waar men niet kan rooten zonder de data te verliezen.

[The Zep Man]

De Nexus 5X heeft nog ondersteuning voor Android 8.1 waar men niet kan rooten zonder de data te verliezen.

Dat betreft de legitieme manier van root verkrijgen. Er zijn minder legitieme manieren (exploits) waar malware gebruik van kan maken.

[RebelwaClue]

Zover ik weet zijn er nog geen werkende exploits voor 8.1 om root te krijgen. Ik heb het wel eens geprobeerd met Kingoroot, maar werkt dus echt niet en lijkt bijna meer een scam om je ads te kunnen tonen.

[Titan_Fox]

In LineageOS 15.1 (Android 8.1.0) had ik root-toegang m.b.v. Magisk. Werkte op zich prima. In LineageOS 16.1 (Android 9.0) kun je het inschakelen in de Developer Settings.

[RebelwaClue]

Maar in dat geval heb je root toegang door een bootloader die unlockt is met daarbij een custom recovery om de Magisk zip te installeren. Dat kan je niet vergelijken met een exploit om root toegang te krijgen op stock Android 8.1 waarbij je ook nog eens data bewaart die er al opstond.

[Titan_Fox]

Bij Samsung is die bootloader normaliter nooit gelockt. Ik heb tot nu toe alle apparaten kunnen rooten i.c.m. Odin. Je kunt dan de originele firmware houden totdat Samsung daar geen support meer op levert en stapt dan over op een custom ROM. Erg handig om zo alle bloatware er uit te slopen.

Enige nadeel met root is dat sommige apps niet meer te installeren zijn via de Play Store (je kunt de APK's gewoon los downloaden via APKMirror maar moet ze wel handmatig updaten) en Samsung's beveiligingssoftware werkt dan niet meer.

Voor mij zijn dat 'no-brainers' als ik daarmee de technologische levensduur met een aantal jaren kan verlengen, zoals met mijn 4 jaar oude Galaxy Note 4.

[Verwijderd]

Tjah, ik heb ooit eens een telefoon geroot met een of andere exploit in runtime, als die er zijn voor een android versie waar bijv. een nexus 5x opdraait, kan je behoorlijk de lul worden.

[WhatsappHack]

“Fabrikanten moeten die wel zelf nog doorvoeren naar de desbetreffende telefoons.”

Dat blijft wel altijd een beetje balen en vervelend, zeker als de fabrikant geen hol meer om het toestel geeft of er maanden over doet om eens die update te pushen.

[BikkelZ]

Volgens mij hebben higher end Samsung en Google telefoons een eigen implementatie, dus wellicht zijn die niet kwetsbaar.