Platformcertificaten van meerdere Android-fabrikanten zijn gebruikt voor malware

Googles Android Partner Vulnerability Initiative heeft melding gemaakt van een kwetsbaarheid waarbij signing keys van meerdere fabrikanten van Android-apparaten zijn gelekt. Daarmee kunnen malware-apps veel meer privileges krijgen op de apparaten dan de bedoeling is.

Łukasz Siewierski, een reverse engineer van Googles Android Security-team, maakte melding van de kwetsbaarheid. Hij zegt dat applicaties die middels het platformcertificaat zijn goedgekeurd mogelijk de gebruikersidentiteit of uid met de Android-applicatie delen, waardoor ze dezelfde permissies krijgen zonder dat de gebruiker daar toestemming voor heeft gegeven.

Deze platformcertificaten worden gebruikt om de Android-applicatie in de system image te ondertekenen. Deze applicatie draait android.uid.system en bevat de nodige systeempermissies, zoals de mogelijkheid om toegang te krijgen tot gebruikersdata. Als een andere applicatie is ondertekend met hetzelfde certificaat kan deze app aangeven gebruik te maken van dezelfde uid, waarmee het in dezelfde mate toegang krijgt tot het Android-OS.

Het zou gaan om certificaten van onder meer Samsung, LG en MediaTek. Volgens Siewierski moeten alle getroffen partijen de platformcertificaten vervangen door een nieuwe set van publieke en private sleutels. Daarnaast adviseert hij dat de partijen intern moeten onderzoeken wat de oorzaak van het probleem was. Ook raadt hij aan om het aantal applicaties dat middels het platformcertificaat wordt ondertekend, te minimaliseren. Dat zou volgens Siewierski namelijk de kosten van het vervangen van de platformsleutels aanzienlijk verlagen als een dergelijk geval zich weer zou voordoen in de toekomst.

Google heeft inmiddels aan 9to5Google een verklaring gegeven: "Fabrikanten hebben onmiddellijk mitigerende maatregelen geïmplementeerd zodra we het compromitteren van de sleutel hebben gemeld. Eindgebruikers worden beschermd door gebruikersbeperkingen die door fabrikanten zijn geïmplementeerd. Google heeft brede detectiemiddelen voor de malware geïmplementeerd in Build Test Suite, die system images scant. Google Play Protect detecteert ook de malware. Er zijn geen aanwijzingen dat deze malware zich in de Google Play Store bevindt of bevond. Zoals altijd adviseren we gebruikers ervoor te zorgen dat ze de nieuwste versie van Android gebruiken." Het is niet direct duidelijk of er nog Android-apparaten zijn die nog kwetsbaar zijn.

Deze kwetsbaarheid is niet alleen aan de orde als er een nieuwe of onbekende app wordt geïnstalleerd. De gelekte platformsleutels worden in bepaalde gevallen ook gebruikt om reguliere apps te ondertekenen, zoals bijvoorbeeld de Bixby-app op sommige Samsung-smartphones. Dat betekent dat een aanvaller malware kan toevoegen aan een vertrouwde app en die versie kan ondertekenen met dezelfde sleutel, waarna Android het zal vertrouwen en als een normale update beschouwt.

Reacties (23)

[nst6ldr]

Na wat rondzoeken kan ik nergens vinden dat Android een CRL raadpleegt. Ik hoop dat iemand me daar kan corrigeren maar als dat inderdaad niet gebeurd dan is dat toch wel bizar. Je zou deze certificaten willen intrekken en de apps in kwestie willen updaten ondertekend met een nieuw certificaat.

[P1nGu1n]

Een CRL raadplegen kan niet voor deze certificaten. Vergelijk het met Windows: Microsoft ondertekent 'explorer.exe' met hun eigen certificaat. Stel, de private key daarvan lekt uit, dan kan je het niet zonder grote gevolgen intrekken. Dat zou immers betekenen dat explorer.exe niet meer wordt vertrouwd door het OS en je Windows installatie onbruikbaar wordt.

Het hele PKI systeem is gebaseerd op vertrouwen. Dit platformcertificaat kan je zien als een soort rootcertificaat voor het ondertekenen van APK's en andere systeembestanden. Als een rootcertificaat uitlekt kan je daar niks tegen doen behalve updates uitbrengen om het certificaat te vervangen.

[Reactie gewijzigd door P1nGu1n op 24 juli 2024 17:20]

[nst6ldr]

Een CRL raadplegen kan niet voor deze certificaten. Vergelijk het met Windows: Microsoft ondertekent 'explorer.exe' met hun eigen certificaat. Stel, de private key daarvan lekt uit, dan kan je het niet zonder grote gevolgen intrekken. Dat zou immers betekenen dat explorer.exe niet meer wordt vertrouwd door het OS en je Windows installatie onbruikbaar wordt.

Maar het onbruikbaar maken van deze apps is toch juist wat je wilt? Dit is precies wat je zou verwachten van een PKI die is ingericht voor code/executable signing, binnen iOS werkt dit ook.

Dat het essentiële onderdelen van Android zijn mag dan geen probleem zijn zolang een vervanger is te pushen middels OTA - dan heb je het aantal componenten wat je niet zomaar kan vervangen teruggebracht tot één.

[P1nGu1n]

Maar het onbruikbaar maken van deze apps is toch juist wat je wilt? Dit is precies wat je zou verwachten van een PKI die is ingericht voor code/executable signing, binnen iOS werkt dit ook.

Niet als het rootcertificaat van die PKI uitgelekt is. Want dat is eigenlijk precies wat er hier gebeurd is. Dan kan je echt niks anders dan een update uitbrengen.

Het systeem is gebaseerd op vertrouwen. Als het rootcertificaat voor iOS was uitgelekt, was Apple net zo goed het haasje. Feit blijft dat het ongekend amateuristisch is dat deze keys uitgelekt zijn. Een dergelijke private key hoort ergens op een HSM te staan, waar die niet vanaf kan worden gehaald.

[Reactie gewijzigd door P1nGu1n op 24 juli 2024 17:20]

[Verwijderd]

P1nGu1n schreef onder meer:

Niet als het rootcertificaat van die PKI uitgelekt is. Want dat is eigenlijk precies wat er hier gebeurd is.

Je bedoelt de private key (passend bij de public key in het certificaat) - maar die hoeft niet uitgelekt te zijn (deze kan best "veilig" in een HSM zitten).

Als een kwaadwillende toegang heeft tot het signing proces is dat voldoende; het laten ondertekenen van de cryptografische hash van een APK volstaat.

Als ik mij niet vergis is dit ook wat bij Diginotar en zeker bij Adobe gebeurde (geen toegang tot de private key zelf, maar wel de mogelijkheid om daarmee digitale handtekeningen te zetten).

Vergelijkbaar met een FIDO2 hardware key: je kunt de private key er niet (of heel moeilijk) uithalen, maar natuurlijk wel gebruiken.

[OruBLMsFrl]

Daarom ook de oproep denk ik om enkel het systeem zelf nog hiermee te ondertekenen, en niet apps als Bixby. Hoe breder je zoiets inzet, hoe lastiger te beschermen het wordt. Maar zo'n verhaal rondom certificaten is vrijwel gelijk aan het least privilege principe, certficate (lifecycle) management is ook vrij standaard onderdeel van meer technische security audits. Gek dat zo'n tech bedrijven met hele security teams dat dan allemaal niet op orde lijken te hebben. Ben benieuwd wat hier nu achter zit ook, dat het bij meerdere bedrijven al misgegaan is, dat is nog wel het meest bijzondere hiervan.

[GertMenkel]

Na het pushen van een update wel, maar telefoons ouder dan vijf jaar krijgen die update niet en het zou best lastig zijn als je geen 112 meer kan bellen doordat de telefoon de CRL binnenhaalt.

[kodak]

Het hoeft niet alles te blokkeren. Fabrikanten kunnen ook kiezen om niet alles van een CA af te laten hangen en de gebruikers keuze te geven of het blokkerend moet zijn.
Dat bewees Google 10 jaar geleden al en toont ook hun huidige advies aan.

[CAPSLOCK2000]

Maar het onbruikbaar maken van deze apps is toch juist wat je wilt? Dit is precies wat je zou verwachten van een PKI die is ingericht voor code/executable signing, binnen iOS werkt dit ook.

Dat ligt er maar aan wie je het vraagt. Vanuit security oogpunt is dat precies de bedoeling en het systeem is er min of meer van afhankelijk. Maar vanuit gebruikersgemakt/customerservice wordt het een lastig verhaal. Voor een hoop mensen betekent het dat hun apparaat/applicatie het opeens niet meer doet en herstellen kan enorm lastig zijn, zeker als er een firmware-update voor nodig is. Dat is eigenlijk niet uit te leggen.

Maar ja, ondertussen wordt de security ook een moeilijk verhaal. Het systeem werkt alleen als je je aan de regels houdt. Die telefoons, televies, etc worden verkocht met de belofte dat ze veilig zijn omdat ze beveiligd zijn met digitale certifcaten. Zonder die veiligheid zou je ze eigenlijk niet moeten verkopen.
Overigens is dit probleem niet nieuw. CRL bestaat al heel lang en het is al jaren standaard om het uit te schakelen en hooguit best effort te gebruiken. Anders zou je apparaat niet opstarten als er geen internet is om de CRL te controleren.

Er zijn alternatieven voor CRL maar het fundmantele probleem is hetzelfde als met iedere beveiliging, mensen accepteren niet dat dingens som niet werken. Het moet altijd werken én veilig zijn maar die twee gaan nu eenmaal niet altijd samen. Conceptueel snappen ze dat natuurljk wel maar in praktijk accepteert niemand het.

[Cerberus_tm]

Volgens mij accepteren mensen best dat een apparaat nooit 100% veilig is. Ze weten gewoon dat dit nooit zo is, en gebruiken de apparaten.

[Victortjeuh]

Je kan ook een timestamping authority gebruiken die precies dit tegengaat, maar in realiteit doet niemand dat. Werkt ook niet met terugwerkende kracht.

[Reactie gewijzigd door Victortjeuh op 24 juli 2024 17:20]

[The Zep Man]

Certificaten lekken niet. Die zijn publiekelijk beschikbaar.

(Toegang tot het gebruik van) geheim sleutelmateriaal ('private key') gerelateerd aan het certificaat kan wel uitlekken zoals in dit geval, waarmee iemand anders zich kan voordoen als de certificaathouder.

[edit]
Nuance toegevoegd gebaseerd op de post van @Verwijderd.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 17:20]

[Verwijderd]

The Zep Man schreef onder meer:

Geheim sleutelmateriaal ('private key') gerelateerd aan het certificaat kan wel uitlekken zoals in dit geval, [...]

Niet noodzakelijkerwijs; toegang tot het signing proces (vaak onderdeel van een "build server" of "build street") volstaat; zie ook mijn andere post.

[Accretion]

Cool! Volgens mij zijn systeempermissies nodig voor het sturen van CEC berichten (of beeldscherm aan/uit van een Android TV).

Dan kunnen we met de key dus eindelijk een app maken waarmee we de versterker/TV aan/uit zetten en/of van input veranderen.

Dan heb je niet meer een externe CEC injector nodig, tof!

[Reactie gewijzigd door Accretion op 24 juli 2024 17:20]

[GertMenkel]

Ik weet niet of er een CEC API is op Android die je zomaar kan gebruiken. De documentatie (https://source.android.com/docs/devices/tv/hdmi-cec) lijkt toch wat aanpassingen van de system image te vereisen, waar je root voor nodig hebt.

Waar dit wel goed voor zou kunnen zijn:
- het omzeilen van VPNs
- toegang krijgen tot apparaatbeheerdersfuncties
- directe toegang krijgen tot het modem van je apparaat
- specifieke applicaties killen (virusscanners, advertentiedaemons, etc.)
- minder tot geen popups meer nodig hebben om andere applicaties te installeren
- het veranderen van systeeminstellingen

Ik verwacht dat je hier wel het een en ander mee kan doen dat de gebruiker ten goede komt, maar ik ben bang dat de overgrote meerderheid van dit gebruik eerder ten nadele van de gebruiker zal komen. Álle telefoons van deze merken moeten nu een volledige systeemupdate krijgen met een eventuele bootloaderupdate ernaast om dit probleem te herstellen en dat gaat niet gebeuren vrees ik…

[toonp]

Ik begrijp niet hoe de private keys van verschillende fabrikanten tegelijk kunnen uitlekken. Een private key bewaar je niet samen met andere partijen in een centrale repository. Hoop ik...

[bkor]

Ik begrijp niet hoe de private keys van verschillende fabrikanten tegelijk kunnen uitlekken.

In het verleden is het al meerdere keren voorgekomen dat er dingen werden ondertekend met sleutels welke echt heel erg gevoelig zijn. Je zou verwachten dat deze sleutels alleen in hardware beschikbaar zijn. Toch zijn er bijvoorbeeld verschillende soorten malware geweest welke geïnstalleerd werd als een Windows driver. Deze waren ondertekend met een sleutel van verschillende grote fabrikanten. Groot genoeg dat je aanneemt dat de beveiliging echt wel op orde is. In de praktijk lijkt dit toch anders te gaan.

Uit het artikel:

Ook raadt hij aan om het aantal applicaties dat middels het platformcertificaat wordt ondertekend, te minimaliseren.

Dit komt op mij over als een grote hint. Deze certificaten werden gebruikt voor een hoop apps. Om dat makkelijk te maken is het mogelijk dat er veel te veel toegang is tot dat certificaat.

In algemeen: Erg fijn trouwens dat de auteur dit artikel heeft geschreven. Ik zag dit beveilgingsprobleem voorbij komen op een netsec forum en heb het vervolgens hier als nieuwstip ingestuurd. Echter zit er echt een gigantisch verschil tussen wat ik instuurde (minimalistisch, dacht dat het alleen Samsung betrof) en dit artikel. Er is echt veel werk verricht om het duidelijk te verwoorden. Het komt ook uit meerder bronnen en lijkt alsof er echt veel onderzoek is gedaan.

[kodak]

It’s not known which current Android devices, if any, are still vulnerable to this security exploit.

Het lijkt me redelijker eerst duidelijk te hebben wanneer al die apparaten wel weer veilig zijn. En dat zijn die (kennelijk miljoenen) apparaten niet zomaar door wat nieuwe sleutels en certificaten te genereren. Er zal dus ook moeten blijken dat het updaten en controleren per apparaat wordt gedaan, niet dat het kan.

the malware examples were first scanned by VirusTotal as early as 2016.

Dat zou dus betekenen dat het voor een fabrikant en alle klanten dus al ruim 6 jaar een probleem was. Dan verwacht ik toch minstens ook een uitleg wat er redelijk aan de controle van de fabrikanten is die ze tot nu toe hebben en 6 jaar lang klanten in gevaar brengt.

[DeTeraarist]

Een andere rigoreuze oplossing zou zijn om derden geen systeem apps meer te laten maken. Ben alleen wel bang dat je dan direct aan andere roms moet, als je root wilt zijn over je eigen apparaat.

[kimborntobewild]

Zoals altijd adviseren we gebruikers ervoor te zorgen dat ze de nieuwste versie van Android gebruiken.

Honderden miljoenen mensen hebben niks aan die redenatie; honderden miljoenen smartphone's kunnen niet meer geupdate worden terwijl er verder helemaal niks mis is met het mobieltje.
En nee... die mensen kunnen niet allemaal elke 2 jaar een nieuwe betalen. Fabrikanten zouden verplicht moeten worden om 10 jaar of langer security updates te maken, en de telefoons weer tegen een behoorlijk vergoeding moeten innemen als dat niet lukt.

[Ne0fr0g]

Google heeft brede detectiemiddelen voor de malware geïmplementeerd in Build Test Suite, die systeemafbeeldingen scant

Systeemafbeeldingen…

[nsttu]

Dat is toch gewoon het Nederlandse woord voor systemimages?

[MaDMaRTiGaN648]

Net zoals een disk image een plaatje of tekening van een disk is? Volgens mij vertalen we image in dat geval naar kopie.