Android Security 2015 Year in Review
Google brengt elk jaar een beveiligingsrapport uit met daarin informatie over op welke manieren het bedrijf probeert om Android zo vrij mogelijk van bedreigingen te maken. Gisteren kwam de 2015-editie van ‘Android Security Year in Review’ uit en daarin bespreekt Google alle nieuwe technieken die gebruikt worden om bedreigingen tegen te gaan.
In dit artikel bespreken we de nieuwe en bestaande manieren die Google gebruikt om Android te beveiligen. Het artikel is opgedeeld in drie stukken. Het eerste stuk beslaat de maandelijkse beveiligingsupdates, het tweede stuk beveiligingsverbeteringen in Android zelf en het derde stuk gaat over het SafetyNet en Verify Apps, waarmee Google schadelijke apps opspoort. In het tweede deel in deze mini-serie over beveiliging bespreken we de grootste beveiligingsrisico’s van het afgelopen jaar op Android.
Snellere updates voor Android
Feit is dat Android-toestellen over het algemeen niet snel geüpdatet worden. Dat houdt in dat toestellen vaak maanden of langer draaien op software waar bekende beveiligingslekken in zitten. Dit is een probleem van providers die lang doen over een goedkeuringsproces en van fabrikanten die niet genoeg prioriteit aan updates geven.
Google brengt al sinds het prille begin van Android regelmatig een lijst met beveiligingsverbeteringen uit voor Android-fabrikanten. Deze verbeteringen zijn momenteel beschikbaar voor Android 4.4.4 (KitKat) en hoger en zijn bedoeld zodat de fabrikanten ze op kunnen nemen in hun updates. Momenteel draait meer dan 70% van de actieve apparaten op een Android-versie waarvoor Google de oplossing voor lekken biedt.
Stagefright-angst en maandelijkse beveiligingsupdates
Met het verschijnen van het beruchte Stagefright-lek in Android zag Google zich genoodzaakt om de strategie op het gebied van beveiligingsupdates te verbeteren. Vanaf begin augustus biedt het bedrijf een maandelijkse beveiligingsupdate die in het Android Open Source Project wordt vrijgegeven naast een openbaar beveiligingsbulletin met de verholpen problemen.
Tegelijkertijd met de aankondiging van het maandelijkse bulletin liet Google ook weten elke maand een beveiligingsupdate uit te zullen brengen voor Nexus-toestellen en Samsung, LG en BlackBerry hebben een soortgelijke statement uitgebracht en hebben aangegeven maandelijkse beveiligingsupdates voor hun vlaggenschepen uit te zullen brengen. BlackBerry heeft daarbij laten zien consequent nog eerder dan Google zelf te zijn met het uitbrengen van de beveiligingsupdates.
Google biedt daarnaast ook meer duidelijkheid over hoe lang een Nexus-apparaat ondersteund wordt: de eerste twee jaar zullen de toestellen updates naar grote nieuwe Android-versies krijgen en de toestellen krijgen drie jaar na het uitkomen van een toestel beveiligingsupdates of 18 maanden nadat het toestel voor het laatst verkocht is via de Google Store. Daarbij geldt welke van de twee periodes het langst is. Ook Samsung en BlackBerry hebben te kennen gegeven hoe lang een apparaat zal worden ondersteund. De informatie voor Samsung-toestellen wordt op de Nederlandse website van de Zuid-Koreaanse fabrikant vermeld.
Halverwege 2015 nam Google Android op in het Vulnerability Reward Program, waarbij onderzoekers een beloning krijgen als ze beveiligingsproblemen weten te ontdekken. Oplossingen voor deze problemen worden dan uiteraard opgenomen in de maandelijkse updates. In 2015 is meer dan 210.000 dollar uitgekeerd aan onderzoekers voor het vinden van Android-lekken, waarbij 30 kritieke fouten zijn opgespoord.
Beveiligingsverbeteringen in Android
Het afgelopen jaar heeft Google één grote nieuwe Android-versie uitgebracht, Android 6.0 Marshmallow. Daarin zijn verschillende beveiligingsverbeteringen doorgevoerd. Deze zijn niet alleen gericht tegen malware en andere schadelijke apps, maar ook tegen pottekijkers en dieven.
Vingerafdrukscanner
Ondersteuning voor vingerafdrukscanners is niets nieuws voor Android-toestellen zou je zeggen en inderdaad, de Motorola Atrix had in 2011 al een vingerafdrukscanner aan boord. Android zélf heeft echter pas vanaf Android 6.0 ondersteuning voor dit soort scanners, voorheen waren fabrikanten aangewezen op een eigen implementatie.
Volgens Google zorgt de beschikbaarheid van een vingerafdrukscanner er voor dat veel meer mensen hun toestel vergrendelen. Op de Nexus 5 en Nexus 6 gebruikt 55,8% van de mensen een beveiligd lockscreen, terwijl dat op de Nexus 5X en Nexus 6P 91,5% is. Ook op andere toestellen ziet Google een toename in het gebruik van een beveiligd lockscreen wanneer er een vingerafdrukscanner aanwezig is.
Permissies
In Android 6.0 introduceerde Google ook een vernieuwd systeem voor permissies. Voorheen moesten applicatie-ontwikkelaars aangeven welke systeemfuncties een app wil gebruiken en tot welke gebruikersdata een app toegang wil. Deze toestemming werd dan nog vóór de installatie van een app al dan niet verleend: de gebruiker kon er eventueel voor kiezen de app niet te installeren.
Dit is veranderd in Marshmallow: voortaan kunnen apps deze toestemming aanvragen op het moment dat ze toegang tot een functie of data nodig hebben. Een goed voorbeeld hiervan is de Facebook-app. Deze heeft, omdat de app heel veel uiteenlopende functies gebruikt, heel veel permissies nodig. Daardoor zou Facebook in principe je bijvoorbeeld te allen tijde af zou kunnen luisteren, omdat het toegang heeft tot jouw microfoon. In Android 6.0 kun je de app wel installeren, maar dan geen toegang geven tot privacy-gevoelige functies zoals het gebruik van jouw microfoon, camera en het opvragen van je locatie.
Het vernieuwde permissiessysteem in Android 6.0 Marshmallow is niet alleen voor gebruikers een grote vooruitgang, ook ontwikkelaars krijgen minder snel vragen over ‘vreemde permissies’ die noodzakelijk zijn voor een functie die slechts sporadisch gebruikt hoeft te worden. Daarnaast kunnen ontwikkelaars beter uitleggen waarom een bepaalde permissie nodig is en zien de gebruikers beter de relatie tussen de permissie en de gebruikte functie.
Smart Lock
Zogeheten TrustedAgents, applicaties die het vergrendelscherm kunnen beheren, zijn sinds Android 5.0 Lollipop onderdeel van het systeem. De bekendste daarvan is Smart Lock van Google zelf. De verificatie van het lockscreenwachtwoord wordt sinds Android 6.0 gedaan in het beveiligde gedeelte van het werkgeheugen en bevat steeds groter wordende vertragingen bij mislukte inlogpogingen, waardoor het bijna onmogelijk gemaakt wordt om een wachtwoord of pincode te raden door willekeurige getallen of wachtwoorden in te geven.
Met Smart Lock hoeft de gebruiker het toestel maar één keer te ontgrendelen en wanneer hij dan het toestel bij zich blijft dragen, op een bepaalde plaats blijft of verbonden blijft met hetzelfde netwerk of Bluetooth-accessoire, zal hij het toestel niet opnieuw hoeven te ontgrendelen. Het aantal ontgrendelpogingen wordt volgens Google bij het gebruik van Smart Lock in combinatie met een vertrouwde locatie, een vertrouwde Bluetoothverbinding en lichaamsdetectie het aantal keren dat een toestel ontgrendeld moet worden met 90% verminderd.
Encryptie en geverifieerd opstarten
Sinds Android 3.0 Honeycomb ondersteunt Android full disk encryption, wat inhoudt dat alle informatie die door de gebruiker of door apps wordt opgeslagen, wordt versleuteld. Deze informatie is dan alleen uit te lezen wanneer je beschikt over het wachtwoord.
In Android 5.0 Lollipop begon Google met het sterk aanbevelen van fabrikanten om deze vorm van beveiliging standaard in te schakelen op smartphones die daar snel genoeg voor zijn. Het versleutelen en ontcijferen van alle data is namelijk een processorintensieve klus en deze kan zorgen voor vertragingen. Dit geldt vooral wanneer de in een toestel gebruikte chipset geen speciale ondersteuning heeft voor encryptie.
Vanaf Android 6.0 Marshmallow zijn fabrikanten verplicht om full disk encryption standaard in te schakelen op hun toestellen als die de versleuteling efficiënt genoeg kunnen verwerken. Vanaf de vorig jaar geïntroduceerde Android-versie is het ook mogelijk om SD-kaarten als (bijna) volwaardig onderdeel van het geheugen te gebruiken. Meer daarover lees je in ons uitgebreide artikel, maar een belangrijk detail is dat hierbij ook gebruik wordt gemaakt van volledige versleuteling van alle data.
Google geeft verder aan dat bijna alle toestellen die nieuw worden uitgeleverd met Android 6.0 gebruik maken van een verifiërend opstartmechanisme waarbij de sleutel opslagen zit in een beveiligd onderdeel van het toestel. Met deze zogenaamde verified boot zorgt er voor dat Android niet automatisch opstart als er met het systeem geknoeid is. De gebruiker kan dan wel de mogelijkheid krijgen om alsnog verder te gaan met opstarten, maar krijgt wel een waarschuwing dat de veiligheid van zijn gegevens niet gegarandeerd kan worden.
App Security Improvement Program
Het verbeteren van de beveiliging van Android gebeurt niet alleen op systeemniveau, maar wordt ook aangepakt bij individuele apps. Google scant apps op bekende beveiligingsrisico’s die optreden wanneer ontwikkelaars bijvoorbeeld verouderde software in hun eigen apps gebruiken.
Google waarschuwt ontwikkelaars al langere tijd als hun apps potentieel onveilig zijn en volgens het bedrijf heeft dit gezorgd voor een oplossing voor meer dan 100.000 potentiële beveiligingsrisico’s.
Sinds afgelopen jaar verbindt Google ook een consequentie aan ontdekte problemen: 90 dagen na het ontdekken van een bepaald risico, mogen er geen nieuwe apps of updates meer worden gepubliceerd in de Google Play Store. Bestaande apps mogen alleen worden geüpdatet als ze het risico niet meer bevatten.
Verbeteringen in het SafetyNet
Wanneer we lezen over een nieuw beveiligingslek in Android, horen we vaak dat meer dan 95% van de Android-apparaten kwetsbaar is. Dat percentage is dan afkomstig uit statistieken die Google zelf uitgeeft: de maandelijkse distributiecijfers laten zien welke Android-versies actief worden gebruikt. Wanneer we kijken naar de huidige distributiecijfers, dan zien we dat 4,6% van de actieve toestellen op Android 6.0 Marshmallow draaien. Dat houdt in dat als er een beveiligingsprobleem in een lagere Android-versie zit, meer dan 95% van de actieve toestellen daar kwetsbaar voor zou zijn. Door het SafetyNet van Google is het werkelijke percentage een heel stuk lager.
Zoals we mogen verwachten van Google, maakt Google gebruik van zijn cloudmogelijkheden om toestellen veiliger te maken. Dat doet het bedrijf door het scannen van apps en door ze in de gaten te houden.
Potentieel schadelijke apps
Google heeft het in zijn beveiligingsrapport veel over potential harmful applications (PHA), oftewel potentieel schadelijke apps. Volgens het bedrijf zijn deze apps, die we ook wel malware noemen, het grootste beveiligingsrisico voor Android.
In 2015 stonden dit soort mogelijk kwaadaardige apps volgens Google op z’n hoogst op minder dan 1% van de apparaten en gemiddeld lag dit percentage onder de 0,5%. Het aantal pogingen om PHA’s te installeren via de Google Play Store nam volgens het bedrijf af. Apps die buiten de Google Play Store om worden geïnstalleerd hebben volgens Google een 10 keer hogere kans om in de categorie van potentieel schadelijke apps te vallen.
In de grafiek hieronder is te zien hoeveel van dit soort apps geïnstalleerd waren ten opzichte van het totale aantal actieve Android-apparaten. Daarbij zijn overigens goedaardige root-applicaties uitgesloten. Deze apps zijn dan wel potentieel schadelijk, maar identificeren zichzelf als root-app en vragen eerst toestemming voordat systeem-onderdelen worden aangepast.
In de onderstaande grafiek laat Google zien dat het aantal toestellen waarop een PHA geïnstalleerd is een stuk groter is wanneer er ook apps van buiten de Google Play Store om geïnstalleerd worden. Daarbij moeten we wel een kanttekening plaatsen: gebruikers die de optie ‘apps installeren uit onbekende bronnen’ ingeschakeld hebben, zijn over het algemeen geavanceerdere gebruikers die mogelijk ook uit de Play Store andere apps installeren dan gebruikers zonder deze functie. Wanneer we Google’s opmerking dat apps van buiten de Play Store om 10 keer vaker potentieel schadelijk zijn, kunnen we echter concluderen dat het installeren van apps uit onbekende bronnen wel degelijk een groter beveiligingsrisico vormt.
Verify Apps: malware-scanner in de cloud
In 2012 introduceerde Google de Verify Apps-functie. Hiermee begon Google met een cloudgebaseerde beveiligingsfunctie waarmee apps gescand worden op malware en andere onkuise zaken. Inmiddels maken meer dan 1 miljard actieve toestellen gebruik van deze functie en worden er meer dan 400 miljoen apps per dag gescand.
Wanneer Verify Apps een potentiële bedreiging in een app ziet voor het installeren, zal de gebruiker hiervan op de hoogte worden gesteld. In 2015 heeft Google het uiterlijk en de tekst van het het waarschuwingsvenster aangepast en dat heeft er volgens het bedrijf voor gezorgd dat 50% minder van de potentieel schadelijke apps na een waarschuwing alsnog door gebruikers werden geïnstalleerd. Niet alleen moet de gebruiker een extra stap ondernemen om de app alsnog te installeren, ook ziet de bewoording en het rode waarschuwingsdriehoekje er dreigender uit.
Google controleert niet alleen apps die in de Google Play Store te vinden zijn, maar scant alle apps die zijn cloudgebaseerde systemen op publieke websites kunnen vinden. Dit zorgt er voor dat er veel meer schadelijke apps en manieren van misbruik gevonden worden. Sinds 2015 is dit scanmechanisme uitgebreid en kunnen gebruikers bij het installeren van een voor Google onbekende app er voor kiezen deze app naar de servers van het bedrijf te uploaden, zodat deze daar ook gescand kunnen worden.
De apps worden overigens bij het installeren niet eerst naar de servers van Google gestuurd, er wordt een set van een soort digitale handtekeningen gemaakt, die dan vergeleken wordt met bekende malware-handtekeningen en -eigenschappen. In 2015 is deze set van handtekeningen uitgebreid om zo detectie preciezer te maken.
Statische analyse door Verify Apps
Door middel van statische analyse scant Google apps op bekende kwaadwaardige software. Daarbij wordt bijvoorbeeld gekeken naar onderdelen die voorkomen in bekende malware-apps en naar schadelijke functies in apps. Een ander voorbeeld is dat er gezocht kan worden naar telefoonnummer van bekende smsdiensten die gebruikt worden om gebruikers geld lichter te maken.
In 2015 is de statische analyse van apps flink uitgebreid, onder andere om nieuwe toepassingen in het App Security Improvement Program te kunnen faciliteren. Een voorbeeld daarvan is het scannen op de afhandeling van SSL-certificaten. Deze certificaten worden in apps gebruikt om een beveiligde verbinding met een server op te zetten, bijvoorbeeld een bankieren-app die verbindt met de servers van de bank. Wanneer apps zelf fouten in certificaten afhandelen, zijn ze in sommige gevallen kwetsbaar voor zogenaamde man-in-the-middle-aanvallen, waarbij een kwaadwillende zich voordoet als de server waarmee contact wordt gezocht. Zo kunnen aanvragen worden aangepast en kan verkeer worden afgeluisterd. Door de verbeteringen in statische analyse konden ontwikkelaars voor dit soort problemen worden gewaarschuwd.
Dynamische analyse door Verify Apps en SafetyNet
Niet alleen wordt er gekeken naar mogelijk schadelijke code, maar apps worden ook na installatie in de gaten gehouden. Google gebruikt hiervoor neptoestellen op zijn servers. Deze emulatoren draaien dan de app en imiteren het gedrag van gebruikers.
Voor Google is het een uitdaging om kwaardaardige apps te misleiden. Vanaf het moment dat malwaremakers in de gaten kregen dat Google hun apps ook ná installatie nog in de gaten hield, begonnen ze met het ontwikkelen van detectiemethodes. Zo werden de kwaadaardige functies niet ingeschakeld wanneer de app detecteerde op een nep-toestel te draaien. In 2015 heeft Google verschillende verbeteringen doorgevoerd om detectie te voorkomen. Daarbij gebruik het bedrijf de natuurlijke diversiteit in Android-toestellen als camouflage en als detectiemechanisme. Er worden namelijk veel verschillende toestellen gesimuleerd en als een app op verschillende toestellen en onder verschillende omstandigheden op een andere manier reageert, kan dat een indicatie van een detectiemechanisme zijn.
Een andere uitdaging is dat bij veel apps de functionaliteit lastig geautomatiseerd te bekijken is. Wanneer een app voorbeeld pas opstart wanneer er door de gebruiker is ingelogd, dan zal de dynamische analyse niet veel informatie opleveren. In 2015 heeft Google daarom de statische analyse dusdanig uitgebreid dat er voorbereidende informatie verzameld wordt voor de dynamische analyse.
In 2015 zijn er ook volledig nieuwe onderdelen toegevoegd aan de dynamische analyse. Zo worden apps nu ook uitgeprobeerd door Google-medewerkers. Door deze analisten te gebruiken als aanvulling op de automatische scans, kunnen apps veel grondiger gecontroleerd worden. Daarbij wordt de data van de medewerkers gebruikt om de dynamische controle te verbeteren.
Ook nieuw is het gebruik van zogenaamde honeypots. Dit is een verzameling data die echt lijkt, maar samen is gesteld om kwaadwillenden te lokken. Door deze data te gebruiken, kan Google misbruik van bijvoorbeeld persoonsgegevens detecteren. Een voorbeeld daarvan is het versturen van spam naar e-mailadressen die in een apps zijn ingevuld. Er worden sinds afgelopen jaar ook verbanden gezocht tussen apps van verschillende ontwikkelaars. Volgens Google is gebleken bij ontwikkelaars die één mogelijk schadelijke app uitbrengen het risico groot is dat er meerdere schadelijke apps uitgebracht worden. Het was al mogelijk om alle apps van een ontwikkelaars automatisch te blokkeren en vanaf 2015 kan Google ook verbanden tussen ontwikkelaars-accounts ontdekken en herleiden naar één malwaremaker. Daarnaast worden bekende ‘Command&Control’-servers, die bijvoorbeeld botnets en andere besmette toestellen aansturen, beter in de gaten gehouden.
Google gebruikt sinds 2015 ook nieuwe machine learning-mogelijkheden om overeenkomsten in apps te herkennen. Het kan dan bijvoorbeeld gaan om kwaardaardige apps die een populaire app imiteren. Gegeven het aantal MSQRD-klonen dat in de Google Play Store te vinden is, is deze aanpak verre van waterdicht. Er wordt op een paar manieren gekeken naar overeenkomsten, onder andere door te kijken naar gelijkenissen in logo’s van apps. De techniek wordt ook gebruikt om malware-ontwikkelaars aan meerdere accounts te koppelen, doordat overeenkomsten in afbeeldingen en code beter kunnen worden gedetecteerd.
Risicogroepen en afwijkende systemen
SafetyNet gebruikt geanonimiseerde data van meer dan 1 miljard Android-apparaten om zo afwijkingen te kunnen detecteren. Deze data is afkomstig uit geautomatiseerde scans die alleen worden uitgevoerd als een toestel aan de oplader ligt en voldoen opgeladen is.
Aan het einde van vorig jaar heeft Google dit uitgebreid met de zogenaamde Anomaly Correlation Engine. Deze detecteert veranderingen in beveiligingsindicatoren op deze Android-toestellen en onderzoekt daarbij welke apps veranderd zijn nadat het apparaat nog wel veilig was. Omdat er gebruik wordt gemaakt van een enorme dataset, kan zo vrij snel en accuraat worden bepaald welke apps voor een bepaalde verandering gezorgd hebben.
Google gebruikt de informatie uit de Anomaly Correlation Engine bijvoorbeeld om te ontdekken welke apps gebruikt worden om root-toegang te krijgen, maar ook om te kijken welke kwaadaardige apps veranderingen aanbrengen in het systeem, een gedeelte van Android waar apps normaal geen toegang toe hebben.
Om afwijkingen te detecteren, gebruikt Google een database van bekende systeem-partities van Android-toestellen. Het bedrijf heeft meer dan 60.000 systeempartities in zijn database staan die door meer dan 1.000 actieve toestellen gebruikt worden en 175.000 unieke systeempartities in totaal. Wanneer een afwijkende partitie gevonden worden, wordt het toestel gescand, waarna de afwijkende apps kunnen worden gevonden. Op deze manier wordt malware die zich in het systeem nestelt eenvoudig en snel ontdekt.
Om het scannen op kwaadaardige software en apps zo efficiënt mogelijk te kunnen doen, identificeert Google toestellen die een verhoogde risicofactor hebben. Daarbij geeft het bedrijf als voorbeeld dat toestellen van mensen die Russisch als taal hebben ingesteld en apps van buiten de Play Store om installeren, vijf keer meer risico lopen om mogelijk schadelijke apps te installeren. Deze toestellen worden dan ook vaker gescand, tot soms wel één keer per dag waar het wereldwijde gemiddelde op één keer per week ligt. Volgens Google heeft dit tot een vermindering van het installeren van mogelijk schadelijke apps van 80% geleid.
Grootste risico’s
Volgens Google zijn schadelijke apps het grootste beveiligingsrisico op Android, maar er zijn meer risicofactoren. Het bedrijf probeert deze zo goed mogelijk af te vangen met de maatregelen die we vandaag besproken hebben, maar dat betekent uiteraard niet dat het risico nihil is. In het tweede deel van deze artikelserie bespreken we wat de grootste beveiligingsproblemen van 2015 waren en hoe deze verholpen of verkleind zijn.
Reacties
Inloggen of registreren
om een reactie achter te laten
Interessant artikel… Het draaien van een virusscanner in android is dus eigenlijk onzin, aangezien google de apps al scant in de cloud?
Blijkbaar Ben ik niet zo beveiligd op de huawei G525 met android 4.1…