© prettyboy80/Shutterstock.com
Was wurde auf Sicherheitskonferenzen zu Android vorgestellt?

Androids Sicherheit aus Forschersicht


Im Mobile Technology 1.2014 [1] gab es einen Überblick über die Schadsoftware für Android. Und dabei sah es für Googles mobiles Betriebssystem gar nicht gut aus, denn es ist bei den Cyberkriminellen sehr beliebt. Aber was sagen denn die Forscher zur Sicherheit von Android?

Bevor ich zu den Sicherheitskonferenzen komme, ist leider ein unschöner Nachtrag zum Thema „Schadsoftware für Android“ nötig. Bisher hatte sich Android-Ransomware darauf beschränkt, die infizierten Geräte zu sperren und erst nach Zahlung eines Lösegelds wieder freizugeben. Diese Sperre ließ sich meist mehr oder weniger einfach aushebeln, sodass sich der Schaden in Grenzen hielt. Unter Windows ist schon seit Langem die Verschlüsselung vermutlich für den Benutzer wichtiger Dateien üblich. So einen Schädling gibt es nun auch für Android.

Simplocker – Vorbote einer neuen Gefahr für Android

Anfang Juni wurde von ESET die erste Ransomware für Android entdeckt, die bestimmte Dateitypen auf der Speicherkarte des Smartphones verschlüsselt: Simp­locker [2]. Der als Trojaner auf die Geräte kommende Schädling verschlüsselt alle Dateien mit den Endungen jpeg, jpg, png, bmp, gif, pdf, doc, docx, txt, av, mkv, 3gp und mp4. Die parallel angezeigte Lösegeldforderung ist in Russisch geschrieben, die Bezahlung soll in Ukrainischen Hrywnja erfolgen.

Der Trojaner wird von ESET als „a proof of concept or a work in progress“ eingestuft, vermutlich ist der jetzige Einsatz also nur ein Test des Schädlings. Dafür spricht auch die „Qualität“ der Verschlüsselung: Am 16. Juni hat Simon Bell, ein Informatikstudent an der University of Sussex, eine Analyse der Verschlüsselungsfunktion veröffentlicht [3]. Der Schädling nutzt zwar das sichere Verfahren AES, der dafür verwendete Schlüssel ist aber fest im Code vorgegeben. Daher konnte Simon Bell schon am 17. Juni ein Tool zur Entschlüsselung nachreichen [4].

Windows-Schädlinge sind schon weiter

Diese schnelle „Neutralisierung“ von Simplocker sollte aber nicht darüber hinweg täuschen, dass es nun eine weitere gefährliche Schädlingsart für Android gibt. Die ersten Dateien verschlüsselnder Ransomware-Schädlinge für Windows ließen sich auch mehr oder weniger leicht austricksen … bis die Cyberkriminellen zu sicheren Verfahren und Implementierungen gegriffen haben. Unter Windows lässt sich zum Beispiel kaum ein Schädling mehr mit dem verwendeten Schlüssel erwischen. Der zurzeit bekannteste Windows-Vertreter dieser Art ist Cryptolocker, und der verwendet das asymmetrische RSA-Verfahren mit einem individuell erstellten Schlüsselpaar.

Das Schlüsselpaar wird auf einem Server der Cyberkriminellen erzeugt, von dem der installierte Schädling den für die Verschlüsselung benötigten öffentlichen Schlüssel lädt. Der für die Entschlüsselung notwendige private Schlüssel bleibt bis zur Zahlung des Lösegelds auf dem Server. Daher gibt es keine Möglichkeit, die verschlüsselten Dateien ohne Mithilfe der Cyberkriminellen zu entschlüsseln [5].

Seien Sie vorsichtig!

Die Schadsoftware für Android wird also nicht nur ständig mehr, sondern auch gefährlicher. Es dürfte nicht lange dauern, bis die erste Dateien verschlüsselnde Ransomware erscheint, deren Verschlüsselung nicht zu brechen ist. Achten Sie also darauf, nur Apps aus zuverlässigen Quellen zu installieren. Auch wenn das keine wirkliche Garantie dafür ist, dass darin nicht doch Schadfunktionen enthalten sind.

Aber kommen wir jetzt zu den auf Sicherheitskonferenzen vorgestellten Angriffen auf und Analysen von Android. Da es gerade noch um Schadsoftware ging – wie analysiert man die eigentlich auf einem Android-Gerät?

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 [6]. 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 Rechten 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 Re­verse Engineering von Android-Schädlingen beschrieben [7]. 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 Rahm...

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

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang