Stagefright is een van de ergste exploits die Android de afgelopen tijd heeft gezien. Klik om meer te lezen over de details en hoe u uzelf kunt beschermen!
Een van de sterkste punten van Android is vooral het open source-karakter ervan, waardoor belanghebbenden het besturingssysteem kunnen splitsen, aanpassen en herdistribueren op een manier die past bij hun specifieke behoeften. Maar juist dit voordeel van open source werkt als een tweesnijdend zwaard als het gaat om malware en beveiliging. Het is gemakkelijker om fouten te vinden en te herstellen als je veel bekwame bijdragers hebt aan een project waarvan de broncode vrij beschikbaar is. Het oplossen van het probleem op bronniveau vertaalt zich echter niet vaak in het oplossen van het probleem in de handen van de eindgebruiker. Als zodanig is Android niet de eerste keuze als het gaat om het kiezen van een besturingssysteem voor gegevensgevoelige bedrijfsbehoeften.
Op Google I/O 2014 gaf Google zijn eerste impuls aan een veiliger en ondernemingsvriendelijker ecosysteem met de lancering van de
Het streven naar een veilig Android is niet geheel het werk van Google, aangezien Samsung hierin via zijn bedrijf een vrij belangrijke rol heeft gespeeld KNOX-bijdragen aan AOSP, die uiteindelijk versterkt Android For Work. Recente beveiligingslekken en kwetsbaarheden in Android wijzen echter op een zware opgave als het gaat om de populariteit voor bedrijfsadoptie. Een voorbeeld hiervan is de recente Stagefright-kwetsbaarheid.
Inhoud:
- Wat is Stagefright?
- Hoe serieus is Stagefright?
- Wat maakt Stagefright anders dan andere ‘enorme kwetsbaarheden’?
- Het update-dilemma
- Android, Post-plankenkoorts
- Slotnotities
Wat is Stagefright?
Simpel gezegd is Stagefright een exploit die gebruik maakt van de codebibliotheek voor het afspelen van media op Android genaamd lib plankenkoorts. De libstagefright-engine wordt gebruikt om code uit te voeren die wordt ontvangen in de vorm van een kwaadaardige video via MMS, waardoor alleen het mobiele nummer van het slachtoffer nodig is om een succesvolle aanval uit te voeren.
We hebben contact opgenomen met onze interne expert, XDA Senior Recognized Developer en Developer Admin pulser_g2 om een meer gedetailleerde uitleg te geven.
"Terwijl ik dit schrijf, zou de exploit [Stagefright] worden uitgelegd bij BlackHat [Koppeling], hoewel er nog geen dia's of whitepaper-details beschikbaar zijn.
Ik geef deze uitleg daarom meer als een ruw idee van wat er aan de hand is, dan als een zeer diepgaande uitleg met volledige nauwkeurigheid enz.
Stagefright bestaat uit een aantal verschillende bugs, en deze hebben hun eigen CVE [Veelvoorkomende kwetsbaarheden en blootstellingen] nummers voor tracking:
- CVE-2015-1538
- CVE-2015-1539
- CVE-2015-3824
- CVE-2015-3826
- CVE-2015-3827
- CVE-2015-3828
- CVE-2015-3829
Helaas zijn de beschikbare patches niet direct aan elke CVE gekoppeld (zoals dat wel het geval zou moeten zijn), dus dit zal een beetje rommelig zijn om uit te leggen.
1. [CVE-2015-1538]
In de MPEG4-verwerkingscode bevatten de 3GPP-metadata (de dingen die het formaat en andere extra informatie beschrijven, wanneer een video in 3GPP-formaat is) fouten. Het heeft metadata niet afgewezen als de gegevens buitensporig groot waren, maar controleerde alleen of deze te klein waren. Dit betekende dat het voor een aanvaller mogelijk was om een "gewijzigd" of "beschadigd" bestand te maken, dat een langer metadatagedeelte zou hebben dan zou moeten.
Een van de grote uitdagingen bij het schrijven van code voor het verwerken van "niet-vertrouwde" gegevens (dat wil zeggen van een gebruiker of van een andere plaats buiten uw code) is het verwerken van gegevens met variabele lengte. Video’s zijn hier een perfect voorbeeld van. De software moet geheugen dynamisch toewijzen, afhankelijk van wat er aan de hand is.
In dit geval wordt er een buffer gemaakt als verwijzing naar een bepaald geheugen, maar de lengte van de array waarnaar deze verwijst, was één element te kort. De metagegevens werden vervolgens in deze array ingelezen en het was mogelijk om de laatste invoer in deze array niet "null" (of nul) te laten zijn. Het is belangrijk dat het laatste item in de array nul is, omdat de software zo vertelt dat de array klaar is. Door de laatste waarde niet nul te kunnen maken (aangezien de array mogelijk één element te klein was), kon de kwaadaardige code door een ander deel van de code worden gelezen en te veel gegevens worden ingelezen. In plaats van te stoppen aan het einde van deze waarde, kan het programma doorgaan met het inlezen van andere gegevens die het niet zou moeten lezen.
(Zie: OmniROM Gerrit)
2. [CVE-2015-1539]
De kortst mogelijke "grootte" van de metadata moet 6 bytes zijn, omdat het een UTF-16-string is. De code neemt de gehele waardegrootte en trekt er 6 van af. Als deze waarde minder dan 6 zou zijn, zou de aftrekking "onderlopen" en rondlopen, en zouden we eindigen met een heel groot getal. Stel je voor dat je bijvoorbeeld alleen maar van 0 tot 65535 kunt tellen. Als je het getal 4 neemt en er 6 van aftrekt, kun je niet onder nul komen. Dus je gaat terug naar 65535 en telt vanaf daar. Dat is wat hier gebeurt!
Als een lengte van minder dan 6 wordt ontvangen, kan dit ertoe leiden dat frames onjuist worden gedecodeerd, aangezien de byteswap-proces gebruikt de variabele len16, waarvan de waarde wordt verkregen uit een berekening die begint met (maat-6). Dit zou ertoe kunnen leiden dat er een veel grotere wisseloperatie plaatsvindt dan de bedoeling was, waardoor de waarden in de framegegevens op een onverwachte manier zouden veranderen.
(Zie: OmniROM Gerrit)
3. [CVE-2015-3824]
Een biggie! Deze is smerig. Er is precies het tegenovergestelde van dit laatste probleem: een overflow van gehele getallen, waarbij een geheel getal "te groot" kan worden. Als je bijvoorbeeld 65535 bereikt en niet hoger kunt tellen, rol je rond en ga je vervolgens naar 0!
Als je op basis hiervan geheugen toewijst (wat Stagefright doet!), zou je uiteindelijk veel te weinig geheugen toegewezen krijgen in de array. Wanneer er gegevens in werden gestopt, zou het mogelijk niet-gerelateerde gegevens overschrijven met gegevens die de kwaadwillende bestandsmaker beheerde.
(Zie: OmniROM Gerrit)
4. [CVE-2015-3826]
Nog een vervelende! Zeer vergelijkbaar met de vorige - nog een overflow van gehele getallen, waarbij een array (gebruikt als buffer) te klein zou worden gemaakt. Hierdoor zou niet-gerelateerd geheugen kunnen worden overschreven, wat opnieuw slecht is. Iemand die gegevens in het geheugen kan schrijven, kan andere gegevens beschadigen die niets met elkaar te maken hebben, en deze mogelijk gebruiken om een door hem beheerde code door uw telefoon te laten uitvoeren.
(Zie: OmniROM Gerrit)
5. [CVE-2015-3827]
Vrij gelijkaardig aan deze laatste. Er wordt een variabele gebruikt bij het overslaan van een bepaald geheugen, en dit kan tijdens het aftrekken negatief worden gemaakt (zoals hierboven). Dit zou resulteren in een zeer grote "skip"-lengte, waardoor een buffer overloopt, waardoor toegang wordt verkregen tot geheugen waartoe geen toegang zou moeten worden verkregen.
(Zie: OmniROM Gerrit)
Er zijn ook enkele (potentieel) gerelateerde oplossingen die ook in [Android] 5.1 lijken te zijn opgenomen.
(Zie: OmniROM Gerrit)
Dit voegt controles toe om problemen met een eerdere beveiligingsoplossing te stoppen en grenscontroles toe te voegen, die op zichzelf kunnen worden overschreden. In C worden getallen die kunnen worden weergegeven als een ondertekende int opgeslagen als een ondertekende int. Anders blijven ze tijdens de werkzaamheden ongewijzigd. Bij deze controles hadden sommige gehele getallen ondertekend kunnen zijn (in plaats van niet-ondertekend), waardoor hun maximale waarde later zou afnemen en er een overflow zou kunnen plaatsvinden.
(Zie: OmniROM Gerrit)
Nog wat onderstroom van gehele getallen (waarbij de getallen te laag zijn en vervolgens op die getallen wordt afgetrokken, waardoor ze negatief kunnen worden). Dit leidt opnieuw tot een groot aantal in plaats van een klein aantal, en dat veroorzaakt dezelfde problemen als hierboven.
(Zie: OmniROM Gerrit)
En tot slot nog een overflow van gehele getallen. Hetzelfde als voorheen, het staat op het punt om elders te worden gebruikt en het kan overstromen.
(Zie: OmniROM Gerrit)"
Hoe serieus is Stagefright?
Volgens de blogpost gepubliceerd door het moederonderzoeksbedrijf, Zimperium Research Labs, legt de Stagefright-exploit mogelijk bloot 95% van de Android-apparaten (ongeveer 950 miljoen) heeft last van dit beveiligingslek, aangezien het apparaten met Android 2.2 en omhoog. Tot overmaat van ramp lopen apparaten ouder dan Jelly Bean 4.3 het “grootste risico”, omdat deze geen adequate maatregelen tegen deze exploit bieden.
Met betrekking tot de schade die Stagefright zou kunnen aanrichten, merkte pulser_g2 op:
[blockquoteauthor="pulser_g2"]"Op zichzelf zou Stagefright toegang geven aan de systeemgebruiker aan de telefoon. Je zou ASLR (address space layout randomization) moeten omzeilen om er daadwerkelijk misbruik van te kunnen maken. Of dit is gelukt, is op dit moment nog niet bekend. Met deze exploit kan "willekeurige code" op uw apparaat als systeem- of mediagebruiker worden uitgevoerd. Deze hebben toegang tot de audio en camera op het apparaat, en de systeemgebruiker is een geweldige plek om een root-exploit te starten. Weet je nog alle geweldige root-exploits die je gebruikte om je telefoon te rooten?
Deze kunnen mogelijk in stilte worden gebruikt om root op uw apparaat te krijgen! Wie root heeft, is eigenaar van de telefoon. Ze zouden SELinux moeten omzeilen, maar TowelRoot is daarin geslaagd, en PingPong is daar ook in geslaagd. Zodra ze root zijn, staat alles op je telefoon voor hen open. Berichten, sleutels, enz."[/blockquote]
Over worstcasescenario's gesproken: er is alleen een MMS nodig om code te leveren en deze exploit te activeren. De gebruiker hoeft het bericht niet eens te openen omdat veel berichtenapps MMS vooraf verwerken voordat de gebruiker ermee communiceert. Dit verschilt van spear-phishing-aanvallen, omdat de gebruiker zich totaal niet bewust kan zijn van een succesvolle aanval, waarbij alle huidige en toekomstige gegevens in de telefoon in gevaar komen.
Wat maakt Stagefright anders dan andere “enorme kwetsbaarheden”?
"Alle kwetsbaarheden vormen een risico voor gebruikers. Deze is bijzonder riskant, want als iemand een manier vindt om deze op afstand aan te vallen (dat wil zeggen Als er een manier om ASLR wordt gevonden), kan deze worden geactiveerd voordat u zich realiseert dat u onder de maat bent aanval"
Oudere exploits zoals Android Installer Hijacking, FakeID en root-exploits zoals TowelRoot en PingPong vereisen op een gegeven moment gebruikersinteractie om te worden uitgevoerd. Hoewel het nog steeds ‘exploits’ zijn in de zin dat er bij kwaadwillig gebruik veel schade kan ontstaan, blijft het een feit dat Stagefright heeft in theorie alleen het mobiele nummer van een slachtoffer nodig om van zijn telefoon een trojan te maken en krijgt daarom de laatste tijd zoveel aandacht dagen.
Android is echter niet helemaal overgeleverd aan deze exploit. Hoofdingenieur van Android-beveiliging, Adrian Ludwig, heeft enkele problemen besproken in een Google+ bericht:
[blockquote auteur="Adrian Ludwig"]"Er bestaat een algemene, onjuiste veronderstelling dat elke softwarefout kan worden omgezet in een beveiligingsexploit. In feite zijn de meeste bugs niet te misbruiken en er zijn veel dingen die Android heeft gedaan om die kansen te verbeteren...
Er wordt een lijst weergegeven met enkele van de technologieën die zijn geïntroduceerd sinds Ice Cream Sandwich (Android 4.0). hier. De meest bekende hiervan is Address Space Layout Randomization (ASLR), die volledig is voltooid in Android 4.1 met ondersteuning voor PIE (Position Independent Executables) en is nu op meer dan 85% van Android apparaten. Deze technologie maakt het voor een aanvaller moeilijker om de locatie van de code te raden, wat nodig is om een succesvolle exploit te bouwen...
We zijn niet gestopt met ASLR, we hebben ook NX, FortifySource, Read-Only-Relocations, Stack Canaries en meer toegevoegd."[/blockquote]
Het valt echter nog steeds niet te ontkennen dat Stagefright een serieuze zaak is voor de toekomst van Android, en als zodanig serieus wordt genomen door de betrokken stakeholders. Stagefright benadrukte ook de witte olifanten in de kamer: het probleem van fragmentatie en van updates die uiteindelijk de consument bereiken.
Het update-dilemma
Over updates gesproken: het is goed om te zien dat OEM’s de verantwoordelijkheid nemen voor de veiligheid van gebruikers, zoals velen hebben beloofd het updateproces verbeteren, specifiek voor het opnemen van beveiligingsoplossingen en patches voor exploits zoals Stagefright.
Google is een van de eersten die een officiële verklaring heeft vrijgegeven maandelijkse beveiligingsupdates (naast de geplande OS- en platformupdates) voor de meeste Nexus-apparaten, waaronder de bijna drie jaar oude Nexus 4. Samsung heeft dit voorbeeld ook gevolgd door aan te kondigen dat het met vervoerders en partners zal samenwerken om een maandelijks beveiligingsupdateprogramma maar het slaagde er niet in de apparaten en tijdlijndetails van deze implementatie te specificeren. Dit is interessant omdat er sprake is van een ‘fast track’-aanpak van beveiligingsupdates in samenwerking met vervoerders, zodat we dat kunnen verwacht frequentere updates (hoewel op beveiliging gebaseerd, maar hopelijk versnelt dit ook firmware-upgrades) op de provider apparaten.
Andere OEM's die zich bij het pakket aansluiten, zijn onder meer LG, die mee zal doen maandelijkse beveiligingsupdates. Motorola heeft ook de lijst met apparaten die zullen worden bijgewerkt met Stagefright-oplossingen, en de lijst bevat bijna alle apparaten die het bedrijf sinds 2013 heeft gemaakt. Sony heeft dat ook gezegd zijn apparaten zullen binnenkort de patches ontvangen te.
Voor één keer komen ook vervoerders met updates. Sprinten heeft een verklaring afgegeven dat sommige apparaten de Stagefright-patch al hebben ontvangen, en dat er nog meer apparaten op de planning staan voor de update. AT&T heeft ook dit voorbeeld gevolgd door de patch op sommige apparaten uit te geven. Verizon heeft ook patches uitgebracht, al is dit een langzame uitrol waarbij prioriteit wordt gegeven aan high-end smartphones zoals de Galaxy S6 Edge en Note 4. Ook de T-Mobile Note 4 kreeg een Stagefright patchupdate.
Als eindgebruiker zijn er enkele voorzorgsmaatregelen die u kunt nemen om de kans dat u wordt aangevallen te verkleinen. Schakel om te beginnen het automatisch ophalen van MMS-berichten uit in de berichten-apps op uw telefoon. Dit zou de gevallen onder controle moeten houden waarin geen gebruikersinteractie nodig was om de exploit te laten werken. Zorg er hierna voor dat u geen media downloadt van MMS-berichten van onbekende en niet-vertrouwde bronnen.
Als XDA-hoofdgebruiker kunt u dat ook breng wijzigingen aan in uw build-prop om Stagefright uit te schakelen. Dit is geen volledige en zekere manier om jezelf te redden van Stagefright, maar je kunt je kansen wagen om de kans op een succesvolle aanval te verkleinen als je vastzit aan een oudere Android-build. Er zijn ook aangepaste ROM-oplossingen, waarvan de meeste bronnen regelmatig synchroniseren met AOSP en daarom de Stagefright-fixes bevatten. Als u een op AOSP gebaseerde rom gebruikt, wordt het ten zeerste aanbevolen om te updaten naar een nieuwere versie van de ROM die de Stagefright-patches bevat. Je kunt gebruiken deze app om te controleren of uw huidige dagelijkse bestuurder getroffen is door Stagefright.
Android, Post-plankenkoorts
Stagefright is niets anders geweest dan een wake-up call richting Android en het probleem van fragmentatie en updates. Het benadrukt dat er geen duidelijk mechanisme bestaat waarmee dergelijke kritieke oplossingen tijdig op talloze apparaten kunnen worden uitgerold. Terwijl OEM's patches voor apparaten proberen uit te rollen, is de harde waarheid dat de meeste van deze oplossingen beperkt zullen blijven tot recente vlaggenschepen. Andere niet-vlaggenschepen en oudere apparaten, en nog minder van kleinere OEM's, zullen blootgesteld blijven aan bijvoorbeeld Stagefright.
Er zit een zilveren randje aan deze exploit: Het vestigde opnieuw de aandacht op het updateproces van Android en plaatste het in een licht dat niet zoveel toekomstige bedrijven ertoe zal aanzetten Android voor zakelijk gebruik te adopteren. Terwijl Google werkt aan een grotere adoptie door bedrijven, zal het gedwongen worden zijn updatestrategie en de mate van controle die het OEM's biedt, te heroverwegen.
Nu Android M met de dag dichter bij de marktintroductie komt, zou het geen verrassing zijn als Google ervoor zou kiezen om steeds meer componenten van AOSP af te schaffen ten gunste van zijn Play-servicespakket. Dat is tenslotte een gebied waarover Google nog steeds de volledige controle behoudt als een apparaat met de Google Play Store wordt geleverd. Dit heeft zijn eigen nadelen in de vorm van het vervangen van open source-gebieden door close-source muren.
Bij het speculeren over de toekomst van Android bestaat er een (zeer kleine) mogelijkheid dat Google ook de wijzigingen beperkt die OEM’s aan AOSP kunnen aanbrengen. Met de RRO-framework Omdat Google in functionele staat aanwezig is in Android M, zou Google OEM's kunnen beperken om alleen cosmetische wijzigingen aan te brengen in de vorm van RRO-skins. Dit zou een snellere implementatie van updates mogelijk moeten maken, maar zou ten koste gaan van het feit dat OEM’s de mogelijkheid wordt ontzegd om Android volledig aan te passen.
Een andere route die mogelijk tot de mogelijkheden behoort, is om dit verplicht te stellen voor alle apparaten die worden verzonden Google Play Store om gegarandeerde beveiligingsupdates te ontvangen voor een vaste periode, mogelijk twee jaar. Het Play Services-framework zou kunnen worden gebruikt om te controleren op de aanwezigheid van belangrijke beveiligingsupdates en patches, waarbij de toegang tot de Play Store wordt ingetrokken in geval van niet-naleving.
Slotnotities
Dit is op zijn best nog steeds speculatie, omdat er geen elegante manier is om dit probleem op te lossen. Afgezien van een zeer totalitaire aanpak zullen er altijd tekortkomingen zijn in de reikwijdte van oplossingen. Vanwege het enorme aantal Android-apparaten dat er is, zou het bijhouden van de status van de beveiliging van elk apparaat een zeer gigantische taak zijn. De noodzaak van dit uur is een heroverweging van de manier waarop Android wordt bijgewerkt, aangezien de huidige manier zeker niet de beste is. Wij bij XDA Developers hopen dat Android nog steeds trouw blijft aan zijn Open-Source-roots, terwijl we samenwerken met de closed source-plannen van Google.
Is jouw telefoon kwetsbaar voor Stagefright? Denk je dat jouw telefoon ooit een Stagefright-patch krijgt? Laat het ons weten in de reacties hieronder!