StrandHogg 2.0 is een gevaarlijke nieuwe Android-kwetsbaarheid. Hier leest u welke gevolgen dit voor gebruikers kan hebben en hoe ontwikkelaars hun apps ertegen kunnen beschermen.
Het is 22:00 uur. Weet u waar uw activiteiten zijn? Er is een nieuwe kwetsbaarheid die kan worden uitgebuit op miljoenen Android-apparaten, en het is ook een behoorlijk vervelende kwetsbaarheid. In een notendop zorgt deze ontwerpfout ervoor dat een aanvaller zijn eigen activiteit (pagina) bovenop die van een andere app kan presenteren, waardoor de gebruiker mogelijk in de war wordt gebracht en zijn privégegevens weggeeft. De kwetsbaarheid heet StrandHogg 2.0 en is onlangs onthuld door Promon, een Noors beveiligingsbedrijf.
De StrandHogg 2.0-kwetsbaarheid treft theoretisch alle Android-apparaten met Android-versies zo oud als Honeycomb (3.0) en tot Android 9 Pie (9.0). Gebaseerd op de nieuwste distributiestatistieken van de Android-versie, dat betekent dat ongeveer 91,8% van alle Android-apparaten zijn kwetsbaar voor StrandHogg 2.0
. De kwetsbaarheid is toegewezen CVE-2020-0096 en kreeg een ernstniveau van ‘kritiek’. Het vereist geen speciale machtigingen om te werken en kan vrijwel volledig functioneren zonder gebruikersinteractie. Het enige dat een gebruiker hoeft te doen is een app openen waarin kwaadaardige code is verborgen, en dan zijn ze kwetsbaar voor misbruik.Promon was zo vriendelijk om ons hun proof of concept-app en de broncode te sturen, zodat we dit het beste konden doen leg uit hoe de exploit werkt, waarom het belangrijk is voor gebruikers en hoe ontwikkelaars hun apps kunnen beschermen tegen het.
Hoe het werkt
Stel dat u Gmail gebruikt en op een weblink klikt. Als u naar het scherm met uw recente apps gaat, merkt u mogelijk dat de webpagina zich 'in' Gmail bevindt. In het voorbeeld wordt de website weergegeven, maar het app-pictogram en de naam zijn nog steeds afkomstig van Gmail. Dit is iets dat gebeurt wanneer een app/activiteit een andere app/activiteit start in dezelfde taak. Stel je nu voor dat je die link niet met opzet hebt geopend. Voor jou lijkt het erop dat dit slechts een onderdeel is van de Gmail-app. Dit is het gedrag waar StrandHogg 2.0 misbruik van maakt.
We zullen hier wat details moeten weglaten, maar hier is grofweg hoe deze exploit werkt. Laten we voor het volgende aannemen dat de aanvaller de Gmail-inloggegevens van de gebruiker wil achterhalen.
- De gebruiker downloadt een kwaadaardige app (uiteraard zonder te weten dat deze schadelijk is) en opent deze.
- Op de achtergrond opent de app Gmail, plaatst er een vergelijkbare inlogactiviteit bovenop en start vervolgens een andere activiteit.
- De gebruiker opent Gmail en ziet wat lijkt op het inlogscherm van Gmail, maar in werkelijkheid de phishing-activiteit van de aanvaller is.
De laatste activiteit die in stap 2 wordt gelanceerd, kan alles zijn dat argwaan vermijdt. De app kan een crash simuleren en teruggaan naar het startscherm, of hij kan gewoon de hoofdactiviteit openen alsof er niets is gebeurd. Het enige verdachte dat de gebruiker kan zien, zijn een aantal openingsanimaties wanneer alle activiteiten worden gestart. Het ergste: het lijkt er niet eens op dat Gmail is geopend.
Natuurlijk kan een aanvaller meer doen dan alleen een nep-inlogscherm tonen. Een kwaadwillende app kan in plaats daarvan een machtigingsprompt weergeven, waardoor de gebruiker wordt misleid om ongewenste machtigingen te verlenen. Hoewel het aanvragen van speciale machtigingen zoals Toegankelijkheid de gebruiker achterdochtig kan maken, is het mogelijk om veel schade aan te richten met zoiets als Opslagtoegang.
De technische stukjes
Deze volgende sectie is een overzicht op hoog niveau van hoe StrandHogg 2.0 werkt. Promon zal de volledige details pas over een paar maanden vrijgeven, dus we kunnen niet precies delen hoe deze exploit is geïmplementeerd. Er zijn echter enkele technische details waar we over kunnen praten.
In een notendop: StrandHogg 2.0 kaapt Android Context.startActivities() API-methode, met behulp van drie intenties.
- De eerste intentie is degene die, in het geval van ons voorbeeld, Gmail start. Het is gemarkeerd met
Intent.FLAG_ACTIVITY_NEW_TASK. - De tweede bedoeling is de kwaadaardige. In ons voorbeeld is dit de look-alike login-activiteit. Deze intentie heeft geen vlaggen.
- De derde intentie is de afleiding. Het zorgt ervoor dat de gebruiker er niet achterdochtig van wordt dat Gmail zomaar willekeurig wordt geopend in plaats van de app waarop ze hebben getikt (dat wil zeggen degene die de aanval lanceert). Het is gemarkeerd met
Intent.FLAG_ACTIVITY_NEW_TASK.
Al deze intenties worden vervolgens in een array doorgegeven aan de startActivities() methode.
Het ontbreken van vlaggen bij de tweede Intent is hier de sleutel. Door dit te doen hebben we in feite gewoon het Gmail-voorbeeld van hierboven gerepliceerd. Technisch gezien is dit de taak van Gmail, maar de bovenste activiteit is die van de aanvaller. Wanneer de gebruiker vervolgens op het startschermpictogram van Gmail klikt, wordt de activiteit van de aanvaller weergegeven in plaats van die van Gmail.
Bewijs van concept
Met de informatie die Promon ons stuurde, konden we hun proof of concept repliceren. Hier is een schermopname van een Samsung Galaxy Note8 met Android 9 Pie, die hem in actie laat zien.
Mitigatietechnieken en problemen
Het simpelweg repliceren van het bovenstaande in code zal niet echt werken. Het is geen volledig voorbeeld, en er zijn nog een paar andere dingen die een aanvaller moet doen om het te laten werken, die we niet kunnen delen. Maar ze zijn op zichzelf niet bijzonder moeilijk te raden, en dat maakt deze aanval juist zo gevaarlijk. StrandHogg 2.0 is een relatief eenvoudig te implementeren exploit, maar moeilijk te beperken.
Mitigatie kan niet alleen maar inhouden dat alle apps die hiervan gebruik maken op de zwarte lijst worden gezet startActivities(), omdat er tal van legitieme toepassingen voor zijn. Het is ook erg moeilijk om er een detectiealgoritme voor te automatiseren. Kwaadwillende ontwikkelaars kunnen allerlei trucjes gebruiken om hun implementatie van StrandHogg 2.0 effectief onzichtbaar te maken voor diensten als Google Play Protect. StrandHogg 1.0 vereiste dat de aanvaller een attribuut toevoegde aan AndroidManifest.xml van de kwaadaardige app, wat relatief eenvoudig te detecteren was. StrandHogg 2.0 functioneert daarentegen volledig in Java/Kotlin.
Rekening houdend met verduistering, reflectie en zelfs maar verschillende codeerstijlen, lijkt het onpraktisch om automatisch een app te detecteren die gebruik maakt van deze exploit. Wat meer is, is dat als een gebruiker het onderwerp is van een StrandHogg 2.0-aanval, hij of zij het misschien niet eens weet. Als u Gmail opent en het inlogscherm ziet, denkt u misschien dat uw sessie is verlopen en voert u zonder nadenken uw inloggegevens in.
Toen we contact opnamen met Google voor een reactie, gaf een woordvoerder de volgende verklaring:
"We waarderen het werk van de onderzoekers en hebben een oplossing uitgebracht voor het probleem dat ze hebben geïdentificeerd. Bovendien detecteert en blokkeert Google Play Protect kwaadaardige apps, inclusief apps die deze techniek gebruiken."
Dit klinkt goed, en hopelijk heeft het op zijn minst enig effect tegen StrandHogg 2.0-aanvallen. Het is echter vermeldenswaard dat Google Play Protect deed niet detecteer onze proof of concept-app als kwaadaardig, zelfs na het uitvoeren van een handmatige scan.
Promon zegt dat ze "hebben geen echte malware waargenomen die gebruik maakt van de StrandHogg 2.0-kwetsbaarheid”, maar er is geen garantie dat dit de eerste keer is dat de exploit wordt ontdekt. Om die reden raadt Promon ontwikkelaars aan om hun apps te beschermen door de Activity's van hun launcher in te stellen launchMode vlag naar een van beide singleTask of singleInstance. Elk van deze vlaggen zal taakinjectie voorkomen, en dat is waar StrandHogg 2.0 op vertrouwt. Als uw activiteit een van deze vlaggen gebruikt, kan dit echter problemen veroorzaken met bepaalde app-stromen, dus dit is niet altijd wenselijk.
Promon maakt ook reclame voor zijn eigen product "In-App Protection by Promon SHIELD", dat klinkt als een bibliotheek die app-ontwikkelaars kunnen implementeren om de taken in het proces van uw app te controleren op onregelmatigheden invoegingen. Omdat er geen echt effectieve strategie voor het beperken van ontwikkelaars of gebruikers bestaat, is het behoorlijk belangrijk dat fabrikanten de patch implementeren om dit zo snel mogelijk op te lossen.
Gelukkig volgde Promon de richtlijnen voor verantwoorde openbaarmaking voordat hij deze exploit openbaar maakte (en het is nog steeds niet volledig openbaar: Promon wacht 90 dagen voordat hij volledig onthult hoe StrandHogg 2.0 werken). Google heeft sindsdien patches voor deze exploit gebackporteerd naar Android 8.0 Oreo, Android 8.1 Oreo en Android 9 Pie met de Mei 2020 Android-beveiligingspatchniveau (SPL). Gebruikers op Android 10 en hoger zijn niet kwetsbaar, hoewel we niet helemaal zeker weten waarom dat het geval is. Het heeft waarschijnlijk iets te maken met de nieuwe beperkingen van Android 10 met betrekking tot het starten van activiteiten en hoe Google dat in de takenstapel heeft geïntegreerd. Promon zegt dat "op Android 10 de aanval volledig ineffectief is en dat de activiteiten worden opgesplitst in verschillende taken en in afzonderlijke takenstapels volgens adb shell dumpsys activity activities."
Als de fabrikant van uw apparaat nog steeds beveiligingsupdates levert (lees meer over hoe het beveiligingspatchproces hier werkt), moet u ze zo snel mogelijk lastigvallen voor een update. Anders moet je voorzichtig zijn met welke apps je downloadt en uitvoert (hoewel je dat hoe dan ook zou moeten doen).
Voor meer details en gebruiksscenario's van StrandHogg 2.0, bekijk de officiële aankondiging op de website van Promon. Voor ontwikkelaars van aangepaste ROM's kunt u de relevante AOSP-commits vinden voor het voorkomen van StrandHogg 2.0-aanvallen hier En hier.
Tijdlijn voor openbaarmaking
Hier is de tijdlijn voor de openbaarmaking die Promon deelde in zijn StandHogg 2.0-document:
- 4 december 2019 – Probleem gemeld bij Google
- 4 december 2019 – Deelde een PoC “kwaadaardige app” en video met Google
- 4 december 2019 – Google bevestigde de ontvangst van het rapport
- 9 december 2019 – Google heeft de ernst van de bevinding ingesteld als ‘Kritisch’
- 9 december 2019 – Google bevestigt dat zij het probleem kunnen reproduceren
- 14 februari 2020 – We informeren Google begin maart dat de openbaarmaking van 90 dagen nadert en vragen om de status van hun kant
- 14 februari 2020 – Google antwoordt dat april de eerste is waarop ze een oplossing kunnen uitrollen
- 14 februari 2020 – We laten Google weten dat we aan oplossingen werken
- 14 februari 2020 – Google reageert. Ze werken aan herstelmaatregelen en vragen of we kunnen delen welke maatregelen we aanbevelen
- 17 februari 2020 – We laten Google weten dat we de openbaarmaking tot april kunnen uitstellen. Wij vragen het CVE-nummer
- 17 februari 2020 – We delen onze mitigatiestrategieën, evenals hoe we een platformmitigatie voor ogen hebben
- 23 maart 2020 – Google reageert met de CVE-ID (CVE-2020-0096)
- 23 maart 2020 – Google antwoordt dat de algemene beschikbaarheid van de fix voor Android in mei beschikbaar zal zijn
- 23 maart 2020 – Google vraagt of we overwegen de openbaarmaking uit te stellen tot mei
- 27 maart 2020 – Wij antwoorden dat we de openbaarmaking zullen uitstellen tot mei
- 22 april 2020 – Google laat ons weten dat het beveiligingsbulletin van mei een patch voor de kwetsbaarheid zal bevatten