Android en beveiliging: dit doet Google om je toestel te beschermen (2017-editie)

Android Security Year in Review 2016

Vorig jaar hebben we uitgebreid verslag gedaan van de belangrijkste manieren waarop Google probeert Android veiliger te maken en ook wat de grootste bedreigingen waren op het gebied van veiligheid.

Deze week heeft Google het ‘Android Security Year in Review’-rapport voor 2016 vrijgegeven. Dit 71 pagina’s tellende rapport staat weer bomvol statistieken, nieuwe beveiligingsmaatregelen en interessante malwarefamilies. In dit artikel bespreken we welke nieuwe maatregelen Google het afgelopen jaar getroffen heeft om Android beter te beveiligen. In het tweede deel van deze tweedelige artikelserie bespreken we de grootste beveiligingsbedreigingen van vorig jaar.

Fysieke beveiliging

Eén van de grootste bedreigingen op het gebied van beveiliging van Android-toestellen heeft niets te maken met schadelijke apps, maar met vermiste en gestolen toestellen. Google biedt daarom verschillende manieren om persoonlijke informatie te beschermen bij diefstal en vermissing. Tools als Smart Lock en Android Apparaatbeheer zijn niet nieuw, maar de informatie die Google in het beveiligingsrapport biedt wel interessante inzichten over hoe deze gebruikt worden in de praktijk.

Android Apparaatbeheer

De dienst Android Apparaatbeheer, Android Device Manager, bestaat sinds 2013 en maakt het mogelijk om een telefoon of tablet terug te vinden en op afstand te vergrendelen of te wissen. De functionaliteit voor Apparaatbeheer is ingebouwd in Android en het beheer kan worden gedaan door middel van de app of via de website.

In 2016 gebruikten gemiddeld 380.000 gebruikers per dag de dienst. Daarbij wordt de website verreweg het meest gebruikt en komen mensen vooral terecht bij Apparaatbeheer door te zoeken op ’telefoon vinden’. De functies die het meest gebruikt worden zijn dan ook gerelateerd aan het vinden van een toestel dat kwijt is. Het op afstand over laten gaan van de telefoon, bijvoorbeeld om deze in huis terug te vinden, en de locatie van een toestel bepalen zijn veruit de meestgebruikte functies.

De functies om toestellen op afstand te vergrendelen of zelfs te wissen worden weinig gebruikt en volgens Google geeft dat een indicatie van de meeste toestellen terug worden gevonden door de eigenaars. Apparaatbeheer weet alleen de (laatste) locatie van een toestel als locatiegeschiedenis ingeschakeld staat of wanneer een toestel bereikt kan worden via WiFi of dataverbinding.

Smart Lock

In 2015 introduceerde Google Smart Lock, om het gebruik van een vergrendelingsmethode op Android aantrekkelijker te maken. Met de Smart Lock-functie wordt deze vergrendeling, zoals beveiliging door middel van een patroon, pincode of vingerafdruk, onder bepaalde voorwaarden uitgeschakeld. Zo kun je instellen dat wanneer je thuis bent, er niet om een code gevraagd wordt.

In de statistieken van Smart Lock zien we dat deze functie er voor zorgt dat gebruikers veel minder vaak om een code of andere ontgrendelingsmethode gevraagd worden. Wanneer een combinatie van een vertrouwde locatie, Bluetooth-apparaten in de buurt en lichaamsdetectie gebruikt wordt, kan deze reductie zelfs oplopen tot 90%.

Wereldwijd gebruikt ongeveer 49% van de Android-gebruikers beveiliging op zijn ontgrendelscherm. Google geeft in het rapport niet aan of dit aantal toegenomen is, maar de introductie van (betrouwbare) vingerafdrukscanner in de meeste high-end en zelfs midrange-toestellen draagt bij aan het percentage gebruikers dat een beveiligd ontgrendelscherm gebruikt. In het rapport van vorig jaar gaf Google als voorbeeld dat 55,8% van de gebruikers met een Nexus 5 of Nexus 6 (geen vingerafdrukscanner) een beveiliging op hun ontgrendelscherm gebruikten, ten opzichte van 91,5% van de gebruikers met een Nexus 5X of 6P (wel een vingerafdrukscanner).

Beveiligingsupdates

In 2015 begon Google met het uitbrengen van maandelijkse beveiligingsupdates. Dit gebeurde naar aanleiding van de bekendmaking van een paar grote beveiligingslekken in Android die samen bekend staan onder de naam Stagefright. Door de relatief grote paniek voelde Google zich genoodzaakt om maatregelen te nemen. Eén van deze maatregelen was het uitbrengen van maandelijkse beveiligingsupdates voor Nexus-apparaten en later ook voor Pixel-apparaten.

Google bracht al ruim voor 2015 elke maand een beveiligingsbulletin uit dat werd verspreid onder fabrikanten die Android-toestellen uitbrengen. Dit bulletin bevat informatie over beveiligingslekken in Android en de manier waarop deze lekken gedicht kunnen worden. Na het uitkomen van Stagefright besloot Google deze beveiligingsbulletins publiekelijk bekend te maken op elke eerste maandag van de maand. Door aan de beveiligingsverbeteringen die worden genoemd een datum te hangen, het zogenaamde ‘niveau van Android-beveiligingspatch’,  weten gebruikers beter waar ze aan toe zijn en kunnen ze fabrikanten actiever vragen om beveiligingsupdates.

Het lijkt er op dat de vergrote transparantie met betrekking tot beveiligingsupdates helpt, maar de statistieken zijn nog steeds niet rooskleurig. De beveiligingsbulletins bevatten in 2016 verbeteringen voor Android 4.4 KitKat en hoger, maar zo’n 14% van de actieve Android-toestellen draait op een oudere Android-versie. Volgens Google hadden in december van 2016 zo’n 735 miljoen Android-apparaten een beveiligingspatch-niveau uit 2016. Het bedrijf noemt daarbij, vermoedelijk bewust, geen percentage. In de aankondiging van het beveiligingsrapport heeft Google het over 1,4 miljard Android-gebruikers. Wanneer we uitgaan van 1,4 miljard apparaten zit het percentage op iets meer dan 50%, wanneer deze 1,4 miljard gebruikers mogelijk meerdere apparaten hebben, ligt het percentage zelfs nog lager.

De update-percentages voor vlaggenschepen liggen wel flink hoger en daarin zien we update-beloftes van Google, Samsung en LG terug. Deze fabrikanten hebben aangegeven de maandelijkse beveiligingsupdates zo snel mogelijk naar hun vlaggenschepen te zullen brengen. Hierbij is de samenwerking met providers, die vaak lang deden over de goedkeuring van nieuwe updates, van groot belang. Google geeft aan dat in de Verenigde Staten 78% van de belangrijkste toestellen bij de vier grote providers voorzien was van een beveiligingsupdate die maximaal 3 maanden oud was. Het gaat dan om de vlaggenschepen van Samsung (Galaxy S7, S7 Edge, S7 Active, S6, S6 Edge, S6 Edge+, S6 Active, Note 5, Note 4, Note Edge, A5 (2016)), LG (G5, G4, G3, V10), Moto (X Play, X Style, X Force), Huawei (Mate 8, Mate S, P8, P9) en Sony (Xperia Z4, Z5, Z5 Compact, Z5 Premium). In Europa ligt dat percentage op 73%. 

Verbeteringen in Android

In 2016 introduceerde Google Android 7.0 en 7.1 Nougat. Deze nieuwe Android-versies bevatten een aantal veranderingen die moeten zorgen voor betere beveiliging.

Sneller update-proces

Tijdige updates zijn belangrijk om toestellen beter beveiligd te houden, maar daarbij ligt de verantwoordelijk niet altijd alleen bij de fabrikant. Veel gebruikers stellen het doen van updates, omdat het updaten van een toestel vaak een tijdrovende klus is. Tot Android 7.0 Nougat moesten na de eigenlijke update alle apps opnieuw ‘geoptimaliseerd’ worden. Met een flinke lijst apps kon dit een flinke tijd in beslag nemen, terwijl een toestel op dat moment niet gebruikt kon worden. Dit is niet langer het geval: het optimaliseren van apps neemt door technische wijzigingen minder tijd in beslag en kan op de achtergrond gebeuren nadat een update geïnstalleerd is.

Sinds Android 7.1.1 Nougat ondersteunt Android ook updates die op de achtergrond geïnstalleerd worden. Bij deze installatiemethode moeten alle systeemgedeeltes in het geheugen dubbel aanwezig zijn. Hierdoor kunnen updates worden geïnstalleerd op het systeem dat niet in gebruik is. Na het opnieuw opstarten van een toestel, is de update dan direct geïnstalleerd. Is er iets foutgegaan en start het systeem niet op, dan is het mogelijk om de oude versie weer te starten. Op dit moment wordt dit voornamelijk ondersteund door de Google Pixel en Pixel XL, maar de verwachting is dat meerdere toestellen zullen volgen.

Beveiligingsprogramma

In 2015 kwam Google met het Android Security Rewards Program, een manier voor ontwikkelaars om geld te verdienen met het melden van beveiligingsproblemen in Android. Sinds juni 2015 zijn bijna 500 geldbedragen uitgekeerd aan meer dan 125 verschillende beveiligingsonderzoekers.

Volgens Google is in 2016 bijna 1 miljoen dollar aan beloningen uitgekeerd aan onderzoekers die lekken in Android gevonden hebben. Door halverwege de geldbedragen te verhogen voor onderzoekers die duidelijkere foutrapportages indienen, zou de kwaliteit van de gemelde problemen een stuk hoger geworden zijn. Wanneer een onderzoeker zijn beloning aan een goed doel doneert, verdubbelt Google dat bedrag nog eens en dat gebeurde met beloningen van 14.500 dollar.

Google heeft verder een aantal hackwedstrijden gesponsord en opgezet, die voor veel ontdekte kwetsbaarheden hebben gezorgd. Het bedrijf geeft daarbij aan dat de meeste van deze lekken vrijwel direct gedicht konden worden en direct konden worden opgenomen in de maandelijkse beveiligingsupdates.

Bestandsgebaseerde encryptie

Al vanaf Android 3.0 Honeycomb biedt Android ondersteuning voor zogenaamde full-disk-encryptie. Dat houdt in dat het volledige opslaggeheugen kan worden versleuteld, zodat het geheugen niet uit te lezen is door iemand die fysiek toegang heeft tot het toestel.

Bij Android 5.0 Lollipop en 6.0 Marshmallow zijn hier grote verbeteringen in gedaan en vanaf Marshmallow moet deze vorm van encryptie standaard worden ingeschakeld op apparaten die hier geschikt voor zijn. Deze verplichting zien we ook terug in het aantal apparaten met een versleuteld geheugen.

Het gebruik van full-disk-encryptie heeft wel een belangrijk nadeel en dat is nu precies dat het volledige geheugen versleuteld wordt. Dat wil zeggen dat het geheugen pas kan worden uitgelezen, wanneer het wachtwoord of de code ingegeven is. Het besturingssysteem heeft dan ook nog geen toegang tot de gegevens, wat wil zeggen dat bijvoorbeeld een ingestelde wekker niet af kan gaan tot het toestel ontgrendeld is: daar heeft het systeem dan geen toegang toe. 

In Android 7.0 Nougat is Google daarom overgestapt op een andere manier van versleutelen die minder zwart-wit is, file-based-encryptie. Daarbij kunnen sommige delen van het geheugen al eerder worden vrijgegeven, zodat bijvoorbeeld een ingesteld alarm gewoon af kan gaan. Normaal gesproken is full-disk-encryptie sneller dan file-based-encryptie, maar Google heeft een aantal verbeteringen doorgevoerd waardoor het prestatieverschil volgens het bedrijf minimaal is.

Verbeteringen bij mediaserver

De problemen rondom Stagefright lagen allemaal in het feit dat de afhandeling van media op Android gedaan werden door een proces dat verregaande rechten in het systeem heeft. Door een lek in deze afhandeling te misbruiken, zou een aanvaller toegang tot vrijwel alle gegevens op een toestel kunnen krijgen. 

In Android 7.0 Nougat heeft Google deze afhandeling volledig omgegooid. Voorheen kregen alle mediagerelateerde processen toegang tot bijna alle rechten, nu zijn deze processen veel beperkter. Zo krijgen audio-processen alleen toegang tot bijvoorbeeld Bluetooth, de geluidschip en de media-opslag. Hierdoor zijn, zelfs bij nieuwe lekken, de gevolgen van een lek veel minder ernstig.

Google heeft verder het buildproces aangepast, waardoor veelvoorkomende aanvalsmethoden van hackers niet of minder goed gebruikt kunnen worden.

Google Security Services

We hebben al eerder vast kunnen stellen dat beveiligingsupdates en updates in zijn algemeenheid vaak achterlopen of zelfs volledig achterwege blijven op veel Android-toestellen. Dat wil echter niet zeggen dat deze toestellen kwetsbaar zijn voor de beveiligingslekken die in oudere Android-versies te vinden zijn: Google neemt nog extra maatregelen die variëren van de extra controle van apps in en buiten de Play Store tot het scannen van toestellen met een ingebouwde malwarescanner. Deze maatregelen vallen onder Google Security Services en zorgen er voor dat alle toestellen die voorzien zijn van Google Play services relatief veilig zijn.

Verify Apps

We kunnen de beveiligingsmethoden in Google Security Services opdelen in ruwweg twee categorieën, namelijk de bescherming op toestellen zelf en de beveiliging van buitenaf. Eén van de manieren waarop Google Androidtoestellen veilig probeert te houden, is met Verify Apps, de ingebouwde virusscanner van Android.

Verify Apps scant apps op het moment dat ze geïnstalleerd worden, maar doet dit ook regelmatig met eerder geïnstalleerde apps. Daarbij wordt gekeken of apps voorkomen in de database van mogelijk schadelijke apps en of apps mogelijk schadelijke onderdelen bevatten. Wanneer dit het geval blijkt te zijn, zal de gebruiker hiervan op de hoogte worden gesteld door middel van een waarschuwing. Sommige pure malware-apps, die geen enkel positief effect voor de gebruiker hebben, kunnen direct door Verify Apps verwijderd worden, waarna de gebruiker hier een melding van ontvangt.

Google kent een groot gedeelte van de apps die gescand worden al omdat ze deze in de Play Store of op andere toestellen tegen zijn gekomen. Er zijn echter ook ‘zeldzame’ apps. Door de functie ‘Detectie schadelijke apps verbeteren’ in te schakelen bij de beveiligingsinstellen van een toestel, kunnen deze worden geüpload naar de servers van Google, waar ze verder ontleed worden. In 2016 werden 87% meer van dit soort apps geüpload, gedurende het jaar waren dat er 1,8 miljoen.

Sommige schadelijke applicaties proberen op de achtergrond, vaak zonder dat de gebruiker het in de gaten heeft, apps te installeren. Dit kunnen veilige apps zijn, maar in 37% van de gevallen dat het volgens Google om wederom potentieel gevaarlijke apps. In september 2016 is Verify Apps aangepast om de installatie van dit soort apps te blokkeren. In de grafiek hieronder zie je dat sindsdien een significant gedeelte van dit soort achtergrondinstallaties geblokkeerd is ten opzichte van alle app-installaties.

SafetyNet en Safe Browsing

SafetyNet bestaat al sinds 2013 en laat Google gebruikers beter beschermen op basis van relevante beveiligingsdata. Voorheen werden alleen gebruikers die apps van buiten de Google Play Store installeerden gevraagd om SafetyNet in te schakelen, maar vanaf 2016 staat de functie standaard ingeschakeld.

Ontwikkelaars kunnen gebruik maken van de mogelijkheden van SafetyNet om te bepalen of een toestel veilig is. Dat is bijvoorbeeld belangrijk voor apps in de financiële sector, zoals applicaties voor mobiel bankieren. Voorheen kregen ontwikkelaars dan alleen te zien of een toestel volledig gecertificeerd en compleet beveiligd was. Sinds 2016 kunnen ontwikkelaars ook kijken of een toestel alleen aan een aantal basisvoorwaarden voldoet en dat het apparaat lijkt te beschikken over voldoende beveiligingsmaatregelen.

Een andere nieuwe toevoeging in het afgelopen jaar is dat gebruikers zelf kunnen zien of hun toestel door Google gecertificeerd is. In de Google Play Store kan deze certificeringsstatus worden bekeken bij ‘Instellingen’–> ‘Apparaatcertificering’. 

Met de functie Safe Browsing probeert Google je te behoeden voor gevaarlijke websites. Deze functionaliteit zit al lang ingebouwd in Chrome en sinds half 2016 kunnen ontwikkelaars de database van Google met schadelijke sites raadplegen om te voorkomen dat hun gebruikers op dit soort websites terecht komen.

Safe Browsing is afgelopen jaar ook uitgebreid met een nieuwe functie waarbij sites die in het verleden de fout ingegaan zijn, beter in de gaten worden gehouden. Sommige malwaresites hadden namelijk de tactiek om slechts tijdelijk malware aan te bieden, deze te verwijderen na een malware-melding en deze weer terug te plaatsen als de melding ingetrokken was. Door deze nieuwe functie kunnen webmasters pas na minimaal 30 dagen weer opnieuw een verzoek doen om de melding in te laten trekken.

Statische en dynamische analyse van apps

De tweede categorie van beveiligingsmaatregelen in Google Security Services zijn te vinden in de cloud, op de servers van Google zelf. Dan hebben we het onder andere over de analyse van applicaties en de detectie van mogelijk schadelijke functies en code.

De detectie van schadelijke apps gebeurt op twee manieren, namelijk door middel van statische en van dynamische analyse. Bij statische analyse wordt de code van een app bekeken en wordt daarin opgezocht of bepaalde schadelijke functionaliteit ingebouwd zit. Zo kan worden gekeken of de app bijvoorbeeld gevoelige informatie kan verzenden naar derden of binnenkomende (premium) sms-berichten kan verwijderen.

De meest interessante analyse is echter de dynamische analyse van apps die Google doet op zijn servers. Deze vindt plaats door apps te draaien in afgeschermde omgevingen op virtuele smartphones. De Google-servers doen daarbij net alsof ze een Android-smartphone zijn en daarbij wordt invoer door de gebruiker gesimuleerd en dit gaat zo ver dat dit testproces zelfs een nieuwe account aan kan maken.

In 2016 heeft Google naar eigen zeggen het dynamische testproces versneld, nieuwe detectiemethoden toegevoegd en nieuw ‘virtueel gedrag’ toegepast. Dit heeft tot drie keer zoveel meldingen van mogelijk schadelijk gedrag geleid, waarna menselijke testers de app handmatig gecontroleerd hebben. Bij deze automatische detectie speelt Google een kat-en-muis-spel met de makers van schadelijke apps, aangezien die proberen te detecteren of een app in een virtuele omgeving draait of op een echt toestel. Google probeert op zijn beurt weer de code die verantwoordelijk is voor dit soort gedrag te vinden.

Integratie met SafetyNet

Google gebruikt informatie die het bedrijf verkrijgt via SafetyNet onder andere om afwijkende zaken bij bepaalde apps te detecteren die niet opvallen bij het gebruik in een gesimuleerde omgeving. In 2014 was het eerste voorbeeld daarvan de bestrijding van sms-fraude. Sinds Android 4.2 Jelly Bean geeft Android standaard een melding als een app een sms-bericht wil sturen naar wat mogelijk een premium-nummer is. Op basis van de reactie van de gebruiker op het waarschuwingsdialoog, kan Google afwijkingen ontdekken. Als relatief veel gebruikers er voor kiezen de app hier geen toestemming voor te geven, kan dat aangeven dat een app schadelijk gedrag vertoont.

Google gebruikt voor de analyse van statistisch afwijkend gedrag binnen SafetyNet de Anomaly Correlation Engine (ACE). Met deze machine learning-functie heeft het bedrijf in 2016 zich gefocust op de detectie van kwaadaardige root-apps. Deze apps kunnen onderdeel zijn van malware die in meerdere fasen geïnstalleerd wordt zonder medeweten van de gebruiker. De ACE zou volgens het bedrijf 90% van de gevallen van dit soort gedrag detecteren.

Sinds april 2016 gebruikt Google binnen SafetyNet de Verify Apps-data om te ontdekken of apparaten niet langer actief of niet langer veilig zijn. Als een apparaat na de installatie van een app geen terugkoppeling meer geeft aan Verify Apps, dan kan dit betekenen dat er sprake is van een besmetting met een schadelijke app. Door te kijken bij welke apps dit significant vaker gebeurt dan bij andere apps, kon Google behoorlijk precies vaststellen welke apps besmet bleken met malware.

Google heeft in 2016 voor het eerst ook een andere aanpak gebruikt voor het scannen op mogelijk schadelijke apps. Door middel van machine learning werden installatiepatronen van schadelijke apps bekeken en gegroepeerd. Door deze automatische classificering bleek het mogelijk om malware te ontdekken die kleine wijzigingen ten opzichte van bestaande malware vertoonden. 

Conclusie

Het afgelopen jaar is er weer veel gebeurd op het gebied van Android-beveiliging. Beveiligingsupdates, of updates in het algemeen, zijn bij Android nog steeds verre van vanzelfsprekend, maar dat betekent niet dat beveiliging op Android slecht is. Doordat Google verschillende technieken toepast om apps in en van buiten de Google Play Store te scannen en zelfs later nog in de gaten te houden, is Android een stuk veiliger dan we alleen op basis van de geïnstalleerde Android-versie zouden aannemen. Hoe goed de beveiligingsmaatregelen het afgelopen jaar precies in de praktijk gewerkt hebben en wat de grootste bedreigingen van 2016 waren, lees je in het aankomende tweede deel van deze artikelserie.

Het volledige beveiligingsrapport van Google is hier te lezen.