Over 1000 Android-apper kan få tilgang til brukerdata uten riktige tillatelser

Til tross for brukeroppfatning er Android faktisk ganske sikkert som et mobilt OS. Vi aksepterer generelt forutsetningen om at det svakeste leddet er brukeren; så lenge du ser på hva du installerer og hvilke tillatelser du gir, bør du være trygg mot uautorisert tilgang og distribusjon av dataene dine. Hvis du nekter en Android-app tilgang til posisjonen din, bør den appen ikke ha noen måte å finne ut hvor du er eller hvor du har vært. Noen apputviklere har imidlertid funnet ut måter å komme seg rundt i Androids tillatelsesmodell, ifølge forskere fra International Computer Science Institute (ICSI).

I følge CNET, ble studien presentert forrige måned kl PrivacyCon etter å ha blitt ansvarlig avslørt til både Google og FTC i september i fjor. Selv om papir publisert på FTCs nettside viser ikke de eksakte appene som teamet flagget i analysen deres (disse detaljene kommer senere på

Usenix sikkerhetskonferanse neste måned), gir den detaljer om deres analysemetode og hvordan appene omgikk Androids tillatelsesmodell. For hva det er verdt, sier Google at sikkerheten og personvernet endrer Google har introdusert i Android Q vil lukke disse bypass-metodene, og derfor gir denne artikkelen verdifull innsikt i Googles begrunnelser for noen av plattformendringene de har gjort i Android 10. La oss dykke inn.

Hvordan >1000 apper omgikk Androids tillatelsesmodell

Forskerne skiller mellom to forskjellige sikkerhetsomgåelsesteknikker: sidekanaler og skjulte kanaler. Sidekanalteknikker innebærer å få tilgang til bestemt informasjon på en måte som ikke dekkes av sikkerhetsmekanismen; for eksempel pleide apper å spore en enhets plassering ved å bruke MAC-adressen inntil Android Pie introduserte MAC-adresserandomisering. Skjulte kanalteknikker involverer to tjenester som samarbeider for å sende data fra en tjeneste som har gyldig tilgang til en som ikke har det; for eksempel kan en app som har fått posisjonstilgang dele disse dataene med en app som ikke har fått tilgang.

ICSI-teamet analyserte 88 113 av de mest populære Android-appene fra den amerikanske Google Play-butikken og oppdaget over 1 000 apper og tredjepartsbiblioteker som bruke sidekanaler og/eller skjulte kanaler for å omgå Androids sikkerhetstiltak slik at de kan få tilgang til posisjonsdata og vedvarende identifikatorer til brukernes enheter. Hele datasettet deres besto av 252 864 APK-er siden teamet med jevne mellomrom skrapte Play-butikken for nye versjoner av de 88 113 appene de planla å analysere. De testet i utgangspunktet hver apps oppførsel på en Google Nexus 5X kjører Android 6.0.1 Marshmallow, men testet senere funnene deres på en Google Pixel 2 kjører Android Pie for å bevise at funnene deres fortsatt var gyldige fra den siste utgivelsen på tidspunktet for avsløringen.

Med dette datasettet utviklet teamet en metode som bruker dynamisk og statisk analyse for å oppdage omgåelse av Androids tillatelsesmodell. Med andre ord, teamet studerte app-atferd ved å revidere appens kjøretidsatferd (dynamisk analyse) eller skanne koden for potensielt ondsinnet oppførsel (statisk analyse.) Ondsinnede apputviklere er selvfølgelig klar over disse teknikkene, ved å bruke kodeobfuskering og dynamisk kodelasting for å gjøre statisk analyse vanskeligere eller TLS avlytting for å oppdage når appen kjører i et virtualisert miljø, så ICSI-teamet brukte en blanding av statisk og dynamisk analyse (hybridanalyse) i deres testing. Som et resultat oppdaget teamet at følgende data ble skrapet av apper som ikke hadde de nødvendige tillatelsene:

• IMEI: Siden en IMEI er en unik, vedvarende identifikator, er det nyttig for nettjenester å skrape slik at de kan spore individuelle enheter. Teamet oppdaget at Salmonads og Baidu SDK-er brukte en skjult kanal for å lese IMEI. Apper med legitim tilgang til IMEI lagret skjulte filer på den eksterne lagringen som inneholdt enhetens IMEI, slik at andre apper uten legitim tilgang kunne lese IMEI. Identifiserte apper som bruker Baidus SDK på denne måten inkluderer Disneys temaparkapper for Hong Kong og Shanghai, Samsung Health og Samsung Browser.
• Nettverks MAC-adresse: Nettverkets MAC-adresse er også en unik identifikator, og vanligvis er den beskyttet av tillatelsen ACCESS_NETWORK_STATE. Ifølge forskerne brukte apper C++-native kode for å "påkalle en rekke ubevoktede UNIX-systemanrop." Teamet identifiserte 42 apper som brukte Unity SDK for å åpne en nettverkskontakt og en ioctl for å få MAC-adressen, selv om de bemerket at 748 av de 12 408 appene inneholdt den aktuelle koden mens de manglet ACCESS_NETWORK_STATE tillatelse.
• MAC-adresse for ruteren: ACCESS_WIFI_STATE-tillatelsen beskytter BSSID-en, men å lese ARP-bufferen i /proc/net/arp lar en app skaffe disse dataene uten å trenge noen tillatelser. Forskeren identifiserte OpenX SDK som bruker denne sidekanalteknikken.
• Geolokalisering: Forskerne oppdaget at Shutterfly-appen fikk tilgang til plasseringskodene til bildenes EXIF-metadata. Alt som kreves er READ_EXTERNAL_STORAGE-tillatelsen.

I Android Q krever Google nå at apper har READ_PRIVILEGED_PHONE_STATE-tillatelsen til å lese IMEI. Enheter som kjører Android Q sender nå randomiserte MAC-adresser som standard. Til slutt, Android Q-er Omfanget lagring endringer reduserer muligheten for apper til å lese posisjonsdata fra bilder. Derfor har disse bekymringene blitt adressert i den siste Android-utgivelsen, men som vi alle vet, vil det gjøre det ta ganske lang tid for at den siste oppdateringen skal spre seg.

---

Konklusjon

Totalt sett gir denne studien et opplysende blikk på hvordan noen apper får tilgang til data som bør beskyttes bak tillatelser. Forskningen så bare på en undergruppe av det Google kaller "farlige" tillatelser, spesielt å hoppe over tillatelser som Bluetooth, kontakter og SMS. For alle detaljer om denne rapporten, anbefaler jeg å lese papir sendt til FTC.