Android Security

Auteur
Rick Buiten
Datum

Android security

In mijn werk als software engineer ben ik steeds vaker bezig met het onderwerp beveiliging. Een slechte beveiliging kan zorgen voor een slechte naam en probeer dat maar eens goed te krijgen. Beveiliging wordt daardoor steeds belangrijker in ons werk. Als Android developer moet je hier ook goed rekening mee houden. Android is op bepaalde manieren makkelijk te hacken. Als je dit weet kun je je hier goed tegen beschermen. In dit blog leg ik uit hoe je dit doet. Vervolgens leg ik uit hoe je er tegen kunt wapenen. Je kunt voor de verschillende testen je eigen telefoon gebruiken, maar het is in de meeste gevallen verstandiger om een geroot test device te gebruiken. Je Android device wordt anders ook vatbaarder voor misbruik door andere apps.

Beveiligingsrisico netwerk verbindingen

De grootste beveiligingsrisico tijdens het versturen van data naar een server is een man-in-the-middle attack. Dit is de manier om de data tussen de telefoon en de server te onderscheppen, uit te lezen en eventueel aan te passen zonder dat de gebruiker dat merkt. Voor de gebruiker kan het daardoor gebeuren dat ze verkeerd geïnformeerd worden. Voor de ontwikkelaar kan het ook schadelijk zijn als bijvoorbeeld reclame banners wordt aangepast zodat niet de ontwikkelaar het geld krijgt voor de advertentie, maar de hacker.

Voor een goede man-in-the-middle attack is het noodzakelijk om het certificaat van de proxy tool die je gebruikt te installeren op je test device. Dit zorgt ervoor dat de verbinding tussen de telefoon en de proxy tool vertrouwd is. Hierdoor kun je naast HTTP verkeer ook alle HTTPS verkeer bekijken. Er zijn verschillende proxy tools beschikbaar, waaronder Charles proxy, OWASP ZAP en Burp Suite. Hoe je een man-in-the-middle attack doet is niet in scope van dit blog. Voor meer informatie over het configureren van Burp Suite kun je kijken op https://support.portswigger.net/customer/portal/articles/1841101-configuring-an-android-device-to-work-with-burp.

Als je de proxy tool gebruikt, kun je gelijk zien of de ontwikkelaars HTTPS vertrouwen. Als het certificaat van de proxy tool bekend is op het device, kun je de data gewoon lezen. In onderstaand test geval kun je het volgende zien:

Android Security image 1

In bovenstaand voorbeeld zie je dat de request een GET methode is waarbij de waardes via de url worden verzonden. Verder is de response goed te lezen en daardoor ook eenvoudig aan te passen voordat je het terug stuurt naar de gebruiker. Een netwerk verzoek via GET met daarin parameters is sowieso een fail. Dat is ten alle zichtbaar. Het maakt daarbij niet uit of je HTTP of HTTPS gebruikt.

Android Security image 2

In het bovenstaande voorbeeld gaat het wel goed. Hierbij is de data, die wordt verstuurt en ontvangen, geëncrypt verstuurd. Hierdoor is het niet te lezen en/of aan te passen zonder kennis te hebben van de encryptie techniek.

De oplossing

Een Man-in-the-middle attack kan altijd plaats vinden. Zorg er daarom voor dat de communicatie tussen de server en de app altijd encrypted is zoals je kunt zien in de vorige screenshot. Hackers hebben dan namelijk meer kennis nodig van de applicatie.

Een goede manier om een man-in-the-middle attack te voorkomen is om tijdens de bouw van een app een public-private sleutel te creëren. De public key wordt gebruikt om de data met RSA te encrypten. De data kan alleen gedecrypt worden met de private key. Daarom is het noodzakelijk dat deze alleen op de server bekend is en het liefste op een veilige plek. De geëncrypte data bevat onder andere een unieke gegenereerde sleutel. De server weet in het vervolg met welke sleutel de data versleuteld gaat worden. Deze gegenereerde sleutel weet je echter alleen als je de private key hebt, anders kun je namelijk het bericht niet decrypten en daardoor de volgende berichten ook niet.

Verder is het verstandig om certificate pinning en whitelisting van de urls te implementeren. Certificate pinning houdt in dat je, tijdens het versturen van een netwerk verzoek, gaat controleren of de certificaten die je terug krijgt klopt met datgene dat je verwacht en vertrouwd. Het white listen van de urls is bijna dezelfde check. Je geeft dan alleen aan welke urls je vertrouwd.

Beveiligingsrisico Config bekijken

Het is mogelijk om binnen een app configuratie instellingen op te slaan. Hiervoor wordt er een xml bestand op een bepaalde plek geplaatst. Als je telefoon geroot is kun je het bekijken en/of aanpassen. Je hebt hiervoor wel toegang nodig tot de telefoon.

Je kunt de configuratie uitlezen via het commando 'adb shell'. In de folder '/data/data//' staan alle belangrijke bestanden van een app.

Android Security image 3

In de shared_prefs folder staan vaak alle instellingen opgeslagen. Dit is uit te lezen zoals te zien is in het onderstaande voorbeeld:

Android Security image 4

Het is ook mogelijk om de tool Introspy ( https://github.com/iSECPartners/Introspy-Android) te gebruiken. Deze tool houdt bij of een app iets opslaat in de configuratie bestanden van de app. Zodra dit gebeurt schrijft Introspy dit weg in de log file. Dit is uit te lezen via logcat.

Android Security image 5

De oplossing

Zoals je kun zien is het eenvoudig, mits de telefoon geroot is, om de configuratie te bekijken. De oplossing is eigenlijk betrekkelijk eenvoudig. Het is namelijk op te lossen door de shared preferences te overschrijven en je eigen implementatie in te bouwen die de velden encrypt en decrypt. Als hulpmiddel raad ik aan om eens te kijken op https://github.com/scottyab/secure-preferences.

Het is wel verstandig om het ophalen van de shared preferences in een andere thread te doen. Het encrypten en decrypten kan een 'dure' operatie zijn en daardoor zorgen dat je app traag aanvoelt.

Beveiligingsrisico Code bekijken

Je weet nu hoe eenvoudig het is om het netwerk verkeer te bekijken. Het decompileren van code is misschien nog wel eenvoudiger. Dit kan op verschillende manieren. Als je telefoon geroot is kun je de apk file downloaden van je telefoon. De locatie is: /data/app/. Door middel van het commando 'adb pull' kun je het bestand downloaden. Vervolgens kun je via www.decompileandroid.com of andere (offline) tools de apk uitpakken.

Het is ook mogelijk om de code te bekijken zonder root rechten. Hiervoor kun je de app 'Show Java' downloaden uit de Play store. Als je de app opent kun je een andere app selecteren. Vervolgens wordt de code zichtbaar.

Zoals je merkt, kun je vrij eenvoudig de code bekijken. Een zoekfunctie op password / wachtwoord of iets dergelijk levert soms goede resultaten op:

Android Security image 6

De oplossing

Het bekijken van code kan een stuk lastiger worden gemaakt. Tijdens het compileren kun je namelijk de tool Proguard gebruiken om code aan te passen. De classes en methodes worden hernoemt naar niets zeggende namen, bijvoorbeeld a of b. Het is nog steeds mogelijk om de code te bekijken, maar het is nu onduidelijk wat er allemaal staat. Een voorbeeld van een class is het volgende:

public class a{
   private final boolean a;
   private final String b;

   public a(boolean flag, int i) {
       a = flag;
       b = Application.getGlobalApplicationContext().getString(i);
   }

   public a(boolean flag, String s) {
       a = flag;
       b = s;
   }

   public boolean a() { return a; }
   public String b() { return b; }
}

Tools

Naast bovenstaande code wijzigingen zijn er verschillende tools beschikbaar die je kunnen helpen bij het vinden van beveiligingsrisico's.

Android Studio

Android Studio heeft zelf de mogelijkheid om code te inspecteren. Veel voorkomende fouten kunnen hierdoor al snel opgelost worden. Met gradle kun je ook een html report laten generen door de taak 'lint' uit te voeren. Hierin staan vervolgens alle errors en warnings.

QARK

QARK staat voor Quick Android Review Kit. Deze tool is gemaakt om op verschillende beveiligingsissue te controleren. Het mooie is dat je dit op verschillende manieren kunt doen. Je kunt de APK file gebruiken, maar ook de source code zelf.

Deze tool is te downloaden via: https://github.com/linkedin/qark

Door het commando "python qark.py" uit te voeren worden er verschillende vragen gesteld, onder andere de locatie van de apk en source. Zodra je door de wizard heen bent krijg je een mooi rapport met daarop de mogelijke beveiligingsrisico's.

Conclusie

Zoals in dit blog staat beschreven zijn er grote gevaren aanwezig om gehackt te worden. Maar ook zijn er voldoende manieren om het voor hackers een stuk lastiger te maken, zo lastig zelfs dat de meeste in vroeg stadium zullen stoppen. Hou daarom, met iedere code change die je doet, rekening met de beveiligingsrisico's van je code. De tools die Android Studio standaard geeft en de tool QARK kunnen daarbij hele mooie hulpmiddelen zijn. Het is daarbij belangrijk dat je begrijpt wat je doet. Als je niet begrijpt wat je doet, kun je er beter in gaan verdiepen of aan het OS overlaten. Een man-in-the-middle attack kan bijvoorbeeld juiste makkelijker worden als je bepaalde checks verkeerd implementeert.

Tags

Security