© DrHitch/Shutterstock.com
Android Security

2 Androids Sicherheit aus Forschersicht


Da es gerade noch um Schadsoftware ging – wie analysiert man die eigentlich auf einem Android-Gerät? Hierzu kommen wir nun zu den auf Sicherheitskonferenzen vorgestellten Angriffen und deren Analyse.

Die Analyse mobiler Schadsoftware

Alex Kirk von Sourcefire VRT hat auf der „Hack in the Box“ Malaysia 2011 beschrieben, wie mobile Schädlinge analysiert werden können [1]. Die Antwort auf die Frage „Wie analysiert man Schadsoftware auf einem Android-Gerät?“ ist ganz einfach: Gar nicht. Stattdessen nimmt man eine virtuelle Maschine, auf der Android installiert ist.

Aber bevor Alex Kirk das beschrieben hat, ging es erst einmal um die Grundlagen: Was ist ein APK eigentlich (eine ZIP-Datei mit anderem Namen), und was hat es mit der Datei AndroidManifest.xml auf sich (das ist keine XML-, sondern eine DBase-IV-Datei mit XML-Daten und zusätzlichen Einträgen, sodass sie mit DBase-IV-Tools nicht bearbeitet werden kann)?

Danach ging es um die Berechtigungen der Apps, die mitunter in die Irre führen können. Eine der möglichen Berechtigungen einer Android-App ist auf den ersten Blick beängstigend: CALL_PHONE. Sie erlaubt es einer App, ein Telefonat zu starten, ohne das normale Dialer-Interface zu durchlaufen, in dem der Benutzer dem Anruf zustimmt. 98 von 877 bösartigen Apps verlangen diese Berechtigung – aber auch zum Beispiel die ING-Direct-Banking-App. Ist die also auch bösartig? Natürlich nicht! Des Rätsels Lösung ist ganz einfach: Die betreffenden harmlosen Apps verwenden einen eigenen Dialog statt des Standardinterfaces, um den Benutzer um Zustimmung zu bitten. Trotzdem (oder gerade deswegen) benötigen sie natürlich die Berechtigung, das Standardinterface zu umgehen.

Die meisten Apps, die diese Berechtigung verlangen, verwenden sie überhaupt nicht. Das Gleiche gilt für viele andere Berechtigungen. Als Beispiel nennt Kirk eine App, die eine lange Liste an Berechtigungen anfordert – aber dann nur zwei davon überhaupt verwendet.

Generell lässt sich aus der Anzahl der angeforderten Rechte nicht unbedingt auf die Bösartigkeit einer App schließen. Ein Beispiel dafür ist eine „Porno-Player“-App, die nur eine einzige Berechtigung verlangt: SEND_SMS. Die kommt den Benutzer aber teuer zu stehen, da die App damit im Hintergrund unbemerkt vom Benutzer teure Premiumdienste nutzen kann.

Gerade diese Funktion kann mit einem Emulator nicht so einfach getestet werden, da der Emulator nicht mit einem Telefonnetz verbunden ist. Der Android-Emulator kann jedoch so konfiguriert werden, dass er Textnachrichten an einen anderen Emulator sendet. Ob sich damit bösartige Apps erkennen lassen, wurde von Alex Kirk jedoch nicht getestet.

Nach dem Manifest und den Rechten einer App geht Alex Kirk auf die Umwandlung des Codes in Classes.dex in Java-Code ein. Die ist noch nicht besonders hilfreich, wenn der Java-Code getarnt („obfuscated“) ist. Am Beispiel eines SMS-Trojaners beschreibt Kirk, wie man der bösartigen App trotzdem auf die Schliche kommt.

Damit stellt sich die Frage, was eigentlich besser ist: eine statische oder eine dynamische Analyse der App? Eine statische Analyse scheitert schnell an einer Obfuscation, außerdem ist sie langsam und schwieriger. „Gucken, was passiert“ geht dagegen recht schnell.

Für eine dynamische Analyse kann das Android SDK verwendet werden. Apps aus Android-Märkten werden über den Umweg über ein echtes Android-Gerät installiert, Apps aus dem Web können direkt in den Emulator heruntergeladen werden. Nach der Installation und dem Start der App kann dann zum Beispiel mittels Wireshark oder tcpdump der Netzwerkverkehr der App überwacht werden. So lässt sich schnell feststellen, ob die App unerwünscht Daten verschickt und wenn ja, welche das sind. Das Ganze wird am Beispiel einer echten Schadsoftware beschrieben.

Reverse Engineering von Android-Schädlingen

Ebenfalls auf der „Hack in the Box“ Malaysia 2011 hat Mahmud Ab Rahman von MyCERT das Reverse Engineering von Android-Schädlingen beschrieben [2]. Im Grunde behandelt er die von Alex Kirk nur relativ kurz behandelte Rückwandlung der .dex-Datei in lesbaren Assembler- oder Java-Code, wobei sich auch Mahmud Ab Rahman teilweise kurz fassen musste, aber jeweils auf entsprechende weiterführende Informationen verwies. Als Beispiel dient wieder echte Schadsoftware:

  • Ein SMS-ausspähender Trojaner,
  • „DreamDroid“ oder „Droid Dream“, ein Trojaner, der es 2011 sogar in Googles Android-Market geschafft hat [3],
  • die erste Mobile-Variante des Schädlingsbaukastens Zeus [4] und
  • die Android-Version von SpyEye, Zeus ständigem Konkurrenten [5].

Ausgehend von diesen Beispielen führt Mahmud Ab Rahman dann noch die Probleme beim Reverse Engineering von Android-Apps auf.

Beide Vorträge sind zwar schon relativ alt, aber immer noch aktuell. 2011 war der „Markt“ der Schadsoftware zwar kleiner und übersichtlicher als heute, das Grundproblem ist aber immer das gleiche: Trojaner tun nicht das, was sie angeblich tun sollen, oder zumindest nicht nur. Und um sie zu erkennen, ist die Überwachung ihrer Kommunikation ein guter Ansatz. Denn jede Schadsoftware (abgesehen von Schädlingen, die „nur“ randalieren sollen) muss mit den zugehörigen Cyberkriminellen kommunizieren. Sei es, um Anweisungen abzuholen, ausgespähte Daten abzuliefern oder ohne Wissen des Benutzers kostenpflichtige Dienste zu nutzen. Unerwartete Verbindungen zu unbekannten Servern sind daher meist ein guter Hinweise darauf, dass da etwas im Gange ist, was nicht im Interesse des Benutzers ist.

Aber kommen wir zu aktuelleren Ergebnissen. Wie sieht es denn mit Angriffen auf Android-Schwachstellen aus?

Angriffe auf ART

Paul Sabanal von IBM X-Force Advanced Research hat auf der „Hack in the Box“ Amsterdam 2014 die Sicherheit der in Android KitKat enthaltenen neuen experimentellen virtuellen Maschine ART unter die Lupe genommen [6]. ART erlaubt das Kompilieren von Dalvik-Bytecode in nativen Code „ahead of time“ und beschleunigt damit die Ausführung von Android-Apps. ART soll Dalvik ersetzen – man sollte also frühzeitig nach möglichen Angriffen darauf suchen. Denn mögliche Schwachpunkte sollten besser behoben werden, solange ART sich noch im experimentellen Stadium befindet.

Nach einer kurzen Einführung in ART werden ausführlich die „Ahead of time“-Kompilierung und das für das Ergebnis verwendete OAT-Dateiformat beschrieben. Nach diesen Vorarbeiten geht es dann um das eigentliche Thema: mögliche Schwachstellen in ART.

Los geht es mit möglichen Schwachstellen im Compiler. Neue Technologien und neuer Code füh...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang