Google-onderzoeker haalt uit naar Android: updates sneller naar gebruikers
Een bekende onderzoeker van Google heeft uitgehaald naar het Android-ecosysteem, omdat beveiligingsupdates niet snel genoeg onder gebruikers worden uitgerold en die zo via bekende kwetsbaarheden kunnen worden aangevallen. De enige bescherming is dan het niet meer gebruiken van de Androidtelefoon, zo stelt Maddie Stone, beveiligingsonderzoeker van Googles Threat Analysis Group (TAG). Deze groep houdt zich bezig met het bestrijden van door overheden gesponsorde en uitgevoerde aanvallen tegen Google en diens gebruikers.
Elk jaar maakt het TAG-team een overzicht van waargenomen zerodaylekken. Het gaat hierbij om actief misbruikte kwetsbaarheden waar nog geen update van de leverancier voor beschikbaar is. Vorig jaar telde het TAG-team 41 zerodaylekken, een daling ten opzichte van 2021, toen het nog om 69 van dergelijke kwetsbaarheden ging. Omdat er geen patches beschikbaar zijn, zijn zerodays zeer effectief.
In het geval van Android blijken bekende bekende kwetsbaarheden waarvoor patches beschikbaar zijn ook als zerodays te fungeren, omdat de betreffende updates niet onder gebruikers zijn uitgerold. "De enige bescherming voor gebruikers is dan het toestel niet meer te gebruiken", stelt Stone. Ze noemt als voorbeeld een kwetsbaarheid in de kerneldriver van de ARM Mali GPU waar Androidtelefoons gebruik van maken.
Het beveiligingslek werd vorig jaar juli door een externe onderzoeker bij het Android Security Team gemeld. In augustus 2022 liet het Android Security Team weten dat het probleem niet zou worden verholpen, omdat het "apparaatspecifiek" was. ARM kwam vervolgens in oktober met een eigen update. Afgelopen november bleek dat aanvallers actief misbruik van de kwetsbaarheid maakten. In april van dit jaar besloot Android pas om de ARM-patch onderdeel van de Android-updates te maken. En zo zijn er nog meer voorbeelden, aldus Stone. Een andere ARM-patch voor een actief aangevallen kwetsbaarheid werd pas na 17 maanden door Android toegevoegd.
Onvolledige patches
Een ander probleem dat Stone benoemt is de kwaliteit van de beveiligingsupdates die leveranciers uitbrengen. Van de 41 zerodaylekken die vorig jaar werden waargenomen waren er 17 een variant van eerder gevonden kwetsbaarheden. Volgens Stone is het dan ook belangrijk dat leveranciers en ontwikkelaars naar de werkelijke oorzaak van een beveiligingslek kijken en niet alleen de manier verhelpen waarop aanvallers er in dat specifieke geval misbruik van maken.
Terugblikkend op vorig jaar concludeert Stone dat updates sneller onder gebruikers moeten worden uitgerold, zodat die zichzelf kunnen beschermen. Moeten leveranciers meer details over zerodaylekken delen zodat hiervan kan worden geleerd en moet de kwaliteit van de patches beter, zodat de werkelijke hoofdoorzaak wordt weggenomen.
Google verwijst door naar de fabrikanten en telco's.
Voor hen is het alleen maar een kostenpost, dus lage prio.
Van de overheid heb je ook weinig te verwachten, want die vindt die kwetsbaarheden maar wat fijn voor de "Staatsveiligheid".
Dan kunnen politie & veilgheidsdiensten namelijk makkelijker meekijken op die toestellen.
En zo worden de gebruikers overgelaten aan de fijne nukken van "de markt".
Eerst moet er een grote ramp gebeuren, voordat politici en bedrijfsleven werkelijk in beweging gaan komen om eigenaarschap van dit probleem op te eisen en het permanent te fixen.
Laten ze dat ook maar eens aanpakken.
Inmiddels is dit alweer Android 13.na een update.
Kreeg van de week de laatste beveiliging updates juli van google binnen.
Denk dat mij volgende toestel een Nokia is. Dat werkt dan allemaal uitstekend daar.
Google zou eigenlijk gewoon zijn security updates moeten afdwingen tenzij opt out.
Fabrikanten hebben bij 9 van de 10 updates geen last van zo'n security update.
Ook vind ik het waardeloos dat je bij Android 2 soorten updates hebt.
1. Systeemupdate / security updates
2. Google Play Security updates
3. App Updates
Geen van alle werkt Automatisch (als zeggen ze soms van wel)
Maar ja bij oude toestellen soms werken nieuwere versies van Android niet meer,mogelijk doordat de chipset dan te veel verouderd is.
Eigenlijk zou google het principe van Apple moeten hebben,dat je minstens voor vijf jaar systeemupdates zou moeten hebben.
Dat zou toch wel mogelijk moeten zijn.
Waarom lukt het met het Apple ecosysteem wel?,en met andere fabrikanten dus niet met een type chipset?.
Laten ze dat ook maar eens aanpakken.
Tot nog toe is Graphene OS de enige die ik snel en vaak met updates in de wwer zie. Ongeveer 30 per jaar.
Laten ze dat ook maar eens aanpakken.
Tot nog toe is Graphene OS de enige die ik snel en vaak met updates in de wwer zie. Ongeveer 30 per jaar.
Graphene is leuk maar de ondersteuning in de praktijk is best kort. Mogelijk korter dan de ondersteuning van Google zelf.
Graphene volgt AOSP. De Pixel 4 series (van 2020??) is over een paar maanden End-of-life. Dus 3 jaar aan updates. Dit is hetzelfde als iedere Samsung , Nokia enzovoort, best slecht eigenlijk - misschien dat ze het nog even verlengen zoals met de Pixel 2 maar in de Pixel 2-3 tijd kwam er niet elk jaar een nieuwe Pixel uit....
Best slecht dus , je zou verwachten dat custom roms je langer ondersteuning geven. Zo had ik met Cyanogenmod een Galaxy S2 uit het jaar huifkar die 8 jaar later gewoon een recente kernel had....
Graphene dwingt dus tot elke 3 jaar je toestel vervangen hoe frequenter Pixels gereleased worden en je weet nooit wat er op chipniveau in de silicone gestopt wordt door Google/Alphabet/NSA/Aylmao.. ze zien de userbase van Graphene ook groeien dus het zal me niet verbazen dat de Pixels vanaf 7 of 8 een paar "foutjes" in de Tensor chip hebben of in de AI chip, bijvoorbeeld in de videobewerking van de CPU , waardoor met een filmpje jouw toestel geroot word op afstand , ongeacht welke app jij gebruikt om je video te bekijken
Hier kunnen geen softwarematige jails of selinux policies tegenop namelijk......
Het probleem van Graphene is dat het een soort eenmans projectje is en je weet nooit hoe lang dat goed blijft gaan, ik zou me er niet afhankelijk van maken
Het zou die Daniel McKay sieren om zich niet zo afhankelijk te maken van de Titan M-series chip maar dit een keuze te maken, zodat mensen ook Graphene kunnen installeren op bijvoorbeeld een FairPhone...
Daarbij zijn alle Graphene toestellen dezelfde binary blobs (stuk of 5 ) en dezelfde symbols , dus zo moeilijk is het niet voor een exploit dev om de juiste return adressen te vinden voor een exploit, de enige obstacels zijn de memory management van Mckay en de sandbox maar de symboltable heb je in elk geval al.. je hoeft maar 1 ketenfout te vinden bij de compiler code optimizations in combinatie met ........ en dan ben je 1 jailbreak en 1 zeroday verwijderd van een hack
Het beste compile je Graphene project dus zelf , dan krijg je geen OTA updates want die hashes kloppen niet maar je hebt wel unieke code , het liefst sloop je de Titan afhankelijkheid eruit dan kun je Graphene op elk toestel draaien, want zeg nou eens eerlijk... de crc hash over de ROM van je toestel kun je toch ook visueel inspecteren , als je opstart zie je de string namelijk...
Eerlijk gezegd denk ik dat de toekomst niets van dit is, niets van Android maar Linux telefoons (misschien daarna BSD? want Linux kernel is default ook erg zwak qua security..het is wel stabiel maar niet secure ) gebaseerd op een XEN kernel
Je weet het gewoon niet met die custom silicons van google, wil je ze echt vertrouwen? Ik denk dat er best wel eens een hardware side channel attack in kan zitten... ik pik trouwens ook een RF signatuur op zodra ik de pixel aanzet en nog voor het laden van het OS zend de Pixel (ook vorige generaties) een specifiek signaal uit als een soort "init" op de radio chip , hij maakt welliswaar geen contact met zendmasten op een hoger OSI level maar gewoon een subtiele RF 'ping' zodra de radio module stroom krijgt
Ik vind het 1 toestel waar iedereen in de ITsec community gebruik van maakt een valkuil.......
Precies waar de NSA ons wil hebben
1 blackberry voor iedere crimineel :)
Tijd om Graphene te slopen los van de Titan chip en te porten voor generiek AOSP gebruik bijv Fairphone of voor 1 generieke chipset bijv de Qualcomm SoC
De "hardware verificatie" zou je nog altijd kunnen doen met een hardware key
Maar dan hoef je niet elke 3 jaar een nieuwe Google telefoon te kopen vanwege 1 dev zijn pipedream dat de Titan chip zijn cryptografische endlosing zou zijn, wat de pixel eigenlijk tot een linuxhackerspeeltje maakt, helaas
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
