Android 16 krijgt mogelijk functie om aanvallen via USB-poort tegen te gaan

Android 16 krijgt mogelijk een functie om aanvallen via de USB-poort tegen te gaan. Het gaat dan om aanvallen met bijvoorbeeld een USB-stick met daarop een virus. De functie werkt alleen in de Advanced Protection-modus en dus niet voor alle Android-gebruikers.

Android Authority zegt in de code van een Android 16-bèta verwijzingen te hebben gevonden naar een functie die de USB-poort van een vergrendelde Android-telefoon softwarematig uitschakelt. De USB-poort kan dan alleen gebruikt worden voor het opladen van de telefoon en er wordt geen dataverbinding opgestart. Deze functie moet malware tegengaan die via de USB-poort van een Android-telefoon op de smartphone wordt geplaatst. Amnesty International waarschuwde eerder voor een zerodayexploit die werkte met de USB-C-poort van de Android-telefoon van een Servische activist.

In onderstaande video laat Android Authority zien dat de functie voorkomt dat er een dataverbinding wordt opgestart als de telefoon vergrendeld is. De smartphone geeft dan de melding dat het toestel ontgrendeld moet worden en de USB-kabel opnieuw in de telefoon gestopt moet worden.

De functie wordt vermoedelijk onderdeel van de Advanced Protection-modus, een nieuwe functie van Android 16. Deze is voornamelijk bedoeld voor gebruikers die een groter risico lopen om gehackt te worden, zoals journalisten en politici. Deze gebruikers moeten de modus zelf inschakelen, die dan onder meer 2G-verbindingen blokkeert en MTE aanzet. Dit is een functie die helpt voorkomen dat kwetsbaarheden met het geheugen worden misbruikt.

Door Hayte Hugo

Redacteur

28-04-2025 • 19:53

42

Submitter: TheVivaldi

Reacties (42)

42
41
24
2
0
13
Wijzig sortering
Toevallig kwam ik dit tegen: https://www.security.nl/p...hones+en+Androidtelefoons
Onderzoekers hebben een methode ontdekt om de 'JuiceJacking' bescherming van iPhones en Androidtelefoons te omzeilen en door middel van een nieuwe aanval genaamd ChoiceJacking toegang tot gevoelige bestanden op toestellen te krijgen. Apple, Google en fabrikanten van Androidtelefoons zijn over het probleem ingelicht en werken aan oplossingen of hebben die inmiddels uitgerold. Dat laten onderzoekers van de Graz University of Technology in hun rapport weten (pdf).
https://graz.elsevierpure...s-through-malicious-charg

Lijkt mij dus wel dat Android 16 ook bescherming biedt tegen dit lek.
Toevallig kwam ik dit tegen: https://www.security.nl/p...hones+en+Androidtelefoons


[...]


https://graz.elsevierpure...s-through-malicious-charg

Lijkt mij dus wel dat Android 16 ook bescherming biedt tegen dit lek.
Volgens dit Ars Technica artikel is dat specifieke probleem al in Android 15 opgelost (en in iOS 18), maar werd die fix door o.a. Samsung nog niet geïmplementeerd. Wellicht dat deze oplossing in Android 16 wel door alle fabrikanten omarmd wordt.
In an email, the researchers said that the fixes provided by Apple and Google successfully blunt ChoiceJacking attacks in iPhones, iPads, and Pixel devices. Many Android devices made by other manufacturers, however, remain vulnerable because they have yet to update their devices to Android 15. Other Android devices—most notably those from Samsung running the One UI 7 software interface—don’t implement the new authentication requirement, even when running on Android 15. The omission leaves these models vulnerable to ChoiceJacking.
Klopt, staat ook in de quoted tekst in mijn bericht:
Apple, Google en fabrikanten van Androidtelefoons zijn over het probleem ingelicht en werken aan oplossingen of hebben die inmiddels uitgerold.
Inderdaad, maar ik wilde even toelichten dat dat dus niet over deze fix in Android 16 ging, maar over een eerdere fix in Android 15 (die helaas niet door iedereen werd geïmplementeerd). Al zullen aanvallen van dit type ongetwijfeld ook een rol hebben gespeeld bij het ontwikkelen van deze nieuwe functie. Zowel Android 15 als Android 16 (als iOS 18) zijn overigens wel rijkelijk laat, want over soortgelijke aanvallen lees je al jaren.

Hopelijk wordt de fix nu wel universeel uitgerold, dan zou dit probleem gedicht moeten zijn tegen dat niemand meer een Android-versie ouder dan 16 gebruikt. (lees, over een jaar of 10 :+ )
Het issue is reeds opgelost door Samsung in de update van juli 2024 (CVE-2024-20900).

Terug te vinden op https://security.samsungmobile.com/workScope.smsb

[Reactie gewijzigd door CyberJohn op 28 april 2025 22:25]

Zoals benoemd, terug te vinden via de link, letterlijk de CVE genoemd in het artikel via @thomas_n

https://imgur.com/d8a6qFf

[Reactie gewijzigd door CyberJohn op 28 april 2025 22:29]

Hmm, ook toevallig dan dat het alsnog gefikst is door Samsung.
Hoe is zoiets toevallig? In het artikel staat dat het euvel in juni en juli met de fabrikanten is gedeeld. Samsung brengt een patch uit in Juli 2024.

Zonde dat de auteur van het genoemde artikel niet de moeite heeft genomen om het op te zoeken....
Ik lees vrij regelmatig dat dit soort aanvallen mogelijk zijn en onderzoekers laten altijd knappe proof-of-concepts zien, maar ik heb nog nooit ergens gelezen dat zoiets ook daadwerkelijk "in het wild" voorkomt. Heeft iemand een voorbeeld van dat deze aanval ooit al daadwerkelijk gebruikt is?

Is het misschien gewoon teveel gedoe voor het infecteren van een relatief klein aantal telefoons, vergeleken met het verspreiden van malafide apps o.i.d., waarmee men veel meer slachtoffers tegelijk maakt? Is dit type aanval dan misschien ooit gerapporteerd voor meer gerichte aanvallen, op specifieke individuen?

Verder had dit beveiligingsgat natuurlijk veel eerder gedicht mogen worden, ook als het slechts een theoretisch gevaar is.
Het helpt wel als iemand je telefoon kan afpakken, zoals een mensenrechtenactivist.
Wat je zegt is van dezelfde orde als "ik hoef geen privacy want ik heb niks te verbergen".
Ik was misschien niet helemaal duidelijk. Ik bedoel zeker niet dat ik het niet nodig vind dat dit gedicht wordt. Daarom zei ik ook dat dit beveiligingsgat al veel eerder gedicht had moeten worden. ;)

Mijn vraag was er één uit nieuwsgierigheid, omdat ik zo vaak lees over dit soort theoretische aanvallen, maar nooit iets lees over een praktijkvoorbeeld, was ik benieuwd of er iemand meer wist over of dit soort technieken daadwerkelijk door aanvallers worden ingezet. En zo nee, waarom dan niet.
Waarschijnlijk zijn dit soort aanvallen zodanig complex en “ondetecteerbaar” dat er vast genoeg mensen op deze manier digitaal aangevallen zijn maar het nooit door hebben.

Dus komt het ook niet boven water.
De betreffende o.mg is veel te duur om te gebruiken op een random persoon.
https://shop.hak5.org/products/omg-cable
Ik heb ook nog nooit echt bewijs gezien dat iemand te grazen is genomen door juicejacking.
Hoop verhalen over het gevaar van laden op vliegvelden, stations enzo.
Ik vraag het mij serieus af.
Terecht punt denk ik hoor. En bij alle rubber ducky achtige scripts, die een toetsenbord emuleren, zie je de actie ook op je scherm gebeuren. Het is niet een stealth hack dat je die kabel erin steekt en boem je telefoon is gehackt.
Mooie feature geleend van GrapheneOS.
Of Samsung's OneUI en waarschijnlijk veel andere Android varianten. Base Android loopt op sommige punten toch best wel achter.

Maar het blijft software, een USB dongle/koppelstukje/condoom die de data pins blokkeert zal uiteindelijk beter werken. Maarja dat is een extra stukje hardware wat weer eigen nadelen heeft.

[Reactie gewijzigd door Caayn op 28 april 2025 20:33]

Samsung doet het sinds enige tijd ook standaard. Bloedirritant voor gebruikers van een USB-C naar audiojack verloopjes, want nu moet je dus elke keer die telefoon ontgrendelen als je dat verloopje aansluit - en als je de muziek uit zet gooit hij binnen een paar minuten die connectie er ook weer uit, dus dan moet je eerst je telefoon weer ontgrendelen, dat verloopje uittrekken, terug insteken en dan werkt het pas weer.

Dat was een jaar geleden nog niet zo en ik kom er maar niet achter hoe je dat weer uit kunt zetten - het moet in een recente update aangepast zijn...
Al is het in standaard Android alleen softwarematig, GrapheneOS maakt gebruikt van de mogelijkheden van Pixel telefoons om het ook hardwarematig uit te zetten :)
Hoe zit die precies bij de iPhone, is zo’n aanval via de USB poort ook mogelijk?
Dat is al lang geleden opgelost, je moet soms zelf om te laden via een apparaat eerst je code invoeren.
Als je dat bij een lader krijgt dan is er iets niet ok met die lader ;)
Met USB PowerDelivery vind er wel zeker communicatie plaats.

[Reactie gewijzigd door RobVI op 28 april 2025 21:13]

PD maakt gebruik van een apart Configuration Channel (CC) voor de onderhandelingen. Dit staat volledig los van de verbindingen bedoeld voor USB dataoverdracht (D+/D-, Tx/Rx). Zie ook de pinout van een USB-C aansluiting.
Opladen is onzin, maar voor nagenoeg elke vorm vorm van data overdracht is inderdaad authenticatie nodig.
Geen onzin. Ik laad nagenoeg altijd via mijn computer op.
Als ik een tijdje niet ingelogd ben in m'n iphone en sluit em direct aan op de usb met de bedoeling om te laden dan zal er niets gebeuren. Dit gebeurd pas nadat ik ben ingelogd.

Wanneer ik wel ingelogd was en de iphone heb gelocked en deze binnen enkele minuten aansluit op mijn computer dan pakt ie em wel gelijk. Overigens weet ik niet of dit ook gebeurd met niet-vertrouwde apparaten.

[Reactie gewijzigd door Username3457829 op 29 april 2025 13:55]

Geen onzin. Ik laad nagenoeg altijd via mijn computer op.
Daar heb je het dus al; omdat je een dataverbinding tot stand brengt, is de poort geblokkeerd totdat je inlogt. De iPhone maakt geen onderscheid tussen laden en dataverkeer. Bij enige vorm van dataverkeer is de gehele poort gewoon geblokkeerd.

Gebruik je een doodnormale lader, dan kan ik je garanderen dat je dit 100% zeker niet hebt. ;)
Het is allemaal geen Rocket science.
Jawel, maar dat is niet waar jij op reageert en waar ik vervolgens op reageer he.

Er stond: "Je moet soms zelfs om op te laden via een apparaat.."
Als je meer wilt dan 5V zal er wel iets van communicatie moeten plaats vinden.
Met USB PD communiceren opladers en apparaten met elkaar om ervoor te zorgen dat de juiste hoeveelheid stroom wordt geleverd.
https://www.anker.com/blo...pd-charger-complete-guide
Die hadden nooit USB. :X
Lightning is elektrisch gewoon USB 2 en met een eenvoudige dongle kan je prima USB apparaten inpluggen op een oudere iPhone.
Lightning = USB2 en nu hebben ze USB-C.
Ik kwam de instelling net tegen op mijn galaxy tab a8 van vele jaren oud. Verbazingwekkend dat dit nu al naar vanilla komt.
Benieuwd of er dan ook functionaliteit in zit om een O.MG kabel tegen te werken. Als je onverhoopt zo'n kabel gebruikt en je telefoon ontgrendelt kan die prima je beveiligingsinstellingen wijzigen zonder dat je het doorhebt (of eender welke andere actie ondernemen)
Dit soort aanvallen zijn al een probleem sinds usb gebruikelijk is om opslagmedia aan te koppelen. Dat is al ruim 20 jaar. Het is er niet beter op geworden toen smartphones werden ontworpen om 'handig' via usb te laden. En ook dat is al bijna 15 jaar het geval.

Dit soort simpele bescherming advanced protection noemen terwijl het dus al 20 jaar niet verstandig is om zomaar pogingen om gegevens te verwerken toe te staan? Het lijkt er meer op dat Google 15 jaar geen zin had om het probleem serieus te nemen en miljoenen gebruikers liever risico liet lopen.
Dit zal een Graphenos bijdrage aan AOSP zijn wat google nu ook gaat implementeren.
Ik snap dit gewoon niet. Waarom niet gewoon geen drive mounten of helemaal geen power delivery totdat je consent dmv een popup? (mits ontgrendeld)?

Android wordt steeds vervelender met al die beveiligingslagen.

[Reactie gewijzigd door Marctraider op 29 april 2025 11:41]

Zou graag zien dat deze 'feature' standaard aanstaat. Of eigenlijk beter, wanneer je een data-verbinding wil maken met je telefoon dat je dan juist iets aan moet zetten. Ik kan mijzelf niet herinneren dat ik mijn telefoons met een datakabel aan een PC oid heb gekoppeld.


Om te kunnen reageren moet je ingelogd zijn