Google dicht Android-zeroday die door Servische autoriteiten misbruikt wordt

Google heeft in zijn beveiligingsupdate van april patches uitgebracht voor twee zerodays die actief misbruikt worden. Eén daarvan is onderdeel van een exploitketen die de Servische inlichtingendienst zou misbruiken.

Het gaat om CVE-2024-53197, die zich in de USB-audiodriver voor ALSA-apparaten in de Linux-kernel bevindt, schrijft Bleeping Computer. Wanneer een aanvaller fysiek toegang heeft tot de USB-poort van een vergrendeld apparaat, is het mogelijk om toegang te krijgen tot de gegevens op dat apparaat. Daarvoor hoeft het slachtoffer niets te doen.

Mensenrechtenorganisatie Amnesty International kwam de fout vorig jaar op het spoor, toen het ontdekte dat de Servische inlichtingendienst een spywareprogramma van het Israëlische Cellebrite gebruikt om de vergrendeling van in beslag genomen telefoons van activisten te kraken. Daarvoor wordt een exploitketen ingezet, waar de nu gedichte kwetsbaarheid onderdeel van zou zijn. In februari en maart werden twee andere fouten gedicht die ook deel uitmaakten van de keten.

De tweede zeroday die Google nu gedicht heeft, is CVE-2024-53150. Daarmee kunnen lokale aanvallers toegang krijgen tot gevoelige informatie op kwetsbare apparaten, zonder dat daar interactie van de gebruiker voor nodig is. Ook van deze fout zijn er signalen dat deze al misbruikt wordt, zegt Google. De beide zerodays worden gedicht via patch 2025-04-05. Het bedrijf dichtte deze maand daarnaast nog zestig beveiligingsproblemen. De volledige lijst met patches is te vinden in het securitybulletin van april.

Door Eveline Meijer

Nieuwsredacteur

10-04-2025 • 07:28

37

Submitter: Flavius

Reacties (37)

37
36
24
4
0
10
Wijzig sortering
Let wel op dat er 2 patch levels zijn elke maand. Dat je de april patch ontvangen hebt wil niet zeggen dat deze lekken ook gedicht zijn. In het 2025-04-01 patch level zitten geen fixes voor de kernel en firmware, dus die is niet genoeg. Je hebt het 2025-04-05 patch level nodig om deze kwetsbaarheden te patchen. De meeste fabrikanten brengen alleen het 01 patch level uit.
In principe moet een 01 patch level wel cumulatief zijn voor alles van de voorgaande maanden, dus dan ontvang je deze fixes bij de volgende patch van de fabrikant.
Het is wel zo dat de fabrikant zelf de string van het patch level bepaalt. In het verleden was het in ieder geval zo dat veel fabrikanten nieuwe 01 patch levels aangaven zonder dat ze ook de voorgaande 05 patches geïmplementeerd hadden. Dat kon je toen nog controleren met SnoopSnitch maar die heeft helaas sinds oktober 2023 geen updates meer gehad. Of fabrikanten dat nu nog steeds zo doen weet ik niet.

Overigens is het 05 patch leven ook geen complete security updates. De Android Security bulletins zijn backports met alleen de High en Critical kwetsbaarheden, niet de Medium en Low.
Die worden alleen in de laatste versie van Android gefixed. In het huidige geval is dat ook niet 15.0. Android/AOSP wordt steeds verder ontwikkeld met maandelijkse en kwartaalupdates, al geeft Google helaas geen versienummers zoals 15.1.2 of 15.2. Alleen QPR1 (of 2/3) voor de kwartaal updates.
Voor zover ik weet zijn Pixels de enige telefoons die echt de up-to-date Android krijgen en die dus ook de low en medium fixes krijgen. Bij andere fabrikanten krijg je die maar 1 keer per jaar bij de grote Android update. (Als je die uberhaupt krijgt, want vaak is het aantal jaren upgrades lager dan het aantal jaren security updates.)

[Reactie gewijzigd door Matthijs8 op 10 april 2025 12:37]

Gezien het feit dat heel veel overheden gebruik maken van Cellebrite denk ik niet dat enkel Servië deze exploit actief misbruikt heeft.
Die kans is zeer aannemelijk. Echter is zover bekend alleen van Servië daadwerkelijk bekend/zeker dat ze de exploit gebruiken.

Echter ook van Turkije, de VAE, Rusland, Wit-Rusland, Venezuela, China, Myanmar, en enkele van de doodseskaders in Bangladesh is bekend dat ze klant/gebruiker van Cellebrite zijn (zie dit artikel), en met de reputatie van die landen is het niet geheel onmogelijk of onverwacht dat zij deze exploit ook gebruiken/misbruiken, alleen is het van hen (nog?) niet met zekerheid vast te stellen.
Men krijgt gewoon de "nieuwste" release van Cellebrite waar alle bekende en werkende exploits in verwerkt zitten. Dus als je release x.x.x van Cellebrite gebruikt dan wordt er gewoon gebruik gemaakt van deze exploit (en een boel andere) om een telefoon uit te kunnen lezen. Er is geen keuze....

En gezien het kat-en-muisspel tussen fabrikanten en software zoals Cellebrite wil je als overheid gewoon de meest recente versie hebben.
dus Google, Samsung en Apple moeten ook gewoon klant zijn en zorgen dat ze zo snel mogelijk de laatste versie van die software testen om te kijken wat het doet?
Cellebrite doet enkel zaken met overheden / law enforcement. Hun Enterprise tak biedt andere soort software aan.
Een gedachte experiment: als zó duidelijk is dat een land deze exploits gebruikt, is hard afsluiten van dat land van de google-diensten dan niet gewoon de best werkende methode? Jammer maar helaas...
Wat lost dat op? Dan zuu voir de gebruikers in dat land ineens hun telefoon niet meer werken.
Klopt, dat is het grote nadeel, maar ik vind het wel vergelijkbaar met wat er nu gebeurd: bijvoorbeeld de Europese tarieven worden gezet op producten die vooral Repulibkeinse kiezers raken. Het systeem an-sich 'om de eindgebruiker dan maar lastig te vallen' wordt dus meer gebruikt.
je bent de 2 grootste boosdoeners nog vergeten: de VS en Israël.
Laten we niet stemmingmaken, maar inderdaad is het niet ondenkelijk dat men in de VS bekend is met deze software, en Israel is het land waar het wordt gemaakt, dus het is vrij logisch dat men het daar gebruikt.
Ik ben het niet eens met waar het meestal voor gebruikt wordt, maar kan ook wel goede doeleinden bedenken. Het opsporen of vervolgen van criminelen is ook mogelijk, wat mij betreft is het dan fair game. Helaas zijn er dan weer overheden die de definitie van 'crimineel' oprekken.
Het is gewoon een feit dat de VS gebruikt maakt van Cellebrite. Het is de "de facto standard" voor het uitlezen van telefoons. De landen die er geen gebruik van maken zijn waarschijnlijk op enkele vingers te tellen...

Alternatieven zijn Greykey, XRY en Oxygen (en nog wat anderen), maar geen van allen bieden een gelijkwaardig "all in one" oplossing + gebruiksvriendelijkheid van Cellebrite.
De Amerikaanse inlichtingendiensten zullen wel exploits hebben waar wij nooit weet van hebben.
Wellicht dat Shadow Brokers of andere hacker groeperingen het wederom voor elkaar krijgen om dat soort tools van NSA te stelen. Wie weet...
Het verkrijgen van inlichtingen door overheden is natuurlijk onder voorwaarden legaal en daarvoor worden allerlei middelen, waaronder deze, ingezet. Dat is altijd zo geweest en zal altijd zo blijven.
Dat er landen en andere actoren zijn die deze middelen misbruiken is ook altijd al zo geweest.
Dat maakt het middel niet crimineel maar de gebruiker wel.
Je zou eigenlijk sowieso geen USB-communicatie mogen doen met een apparaat dat wordt aangesloten in de vergrendelde toestand behalve laders.
(En misschien bekende devices; En weer verplicht ontgrendelen bij een nieuw of ander aangesloten apparaat.)
GrapheneOS heeft hier een hele goede implementatie voor. Het is mogelijk om in de instellingen in te geven dat USB niet beschikbaar is of alleen voor opladen. Die laatste zet de hardware (pogo) pins voor data uit waardoor er niets anders mogelijk is dan data. Omdat dit hardwarematig is, hoeft Android dus niets af te handelen. Sterker nog, die ziet niet dat er iets is aangesloten.

Het bekende devices toelaten is daarentegen weer een lastig iets. Daar is het OS wél bij betrokken, naast dat het ook te spoofen is. Als je het zou toestaan met de USB vendor ID en product ID, is het vrij "lek".

(los hiervan had GrapheneOS de kwetsbaarheden al gepatcht: https://discuss.grapheneo...-serbian-student-activist)
Is dat niet een standaard optie binnen Android?
Ik vroeg mij namelijk ook af of dit soort software ook werkt als je die optie op "alleen opladen" zet.

Iemand die daar meer inzicht in kan geven?
Ja dat kan in zowel Android als in iOS. Het grote verschil is de implementatie. GrapheneOS is de enige die het via de pogo-pins doet, dus echt via de hardware.

Het kan zijn dat dit concept later door AOSP wordt geïmplementeerd. Dat zou niet de eerste feature zijn die vanaf GOS doorvloeit. Maar of dat zo gaat zijn, de tijd zal het uitwijzen.
Update is er nog niet. Ik denk vanavond pas.
Hmmm, ik denk dat mijn Samsung S20 hier niet meer voor gepatcht wordt.
De S20 is sinds eergisteren niet meer ondersteund.

De bug zit in de kernel, dus ook een Google Play systeem-update gaat hier helaas niet meer bij helpen (wat nog wel eens kwetsbaarheden oplost bij niet-ondersteunde toestellen). Bovendien doen fabrikanten er langer over om kernels te patchen.

Dat gezegd hebbende: de CVE en patch komen van vorig jaar, de kans bestaat dat Samsung de update al eerder heeft meegenomen dan Google. De patchlijst van Samsung (hier samengevat) bevat de CVE wel. Misschien dat je nog geluk hebt met een allerlaatste update?
Ik heb op 7 april de laatste update ontvangen met de beveiligingspatches van 1 maart 2025. Dus de kwetsbaarheid is niet verholpen.
Dat is sowieso het probleem van gelockte apparaten waar je afhankelijk bent van de fabrikant voor updates. Een S20 is een prima telefoon die nog jaren meekan, maar je moet hem in principe weggooien omdat de fabrikant geen zin meer heeft in updates.
security updates zouden los moeten staan van grotere updates. En dat is het voor een stuk ook al, die lopen via de playstore. Wel, via de play system. Ik gok, dat je wel een zekere android versie moet hebben.

[Reactie gewijzigd door Yoshi op 10 april 2025 08:56]

Maar een klein deel van de security fixes gaan via de Play System update. Deze maand zijn dat er maar 3 van de 28:
https://source.android.com/docs/security/bulletin/2025-04-01
(En dan tel ik de kernel/firmware updates niet eens mee.)
De kernel kan je helaas niet via Play updaten. Dingen als het Bluetooth-subsysteem en de ART-runtime dan weer wel.

Gebrek aan updates door fabrikanten is wel de reden dat Google steeds meer dingen naar zichzelf toetrekt. Afhankelijk van hoeveel fabrikanten dit meenemen, is dat misschien maar beter ook.
Mee eens. De hardware kan nog perfect mee maar door gebrek aan support van de leveranciers heb je een onbruikbaar apparaat. Een custom firmware kunnen installeren zou dan een optie zijn, maar door zo'n lock kun je die niet installeren. Zo heb je ook de optie om een veiligere firmware te gebruiken, mocht die er zijn.
In dat geval krijg je nog steeds geen device specific firmware updates. Een 3rd party rom kan die ook niet aanbieden als de betreffende fabrikanten die niet leveren. Dan kunnen 3rd party roms alleen security updates voor Android zelf en eventueel de Linux kernel aanbieden. (En vaak doen 3rd party roms het voor device specific firmware niet eens als die er wel is, omdat het veel werk is om dat per telefoon te doen. Soms kan je die dan wel zelf bij de fabrikant downloaden. Ik kon bijvoorbeeld vroeger een Poco met Lineage updaten voor de Android security fixes en dan los nog de device firmware bij Poco downloaden en installeren via sideloading.
Dus je krijgt een lijst van bijvoorbeeld 6 configuraties en door configuratie nummer 7 op te vragen kun je gedeelten van het geheugen lezen waar je normaal niet bij moet kunnen?

En dit is op alle Linux apparatuur met dezelfde kernel? Niet alleen op Android?
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usb_get_configuration for allocating dev->config. This can lead to out-of-bounds accesses later, e.g. in usb_destroy_configuration.
Ik vind het mega slim dat dit soort dingen uberhaupt gevonden wordt
Er zijn over de hele wereld enorm veel mensen dagelijks op zoek naar dit soort exploits. Het is niet voor niets dat bedrijven zoals Apple en Google hier geld voor geven. Bedrijven zoals Cellebrite geven echter makkelijk het 10-voudige voor bepaalde exploits, aangezien dit soort exploits noodzakelijk zijn voor hun business model.
Ik denk dat als je AI loslaat op de sources van de kernel, je waarschijnlijk nog meer van dit soort lekken kunt vinden. Dan moet je per lek gaan bekijken of het de gebruiken is om toegang te krijgen. Persoonlijk vind ik het ontbreken van input validatie, waar hier dus sprake van lijkt te zijn, wel een basale beginnersfout. Maar het zou ook zo kunnen zijn dat dit bewust geïntroduceerd is.
Ja, alhoewel, zo'n out-of-bounds dingetjes zijn wel echt de meest simpele/voorkomende fouten.

D'r zijn veel interessantere voorbeelden te verzinnen, vooral workarounds voor kopieerbeveiligingen op consoles zijn interessante videos.

Op dit item kan niet meer gereageerd worden.