© aigarsr, Fotolia

Android-Geräte rücken zunehmend in den Fokus von Angreifern. Bauliche Mängel in den Grundkonzepten von Googles Smartphone-System machen es leicht, auch an sensibelste Daten wie die TAN fürs Homebanking oder die Facebook-Credentials zu kommen. Dieser Artikel zeigt zwei Hacks und einen Lösungsvorschlag.

“Lieber Kunde, aus Sicherheitsgründen sind ab 31.12. die ausgedruckten TAN-Listen fürs Homebanking nicht mehr gültig. Stattdessen bitten wir alle unsere Kunden, auf Mobile TAN (mTAN) oder einen Kartenleser mit TAN-Funktion (chipTAN) umzustellen. Diese Systeme ermöglichen einen deutlich höheren Sicherheitsstandard”, so ähnlich heißt es in Schreiben, die Banken derzeit an ihre Kunden verschicken.

Sicherheitsrisiko M-TAN

Ein Smartphone hat heute fast jeder. Nicht zuletzt deshalb lassen sich viele Kunden auf das M-TAN-Verfahren ein, bei dem die für den erfolgreichen Abschluss einer Überweisung nötige Geheimnummer per SMS aufs Handy gelangt [1]. Der Bankkunde gibt die erhaltene, geheime Transaktionsnummer im Bankingportal im Browser ein, schon erfolgt die Überweisung. Zwei getrennte Kommunikationskanäle, das sei sicher, versprechen viele Banken. Doch Sicherheitsexperten raten mangels sicherer Smartphone-Betriebssysteme vom M-TAN-Verfahren dringend ab.

Zum Ärger der Konkurrenz, die M-TAN immer noch als uneingeschränkt sicheres Produkt anpreist, gesellt sich zu den Mahnern auch der Direct-Banking- und Wertpapierspezialist Cortal Consors. “Wir mussten für unsere Warnungen viel Prügel von anderen Banken einstecken, die das nicht so schlimm sehen”, erklärt ein Consors-Vertreter.

Die BNP-Paribas-Tochter aus Nürnberg veranstaltete sogar eine Vortragsreihe mit dem “Ex-Hacker” Gunnar Porada als Referenten. Der hat Erfahrung, sein Profil bietet eine lange Liste an Sicherheitslücken, die der Geschäftsführer der Schweizer Sicherheitsfirma Innosec [2] offengelegt hat. Er hackte live im ZDF – bei “WISO” – und enthüllte gravierende Unsicherheiten bei EC-Karten, dem elektronischem Personalausweis, in Reisepässen oder Fingerabdruck-Sensoren.

Eine simple Sache

Weil Cortal Consors nach eigener Aussage ein “sehr hohes Sicherheitsbedürfnis hat und Anwender sensibilisieren will”, durfte er in mehreren Workshops die Schwächen der Kombination Windows-PC und Android vorführen. Erschreckend leicht, so Porada, lassen sich moderne Smartphones kompromittieren.

“Technisch ist das gar nicht so aufregend, die Angriffsmöglichkeiten sind bekannt. Das Schwierigste für den Angreifer ist eher herauszufinden, welches Handy zu einem infizierten PC gehört”, erklärt der Ex-Hacker, der gerade 100 000 Euro vom Konto eines Konzerns zu einer gemeinnützigen Organisation transferiert hat, mit gefälschten Accounts und Webseiten, auf die er den Demo-Rechner vorher per DNS-Spoofing umgeleitet hat – natürlich nur als Demo fürs Publikum.

Auf dem Windows-PC geht Porada jedoch noch weiter: Hier fängt ein Keylogger Tastatureingaben ab, ein Command-and-Control-Server übernimmt derweil die Kommunikation mit dem Smartphone. Auf dem wird Malware die TAN-SMS abfangen und weiterleiten, bevor der Besitzer sie sieht.

Ein Angreifer könnte nun automatisiert und im Verborgenen beliebige Überweisungen tätigen, so weit es der Dispo des Opfers hergibt, eine Benutzerinteraktion ist nicht mehr nötig: Wie von Geisterhand füllt die Demo-Malware auf dem Beamer HTML-Formulare aus, gibt die ans Smartphone versendeten, klammheimlich abgefangen TANs ein und leert so nach und nach das simulierte Konto eines Opfers.

Nur eine Frage der Zeit

“Realistisch betrachtet ist der Schutz sehr gering, den die getrennten Kommunikationswege bieten, ganz egal was manche Banken sagen”, erklärt Porada im Gespräch mit dem Linux-Magazin. “Es ist nur eine Frage der Zeit, bis Angreifer ausreichend viele Verknüpfungen zwischen PC und Handy in ihren Datenbanken haben. Windows-PCs und Android-Smartphones zu infizieren und zu übernehmen ist dagegen eine leichte Übung.”

Typischerweise gelangt die Malware per Drive-by-Installation über bösartige Webseiten auf den PC oder das Smartphone, etwa über infizierte PDFs [3] oder Javascript-Fallen. “Und dann gibt es viele Schnittstellen zwischen den Geräten, die die von den Banken gepriesene Zwei-Wege-Kommunikation torpedieren. Denken Sie nur an E-Mail-Accounts, Synchronisation, den Anschluss des Geräts via USB oder gemeinsam genutzte WLANs. Auch die Information, dass kurz nachdem der Benutzer eine bestimmte Schaltfläche im Browser anklickt auf dem Smartphone eine SMS eingeht, kann Angreifern als Identifikationsmerkmal dienen.”

Vor allem das heimische Funknetz bietet dem Angreifer große Chancen, steht ihm hier doch unter Umständen die Rechenpower eines gehackten Windows-PCs zur Verfügung. Wer die Verwaltungssoftware hinter dem in [3] beschriebenen Ghostnet-Trojaner oder die in Metasploit & Co. eingebauten Exploit- und Profiling-Mechanismen unter die Lupe nimmt, erkennt, dass es nur eine Frage der Zeit ist, bis Angreifer vom Windows-PC aus Smartphones übernehmen.

Das Problem wäre weitaus geringer, gäbe es ein sicheres Betriebssystem für mobile Geräte. “Doch mit Android hat der Benutzer nicht den Hauch einer Chance, sich zu wehren”, konstatiert Porada. Die Sicherheitsmechanismen des mobilen Linux-Systems offenbaren “haarsträubende Lücken, die es einem Angreifer sehr leicht machen, auch an schützenswerte Informationen zu gelangen”. Deshalb rät er grundsätzlich vom M-TAN-Verfahren ab.

Die Zuhörer sich schockiert, doch so weit wie Porada will Veranstalter Cortal Consors nicht gehen: “Wir haben bisher keine Missbrauchsfälle feststellen müssen. Aber sobald das der Fall ist, werden wir aktiv. Bis dahin betrachten wir die Gefahr als gering”, sagt der Pressesprecher. Wie oft im Sicherheitsumfeld scheinen auch hier wirtschaftliche Erwägungen die wichtigere Rolle zu spielen. Wohl deshalb preist Cortal Consors das M-TAN-Verfahren auf seiner Webseite auch weiterhin als sicher an (Abbildung 1).

Abbildung 1: Etwas schizophren mutet an, dass Cortal Consors zwar auf seiner Webseite weiter für die Sicherheit des M-TAN-Verfahrens wirbt, es aber gleichzeitig auf einer Roadshow hacken lässt.

Kein Know-how nötig

Erschreckend ist auch, wie wenig Know-how nötig ist, um auf Android-Geräten an die eigentlich schützenswerten Daten zu kommen. In einem Workshop auf dem Zarafa Summercamp 2012 [4] zeigten Sicherheitsexperten, dass es keiner Hacker- oder Programmier-Erfahrung bedarf, um sensible Daten auszuspionieren.

Die im Workshop gefertigte Anwendung (Facebookthief, mittlerweile auch im Google-Play-Appstore erhältlich) ermittelt problemlos die Facebook-Credentials, die der Benutzer einer anderen App des Social-Networks-Universums zur Verfügung gestellt hat. Dabei offenbaren sich konzeptionelle Schwachstellen im mobilen Linux. “Google hat sich beim Android-Konzept selbst überschätzt”, stellt Gunnar Porada fest.

Das Vorgehen des Niederländers Paul Lammertsma (CTO des Sicherheitsexperten Pixplicity) ist denkbar einfach und kombiniert minimales Social Hacking mit einer eigenen, bewusst einfach gehaltenen App. Möglich macht das Ganze erst eine allzu freigiebige Standardeinstellung des Facebook-SDK: Der Marktführer in Sachen Social Web bietet Entwicklern ein Software Development Kit. Mit dem lassen sich eigene Anwendungen programmieren, die auf das Facebook-API zugreifen [5].

Hilfreich fürs Debugging, aber ungünstig für den Produktiveinsatz, ist, dass das Logging der damit entstandenen Apps standardmäßig auf »Debug« geschaltet ist – eine fatale Einstellung. Dank der ausführlichen Protokollierung der Apps tauchen so in den Logs der Android-Devices (einer Art Fifo-Speicher) auch die Credentials für den Facebook-Zugang in Form eines Token auf. Das dort herauszupicken, schafft jede App mit entsprechenden Zugriffsrechten.

Mit dem Token könnte ein Angreifer Identitätsdiebstahl betreiben und bei Facebook Daten ausspionieren oder Spam-Posts absetzen. Auch schlimmere Szenarien sind denkbar, nicht zuletzt darf ein Unbefugter auch vom Rechner aus über die Android Debug Bridge [6] auf die Logs zugreifen.

Bei Facebook funktioniert der Angriff aber nur, weil viele Programmierer von Zusatzapps für Facebook vergessen, den Loglevel nach dem erfolgreichen Abschluss der Entwicklung auf ein sicheres Maß zurückzustellen. Der Fehler ist recht verbreitet, Lammertsma nennt im Workshop eine Liste von Apps, deren Entwickler Angreifern diese willkommene Informationsquelle bieten.

Als dritte Voraussetzung muss hierbei aber auch der Handybesitzer mitspielen. Dabei schon von Social Hacking zu sprechen, greift jedoch deutlich zu weit: Die im Workshop flugs geschriebene, heruntergeladene und auf dem Android-Gerät kompilierte App (siehe Kasten “Hack-Praxis: Facebook-Credentials auslesen”) fragt bei der Installation ganz unschuldig nach der Erlaubnis, Zugriff aufs Systemprotokoll zu erhalten (Abbildung 2). Einer Anwendung das zu erlauben, erscheint nicht unmittelbar sicherheitskritisch, im Zweifel könnte sich das ja als nützlich erweisen. Dass übers Systemprotokoll sensible Logindaten gehen, entspricht nicht der Erwartungshaltung typischer Smartphone-Besitzer.

Abbildung 2: Unverdächtig: Die zu installierende App will Zugriff auf aufs Systemprotokoll.

Hack-Praxis: Facebook-Credentials auslesen

Der im Workshop [4] beschriebene Angriff braucht eine Internetverbindung. Auf dem Androiden sollte die Funktion, Apps aus unbekannten Quellen zu installieren, aktiviert sein (»Einstellungen | Anwendungen | Unbekannte Herkunft – Installation von Nicht-Market-Anwendungen zulassen« ). Dann installiert der Besitzer die Android-Java-IDE AIDE [7] auf seinem Gerät, einfach per Google Play.

Weiter geht’s per Git: Ein QR-Code führt zum direkten Download der App-Sourcen, erreichbar im Repository unter [8]. Jetzt kommt der schwierigste Teil, den die Präsentation der Autoren aber ausführlich zeigt: Der Smartphone-Besitzer kompiliert mit Hilfe von AIDE die App auf seinem Gerät, installiert sie und räumt ihr das Recht ein, aufs Systemprotokoll zuzugreifen (Abbildung 2).

Die Oberfläche der App ist simpel, sie besteht nur aus einem Ein-Aus-Schalter. Läuft das Programm, dann forkt »LogService.java« einen Logcat-Prozess [9]. Das Tool steht auch an der Android Debug Bridge zur Verfügung und überwacht das Systemprotokoll:

process = Runtime.getRuntime().exec(
 new String[] { "logcat", "-v", "time",
 "*:" + verbosity });

Den passenden regulären Ausdruck für das Facebook-Token gibt folgende Zeile in der Funktion »public static String getRegEx()« in der Datei »LogResult.java« zurück:

return "Login Success! access_ token=([^&\\s]+)";

Die App schnappt sich das Token und holt auch gleich Informationen über den angemeldeten User bei Facebook ab [10]. Abschließend präsentiert sie dem Anwender das Ergebnis (Abbildung 3). Für ernsthafte Angriffe ließe sich der Code zur Tarnung in eine unverdächtige App mit Nutzwert integrieren.

Abbildung 3: Die App Facebookthief hat erfolgreich Tokens abgefangen und Informationen eingeholt.

Google hat das Problem erkannt, ab Android 4.1 erhalten normale Apps keinen Zugriff mehr auf die Protokolle anderer Anwendungen. Aber dass die Hersteller der Android-Geräte die notwendigen, von Google meist zügig veröffentlichten Sicherheitspatches nur zögerlich auf die Smartphones bringen, vereinfacht die Sache für Angreifer. Nach 18 Monaten ist mit den Patches meist sowieso Schluss, denn zu dieser Laufzeit haben sich einige verantwortungsbewusste Hersteller im Google Update Program verpflichtet.

User-IDs und Sandkästen

Hinter der Erlaubnis zum Zugriff auf die Logs steckt eine der grundsätzlichen Tücken des Android-Systems: Standardmäßig läuft jede App mit einer eigenen User-ID, den Zugriff auf viele Systemressourcen regeln jedoch Group-IDs. Dass Google jede Anwendung in eine eigene Sandbox mit eigenen Benutzerrechten kapselt, trennt zwar die Apps relativ sicher voneinander, doch wer ihnen den Zugriff auf eine Systemressource wie die Logfiles einräumt, hebelt weite Teile dieses Konzepts aus – ein Kardinalfehler im Design. Im beschriebenen Beispiel ist der Protokoll-Fifo die Ressource, auf die mehrere Apps mit unterschiedlichen Zielen zugreifen.

Googles Android-Konzept gliedert sich in drei Schichten: unten der Linux-Kernel, darüber die Bibliotheken und das Runtime Environment, ganz oben die Apps. Auf den beiden oberen Ebenen kommt pro Anwendung die dedizierte Sandbox mit der für die App spezifischen User-ID zum Einsatz. Gruppenzugehörigkeiten regeln den direkten Lese- oder Schreibzugriff auf die Elemente der tieferen Ebenen. Meist wickelt jedoch die Middleware selbst die Zugriffe ab, mit eigenen Permissions, ohne das GID-UID-Konzept anwenden zu müssen.

Weitere Mechanismen, die den Zugriff auf Files, Sockets, Treiber oder andere schützenswerte Datenquellen einschränken, gibt es nicht. Das Projekt SE Android, das den Mangel vielleicht nachträglich lindern könnte, hilft auch nicht weiter, weil die Mandatory Access Controls (MAC) für das Middleware MAC Enforcement noch in den Kinderschuhen stecken [11].

So kann jeder Angreifer Daten abfangen, wenn er seine App auf dem Gerät installiert und vom Benutzer ein paar Zugriffsrechte erschlichen hat. Denkbar ist auch, dass unterschiedliche Apps über Netzwerksockets direkt miteinander kommunizieren. Googles Android Security Manual zufolge ist das ja sogar gewünscht: “Prozesse können über die traditionellen Unix-Mechanismen miteinander kommunzieren, zum Beispiel über das Dateisystem, lokale Sockets oder Signale. Aber die Linux-Rechte greifen dennoch.” [12]

Diese pauschale Freiheit hat weitreichende Konsequenzen: Wer beispielsweise mehrere Apps eines Herstellers installiert, diesen aber unterschiedliche Rechte einräumt, hebelt die einzelnen Beschränkungen vielleicht schon durch die gemeinsame Erlaubnis für den Netzwerkzugriff aus. Schlimmstenfalls kann dann ein Angreifer Anwendung A nutzen, um Kontakte zu lesen, mit Anwendung B die Speicherkarte durchforsten, die Informationen kombinieren und interessante Informationen mit Anwendung C sogar per SMS oder MMS verschicken – oder gleich übers Web.

Von Zeus zu Bizztrust

Das dies so einfach geht, blieb auch der Malware-Szene nicht verborgen. Bereits im September 2011 hat der Sicherheitsexperte Trusteer über Banking-Varianten des Trojaners Zeus für Symbian und Android berichtet. Dass diese erste Angriffsvariante drei Tage benötigt, bezeichnet Trusteer “angesichts der massiven Android-Schwächen” als “unverhältnismäßigen Overhead” [13].

Besser machte das ein halbes Jahr später die nächste Generation der Zitmo getauften Malware. Ihr Erfolg setzt aber immer noch die Interaktion seitens des Benutzers voraus. Der muss ein neues “Sicherheitszertifikat” fürs Homebanking auf dem Smartphone installieren, das aber keineswegs ein sicheres Zertifikat, sondern die Backdoor für den M-TAN-Trojaner installiert.

Das Fraunhofer-Institut für Sichere Informationstechnologie (SIT) hat die Bedrohung erkannt und arbeitet an einer Lösung. Die Probleme seien deutlich größer als gemeinhin bekannt, mahnt auch Professor Ahmad-Reza Sadeghi, unter dessen Leitung zwei Teams an der TU Darmstadt und dem Fraunhofer-Institut an dem Projekt Bizztrust arbeiten [15]. “Fast alle bisher bekannten Angriffe setzen voraus, dass Anwender auf Phishing- oder ähnliche Seiten hereinfallen und dann noch auf einem Smartphone Software installieren”, erklärt er dem Linux-Magazin. “Denkbar ist aber auch ein Angriff, der die von Banken als sicher bezeichnete Zwei-Wege-Kommunikation komplett aushebelt: Fast jeder Anwender benutzt sein Smartphone regelmäßig im heimischen WLAN.”

Auch mobile Antimalware-Software hilft nur bedingt, vor allem wenn Viren lernen, diese erfolgreich zu umgehen [16]. Zwar kann sie gegen bekannte Bedrohungen und Apps mit ungewöhnlichem Verhalten schützen. Dass die Probleme jedoch woanders liegen, bestätigt auch das Fraunhofer-Institut, für das Professor Sadeghi zusammen mit anderen Autoren das Sicherheitskonzept von Android durchleuchtet hat [17].

Die Studie legt den Finger tief in die Wunde: “Im Lichte der jüngsten Angriffe ist davon auszugehen, dass Android die Sicherheitsbedürfnisse der Unternehmenskommunikation nicht befriedigen kann.” Android lasse grundlegende Mängel erkennen, weder gebe es hier saubere Datentrennung noch ein Domainkonzept, mit dem sich Anwendungen in verschiedenen Sicherheitsstufen voneinander abschotten ließen.

Dass manche Hersteller wenig Wert auf saubere Treiberprogrammierung legen und Google erst 2012 anfing, Exploit-Mitigation-Techniken, die im Linux-Kernel lange üblich sind, auch in Android einzuführen, fällt dabei kaum mehr ins Gewicht. Nach Meinung der Studie ist der einzige sichere Ansatz ein neuartiges Android-System, das über alle Ebenen des Stack eine saubere Trennung einführt. Genau dies werde das Fraunhofer-Produkt Bizztrust [17] bieten.

Neben einem Domainkonzept (roter und grüner Bereich) setzt es auf Zertifikate, die einer zertifizierten App den Zugriff auf etwa das Unternehmensnetzwerk (auf dem Gerät ein Teil der abgesicherten roten Domain) erlauben. Ist sie nicht mit einem Zertifikat versehen, dann kann der Benutzer sie zwar installieren und benutzen, aber nur im grünen, dem unsicheren Umfeld. “Zwei Klicks auf dem Touchscreen, und der Anwender wechselt in die jeweils andere Umgebung”, wirbt das Fraunhofer-Institut.

Probleme überall

Doch auch dies löst das Problem sicherer Smartphone-Kommunikation noch lange nicht. VPN-Verbindungen und verschlüsselte Datenübertragungen müssen die Unzulänglichkeiten vieler Mobilfunkbetreiber kompensieren. Die setzen teilweise auf veraltete Stromchiffren zur Verschlüsselung der Telefonate und öffnen so Lauschern mit IMSI-Catchern Tür und Tor [18]. Apps wie Whatsapp erweisen sich trotz SSL als anfällig für einfache Man-in-the-Middle-Attacken [19]. Selbst Apples restriktive Softwarepolitik kann ähnliche Fehler auf dem iPhone nicht verhindern, wie ein Blick auf den jüngsten Flash-Exploit [20] oder die anhaltenden Probleme des iPhone im Umgang mit PINs [21] zeigt.

Ob die Zukunft Besserung bringt, scheint unwahrscheinlich: Neue mobile Bezahlmethoden und Kurzstreckenfunk wie die Near Field Communication (NFC) machen Smartphones und Tablets noch attraktiver und anfälliger für Hacker. Immerhin verschlüsseln iPhone 4 und Android 4 auf Wunsch die lokalen Datenspeicher. Eine Hoffnung für sicherheitsbewusste Smartphone-Besitzer ist, dass das Android-Konzept auch Lösungen wie Bizztrust ermöglicht. Unter I-OS ist dergleichen laut Fraunhofer nicht machbar, weil “Apple so tiefgreifende Änderungen im System nicht erlaubt”.