Bepaalde Marshmallow-apparaten zijn gevoelig voor tapjacking, waarbij een app tekst over een toestemmingsdialoogvenster legt om de gebruiker te misleiden.
Terwijl velen van ons kwijlen over de nieuw uitgebrachte Android Nougat voor Nexus-apparaten, gebruikt de overgrote meerderheid van de gebruikers nog steeds Android Marshmallow. Een exploit waarvan het bestaan sindsdien is gedocumenteerd tenminste medio 2015 treft nog steeds veel moderne Android-apparaten.
Schadelijke toepassingen kunnen dat wel tapkraan jouw acties in door hen een toestemming te verlenen die u nooit expliciet hebt verleend. Hier ziet u hoe de exploit werkt.
De terugkeer van tapjacking
Stel je voor dat je Instagram opent en een foto probeert te delen die je onlangs hebt gemaakt terwijl je op vakantie was. Wanneer je ervoor kiest om in je galerij naar een foto te bladeren, vraagt Instagram je om toestemming voor toegang tot je opslag. Maar als u op "Ja" tikt, krijgt u een foutmelding.
Je kunt de opslagtoestemming voor Instagram niet verlenen omdat je een actieve schermoverlay hebt ingeschakeld dit geval een van de vele applicaties die uw scherm kleuren, zodat u uw telefoon 's nachts kunt gebruiken zonder te verblinden jezelf. Dit is een geval van het Android-machtigingensysteem
werken zoals bedoeld: om een applicatie gevoelige toestemming te verlenen, moet u alle schermoverlays op uw apparaat uitschakelen.Applicaties die over uw scherm kunnen tekenen, kunnen u mogelijk verleiden tot het invoeren van gevoelige gegevens. Een schermoverlay kan bijvoorbeeld een nep-wachtwoordinvoer bovenop een echt inlogscherm plaatsen om uw wachtwoorden te verzamelen. Een exploit als deze heet 'tappen' en is door de jaren heen op verschillende Android-versies verschenen en gepatcht een van de ergste voorbeelden die duurde tot Android 4.0.3. Maar onlangs maakte de exploit een terugkeer met Het runtime-toestemmingsmodel van Android Marshmallow.
Een ontwikkelaar met de naam Iwo Banas creëerde een sollicitatie het aantonen van de exploit. De manier waarop het werkt is vrij eenvoudig: wanneer een applicatie een toestemmingsdialoogvenster weergeeft, wordt de kwaadaardige applicatie aangevallen die u hebt geïnstalleerd, zal een systeemoverlay weergeven om het tekstblok van het toestemmingsdialoogvenster te bedekken met welke tekst dan ook wil. Een onwetende gebruiker die op "toestaan" klikt in het toestemmingsdialoogvenster zal worden misleid om toestemming te verlenen waar hem om werd gevraagd, maar waarvoor het verzoek voor de gebruiker verborgen was. Een dergelijke exploit vernietigt sinds de introductie van Android Marshmallow het doel van het toestemmingssysteem van Android Marshmallow volledig het nieuwe model moest ervoor zorgen dat gebruikers alleen toestemming zouden krijgen waarmee ze expliciet hadden ingestemd.
Ik weet waar je aan denkt. Als Android een systeemoverlay zou detecteren en mij ervan zou weerhouden Instagram-opslagrechten te verlenen, zou dit dan niet voorkomen dat deze exploit plaatsvindt? Het antwoord is nee, bij mijn tests blijkt dat op bepaalde apparaten het weergeven van een tekstoverlay bovenop een toestemmingsdialoogvenster het veiligheidsmechanisme niet activeert. De ontwikkelaar van de proof-of-concept tapjacking-applicatie stelt dat de exploit effectief is omdat deze is afhankelijk van de gebruiker die een secundaire kwaadaardige applicatie installeert die zich richt op API-niveau 22 en lager (pre-Marshmallow). Dit komt door het feit dat vóór Android Marshmallow alle applicaties tijdens de installatie toestemming kregen.
Oké, dus als je Marshmallow gebruikt, hoef je alleen maar te voorkomen dat je apps installeert die je niet vertrouwt en die toestemming vragen om een overlay te tekenen, toch? Als het toestemmingsmodel van Android zou werken zoals oorspronkelijk bedoeld, zou je gelijk hebben. Maar sinds de ontdekking van deze exploit, zelfs apps die API-niveau 23 targeten (Marshmallow) die om toestemming voor de overlay vragen, vormen een potentieel risico.
Een gat in het toestemmingsmodel?
Als je een van de vele miljoenen mensen bent die Facebook Messenger gebruiken om met je vrienden te chatten, dan ben je een van de beste functies van Android tegengekomen: de mogelijkheid voor apps om bovenop andere te tekenen schermen. Hoe cool is het dat je een bubbel kunt hebben met je favoriete Facebook-groepschat en de gebruiker kunt volgen bovenop elke applicatie die ze openen? Hoewel Facebook's Messenger het idee van "zwevende apps" mainstream heeft gemaakt, bestaat het concept al een tijdje in Android. Applicaties kunnen al een tijdje overlays over je apps heen creëren, dankzij het bestaan van TYPE_SYSTEM_OVERLAY in WindowManager van Android.
Vóór Android Marshmallow moesten applicaties om toestemming vragen SYSTEEM_ALERT_WINDOW tijdens de installatie voordat er overlays bovenop uw scherm kunnen worden weergegeven. Maar dit veranderde met de introductie van het gedetailleerde runtime-toestemmingsmodel van 6.0. Gebruikers zouden nu toestemming moeten verlenen aan applicaties wanneer ze de app daadwerkelijk gebruiken, wat hopelijk het gemiddelde zou stimuleren gebruiker om zijn eigen privégegevens te beschermen tegen applicaties die er verdacht om vragen en schijnbaar functioneel niets met elkaar te maken hebben rechten.
SYSTEM_ALERT_WINDOW is echter niet zoals andere machtigingen. Ontwikkelaars kunnen geen dialoogvenster weergeven waarin ze programmatisch vragen om toestemming van de eindgebruiker, zoals de meeste andere machtigingen voor apps die zich op Marshmallow richten. In plaats daarvan moet u handmatig naar het instellingenscherm navigeren en zelf de toestemming inschakelen. Natuurlijk helpen sommige apps, zoals Facebook Messenger, je tijdens het proces.
Google eist dit van ontwikkelaars omdat zij de toestemming als 'bijzonder gevoelig."
Speciale machtigingen
Er zijn een aantal machtigingen die zich niet gedragen als normale en gevaarlijke machtigingen. SYSTEM_ALERT_WINDOW en WRITE_SETTINGS zijn bijzonder gevoelig, dus de meeste apps zouden ze niet moeten gebruiken. Als een app een van deze machtigingen nodig heeft, moet deze de machtiging in het manifest declareren en een intentie verzenden waarin om autorisatie van de gebruiker wordt gevraagd. Het systeem reageert op de bedoeling door een gedetailleerd beheerscherm aan de gebruiker te tonen.
Gezien wat we hierboven weten over tapjacking, is dit logisch. Maar hier gaat het om. Google volgt niet eens zijn eigen regels. De schermafbeeldingen van Facebook Messenger die je begeleiden bij het verlenen van de SYSTEM_ALERT_WINDOW-toestemming die ik je hierboven heb laten zien? Dat gebeurt alleen als je de APK van buiten de Google Play Store installeert. Als u een applicatie uit de Google Play Store installeert, wordt de SYSTEM_ALERT_WINDOW toestemming wordt automatisch verleend.
Google heeft veiligheid opgeofferd voor gemak
Lange tijd vóór Android Marshmallow werd SYSTEM_ALERT_WINDOW beschouwd als een "gevaarlijk" toestemming. Met Android Marshmallow 6.0 is de toestemming gewijzigd in handtekening|systeem|app wat in eerste instantie vereiste dat ontwikkelaars de gebruiker naar het instellingenscherm moesten leiden om toestemming te verlenen. Maar met Android-versie 6.0.1 SYSTEM_ALERT_WINDOW is gewijzigd zodat de Google Play Store automatisch toestemming kunnen verlenenzonder de gebruiker hiervan op de hoogte te stellen. Waarom Google deze wijziging heeft doorgevoerd, is ons onduidelijk. Google zelf heeft niet naar buiten gebracht en verklaard waarom ze deze wijziging hebben doorgevoerd, wat vooral vreemd is gezien de taal over SYSTEM_ALERT_WINDOW die nog steeds op hun webpagina's staat.
Het is mogelijk dat genoeg ontwikkelaars waren boos door de eerste wijzigingen in SYSTEM_ALERT_WINDOW die vereisten dat gebruikers handmatig de toestemming moesten verlenen die Google stilletjes had toegegeven en deze gewoon had verleend aan elke applicatie die erom vroeg. Maar daarbij heeft Google dat wel gedaan veiligheid opgeofferd voor gemak. Er is een reden waarom Google zelf de toestemming het langst als gevaarlijk beschouwde, want dat is het ook. En het bestaan van de Marshmallow-exploit voor het tapjacken van toestemming is voldoende bewijs van de gevaren die inherent zijn aan het automatisch verlenen van deze toestemming aan welke app dan ook.
Deze tapjacking-exploit is pas onlangs onder onze aandacht gebracht, hoewel deze al vele maanden bestaat. Bij onze interne tests van apparaten door het XDA Portal-team hebben we dat bevestigd de exploit werkt op veel moderne apparaten met Android Marshmallow. Hier volgt een kort overzicht van de apparaten die we hebben getest op de nieuwste beschikbare softwareversies voor elk apparaat en of de tapjacking-exploit wel of niet werkt. De apparaten die zijn gemarkeerd als 'Kwetsbaar' zijn vatbaar voor tapjacking, terwijl de apparaten die zijn gemarkeerd als 'Niet Kwetsbaar" kunnen een app detecteren die de overlay weergeeft en verzoeken u deze eerder uit te schakelen doorgaan.
- Nextbit Robin - Android 6.0.1 met beveiligingspatches van juni - Kwetsbaar
- Moto X Pure - Android 6.0 met beveiligingspatches van mei - Kwetsbaar
- Eer 8 - Android 6.0.1 met beveiligingspatches van juli - Kwetsbaar
- Motorola G4 - Android 6.0.1 met beveiligingspatches van mei - Kwetsbaar
- OnePlus 2 - Android 6.0.1 met beveiligingspatches van juni - Niet kwetsbaar
- Samsung Galaxy Note 7 - Android 6.0.1 met beveiligingspatches van juli - Niet kwetsbaar
- Google Nexus 6 - Android 6.0.1 met beveiligingspatches van augustus - Niet kwetsbaar
- Google Nexus 6P - Android 7.0 met beveiligingspatches van augustus - Niet kwetsbaar
Tot nu toe zijn dit alle apparaten die ik door het team heb kunnen laten testen. Ik kon geen enkel verband vinden tussen de versie van de beveiligingspatch en de exploit. Zoals u kunt zien aan onze laatste discussie over Android-beveiligingsupdates, veel mensen draaien sowieso niet op de nieuwste beveiligingspatches en zijn dus mogelijk kwetsbaar voor deze en andere exploits die op de website worden beschreven Android-beveiligingsbulletin.
Vooruit gaan
We raden u aan deze exploit zelf op uw apparaat te testen om te zien of u kwetsbaar bent. We hebben de APK's samengesteld van de broncode hierboven gelinkt (je kunt het ook zelf doen) en heb ze geüpload naar AndroidFileHost. Om de exploit te testen, moet u zowel de belangrijkste tapjacking-toepassing evenals zijn helper dienst. Voer vervolgens eenvoudigweg de hoofdtoepassing uit en klik op de knop "test". Als er een tekstvak boven het toestemmingsdialoogvenster zweeft en wanneer u op 'Toestaan' klikt, verschijnt er een lijst met contacten op uw apparaat, dan is uw apparaat kwetsbaar voor tapjacking. Maak je geen zorgen dat het zwevende tekstvak het toestemmingsdialoogvenster niet volledig bedekt; deze proof-of-concept-app is dat niet bedoeld om perfect te demonstreren hoe je een toestemmingsdialoog netjes kunt kapen, maar eerder om te bewijzen dat dit inderdaad het geval is mogelijk.
We hopen dat er een oplossing komt die deze exploit op alle Marshmallow-apparaten herstelt, en dat OEM's al hun apparaten updaten naar de nieuwste beveiligingspatch. Omdat de realiteit is dat het vele maanden zal duren voordat de meeste beloofde apparaten Nougat krijgen, dus voor de meesten de enige manier Om gebruikers uit de gevarenzone te houden, moeten ze ofwel de nieuwste beveiligingspatches installeren, ofwel toestemming krijgen voor de monitorapp zich. Maar met het besluit van Google om automatisch de potentieel gevaarlijke SYSTEM_ALERT_WINDOW-toestemming te verlenen, zijn er veel gebruikers voeren onbewust apps uit die mogelijk hun telefoons kunnen kapen om steeds gevaarlijker te worden rechten.