Ergebnisse eines Android-Sicherheitschecks erschrecken

fixer00, 123RF

Ziemlich löchrig

Mittlerweile existieren mehr als 900 000 Apps für Smartphones, die unter Android laufen. Viele tauschen auch sensible Informationen über das Internet aus. Welche Sicherheit bieten sie dabei? Die Leibniz Universität Hannover und die Philipps-Universität Marburg haben gemeinsam mehr als 13 500 beliebte und kostenlose Android-Apps von Googles PlayStore analysiert.
ADMIN 11/13 stellt die besten Lösungen vor und klärt, ob Browser-Plugins, Anonymisierer sowie Verschlüsselung wirklich helfen. Weitere Themen: Small ... (mehr)

Das Secure-Socket-Layer-Protokoll (SSL) wird oft benutzt, um die Übertragung von Informationen zwischen Android-Apps und Servern im Internet zu sichern. SSL identifiziert dabei zum einen den Kommunikationspartner und verschlüsselt zum anderen die übertragenen Informationen, um sie vor dem Abhören und Manipulation zu schützen. Dabei beruht die Sicherheit mobiler Apps ganz wesentlich auf der eindeutigen Identifizierung des Zielservers im Internet, mit dem die App kommuniziert. Dafür überträgt der Server beim Verbindungsaufbau ein SSL-Zertifikat, das die Android-App validiert. Die Validierung beinhaltet folgende Fragen:

  • Wurde das Server-Zertifikat von einer vertrauenwürdigen »Certificate Authority« (CA) unterzeichnet?
  • Wurde das Server-Zertifikat für den Internet-Host ausgestellt, mit dem gerade kommuniziert wird?
  • Ist das betreffende Zertifikat bereits abgelaufen?

Zusätzlich sollte geprüft werden, ob das Zertifikat und seine dazugehörige Zertifikatskette widerrufen wurde. Widerrufenen Zertifikaten darf nicht mehr vertraut werden.

Die Standardimplementierung der Zertifikatsvalidierung in Android-Apps führt diese Schritte korrekt aus. Apps können jedoch auch eigene Strategien zur Zertifikatsvalidierung implementieren und die könnten dann durchaus für sogenannte Man-In-The-Middle-Angriffe (MITMA) anfällig sein.

Bei einem MITMA ist der Angreifer in der Lage, Nachrichten zwischen den Kommunikationspartnern abzufangen, indem er sein eigenes SSL-Zertifikat in den Verbindungsaufbau einschleust und dadurch ausgetauschte Informationen entschlüsselt und verändert. MITMA stellen für Smartphones und Tablet-PCs eine größere Gefahr dar als für traditionelle Desktop-Computer, weil die Mobilgeräte häufiger in unbekannten und weniger vertrauenswürdigen Umgebungen genutzt werden. Speziell die Nutzung offener WLAN-Netze machen MITMA gegen mobile Geräte zu einer ernsthaften Bedrohung.

Eine weitere Gefahr geht vom sogenannten SSL-Stripping aus, mit dem sich ein MITM-Angriff gegen eigentlich geschützte SSL-Verbindungen durchführen lässt. Der Angriff beruht darauf, dass viele SSL-Verbindungen erst durch den Klick auf einen Link eingeleitet oder über eine nicht durch SSL geschützte Seite umgeleitet werden. Während des SSL-Strippings ersetzt der Angreifer HTTPS-Links auf geschützte Seiten durch unsichere HTTP-Links. Der Angreifer kann im Anschluss – solange der Benutzer nicht merkt, dass die Links geändert wurden – sämtlichen SSL-Schutz umgehen. Dieser Angriff ist besonders bei einem Erstkontakt zu einem Server relevant.

Die Ergebnisse der hier diskutierten Studie machen deutlich, dass viele Millionen Nutzer von Android-Apps gefährdet sind, weil sie sensible Informationen über unzureichend geschützte Kommunikationskanäle im Internet austauschen.

Netzwerkkommunikation in Android-Apps

Das Android-SDK bietet komfortable Möglichkeiten für den Netzwerkzugriff. Die »java.net« -, »android.net« - und »org.apache.http« -Pakete sind verwendbar, um direkte Netzwerksockets oder HTTP(S)-Verbindungen aufzubauen. Das »org.webkit« -Paket bietet zudem Zugriff auf Webbrowserfunktionen. Alle diese Möglichkeiten für den Netzwerkzugriff erlauben es, die SSL-Zertifikatsvalidierung den Bedürfnissen der App-Entwickler anzupassen. In diesem Fall müssen Entwickler aber selbst sicherstellen, dass SSL-Zertifikate ausreichend sicher überprüft werden.

Kontrollen laufen ins Leere

Die Analyse-Ergebnisse haben gezeigt, dass dies häufig nicht der Fall ist. Es fanden sich folgende gefährliche Validierungsstrategien für SSL-Zertifikate in Apps:

  • Vertraue allen Zertifikaten: Zertifikatsvalidierung kann mithilfe des TrustManager-Interface derart implementiert werden, dass allen Zertifikaten, ungeachtet ihrer Signatur, vertraut wird.
  • Erlaube alle Hostnamen: Wurde die Signatur geprüft, so kann dennoch die Hostname-Verifikation fehlerhaft sein. Es wird dann zum Beispiel ein für »some-other-domain.com« vergebenes Zertifikat akzeptiert, obwohl auf den Server »example.com« zugegriffen wird und es für diesen Server nicht gültig ist.
  • Vertraue vielen Wurzelzertifikaten: Obwohl dies nicht notwendigerweise ein Sicherheitsproblem darstellt, vertrauen aktuelle Android Apps standardmäßig mehr als 130 Wurzelzertifikaten (oft auch »Root-Zertifikate« genannt). Die Angriffe auf einige große Certificate Authorities (CAs) im Jahr 2011 und die aktuelle Entwicklung im Hinblick auf Spionageprogramme der NSA machen ein solches Standardverhalten besonders problematisch.
  • Mixed Mode/Kein SSL: App-Entwickler können sichere und unsichere Verbindungen in einer App mischen oder SSL gar nicht verwenden. Dies ist kein direktes Problem von SSL, aber dennoch relevant, da der Endanwender nicht feststellen kann, ob eine sichere Verbindung genutzt wird oder nicht. Dieses Verhalten macht es dem oben beschriebenen SSL-Stripping-Angriff besonders einfach.

Die Flexibilität, die Android seinen Entwicklern bietet, führt allerdings nicht zwingend zum häufigen Missbrauch der SSL-Zertifikatsvalidierung, den die Forscher aufdeckten. Sie eröffnet auch die Möglichkeit, die Sicherheit von SSL im Vergleich zum Standardverhalten zu erhöhen. Eine zentrale Strategie ist SSL-Pinning. Dabei können sowohl eine kleinere Liste von vertrauenswürdigen CAs, eine benutzerdefinierte Liste von speziellen CAs oder sogar selbst signierte Zertifikate auf sichere Art und Weise verwendet werden.

Obwohl durch die Benutzung von SSL viele Sicherheitslücken entstehen können, soll an dieser Stelle betont werden: Die Benutzung eines durch SSL gesicherten Kanals, auch mit den zuvor beschriebenen Schwachstellen, ist gegen einen passiven Angreifer immer noch sicherer, als komplett auf kryptographische Techniken zu verzichten.

Sicherheitsanalyse von Android-Apps

Im Rahmen einer Sicherheitsanalyse wurden 13 500 beliebte und kostenlose Apps aus Googles PlayStore untersucht. Zur Analyse entwickelten die Untersucher basierend auf dem Androguard Reverse Engineering Framework [1] das Tool MalloDroid, das automatisch eine statische Code-Analyse von Android-Apps durchführt und fehlerhafte Implementierungen der SSL-Zertifikatsvalidierung identifiziert. MalloDroid ist unter [2] frei verfügbar und kann als Werkzeug im Rahmen der Sicherheitsanalyse von Android-Apps verwendet werden.

Die Untersuchungen kamen zu folgenden Ergebnissen: Mehr als 88 Prozent der getesteten Apps greifen auf das Internet zu. Mehr als die Hälfte (51 Prozent) der untersuchten Apps greifen auf das Internet zu und fordern weitere Privatsphäre-relevante Rechte an, wie Kalender, Kontakte, Browser-Verlauf, Profilinformationen, soziale Streams, Kurznachrichten oder exakte geografische Position des Benutzers. Diese Apps können potenziell sensible Informationen über das Internet übertragen. Weitere Apps, die die Privatsphäre betreffende Informationen verarbeiten, sind solche für Banking, E-Mail, soziale Netzwerke und Instant Messaging.

Zu wenige nutzen HTTPS

Mehr als 90 Prozent aller Aufrufe der Netzwerk-API nutzen HTTP- oder HTTPS-Verbindungen. MalloDroid extrahierte mehr als 200 000 Web-URLs, darunter aber nur knapp 30 000 HTTPS-URLs, der Rest verwendete HTTP. Eine weitere Analyse ergab, dass 76 000 URLs, die HTTP benutzten, auch über das verschlüsselte HTTPS-Protokoll erreichbar gewesen wären. Das heißt, dass 73 Prozent der getesteten Apps durch das einfache Einfügen eines einzigen Buchstabens, eine sichere Verbindung hätten nutzen können.

Insgesamt 46 Prozent der Apps griffen sowohl auf HTTP- als auch HTTPS-URLs zurück, während 43 Prozent nur HTTP-URLs verwendet haben. Lediglich 0,8 Prozent der Apps setzten ausschließlich HTTPS ein und verschlüsselten ihre Kommunikation komplett.

Um die Gültigkeit der verwendeten SSL-Zertifikate zu überprüfen, luden die Forscher die Zertifikate aller aus den Apps extrahierten HTTPS-Hosts herunter. Das waren insgesamt 1900 unterschiedliche SSL-Zertifikate, von denen 8 Prozent die Standardvalidierung von Android für Zertifikate nicht bestanden haben. Diese wurden in insgesamt 668 Apps verwendet.

Mit Hilfe von MalloDroid konnten in allen untersuchten Apps mehr als 3400 App-spezifische SSL-Implementierungen gefunden werden. Diese erstreckten sich über 1074 Apps, die Code enthielten, der die SSL-Verifikation vollständig durch das Akzeptieren aller Zertifikate (790 Apps) oder das Akzeptieren aller Hostnames (284 Apps) aushebelte.

Sicherheit ausgehebelt

Während ein App-Entwickler, der alle SSL-Zertifikate akzeptieren möchte, das TrustManager-Interface implementieren muss, ist für das Erlauben aller Hostnames für eine SSL-Verbindung, lediglich die Benutzung des »AllowAllHostnameVerifier« nötig. Die Implementierung einer eigenen HostnameVerifier-Klasse ist allerdings auch möglich.

Um nachzuvollziehen, wie Entwickler benutzerdefinierte SSL-Implementierungen einsetzen, wurden Apps analysiert, die spezielle TrustManager- und HostnameVerifier-Implementierungen beinhalteten. Die Forscher fanden 86 unterschiedliche benutzerdefinierte TrustManager-Implementierungen in 878 Apps. In über 90 Prozent der Fälle, in denen eine App-spezifische SSL-Zertifikatsvalidierung implementiert wurde, war das Resultat, dass die Zertifikatsvalidierung komplett ausgeschaltet wurde, so dass alle betroffenen Apps für die eben beschriebenen Man-In-The-Middle-Angriffe anfällig waren. Abbildung 1 zeigt eine typische Implementierung, die den Hostname eines Zertifikats nicht validiert.

Abbildung 1: Diese Implementierung akzeptiert sämtliche Zertifikate für eine SSL-Verbindung und schützt damit nicht vor Man-In-The-Middle-Angriffen.

Verräterische Namen

Passenderweise fanden sich für die meisten fehlerhaften Implementierungen entsprechende Klassennamen: »FakeHostnameVerifier« , »NaiveHostnameVerifier« und der »AcceptAllHostnameVerifier« akzeptieren beispielsweise alle Hostnames, während TrustManager-Implementierungen wie »AcceptAllTrustManager« , »DummyTrustManager« , »EasyX509TrustManager« oder »PermissiveX509TrustManager« die Zertifikatsvalidierung gleich ganz ausschalten.

Diese kleine Anzahl von kritischen Klassen betrifft eine große Anzahl von Apps. Viele der obigen Klassen gehören zu häufig verwendeten Bibliotheken und Frameworks. Ganze 313 Apps verwenden die »NaiveTrustManager« -Klasse, die von einer »Crash Reporting Library« angeboten wird. In 90 Apps wurde die »NonValidatingTrustManager« -Klasse verwendet – angeboten von einem SDK zur Entwicklung mobiler Apps für verschiedene Plattformen. Der »PermissiveX509TrustManager« wurde in einer Bibliothek zum Versenden verschiedener Arten von Push-Benachrichtigungen an Android-Geräte, eingebunden in 76 Apps, gefunden. Der »EasyX509TrustManager« ist Teil einer Bibliothek, die einfache und zuverlässige Netzwerkverbindungen für Android-Apps verspricht und in einem Großteil der missbräuchlichen Implementierungen gefunden wurde. Die bisherigen Ergebnisse wurden mit Mitteln der statischen Code-Analyse erzielt und zeigen nur das Potenzial für Sicherheitsprobleme durch nicht korrekt validierte SSL-Zertifikate auf. Die Tatsache, dass unsicherer SSL-Code in einer App enthalten ist, bedeutet allerdings nicht zwangsweise, dass darüber auch sensitive Informationen übertragen werden.

Welche Informationen sind wirklich gefährdet?

Aus diesem Grund wurde eine zweite, detailliertere Analyse angeschlossen, um festzustellen, welche Benutzerinformationen tatsächlich gefährdet sind. Zu diesem Zweck installierten die Untersucher Apps auf einem Android-Smartphone und führten Man-In-The-Middle-Angriffe gegen diese Apps durch. Sie konzentrierten sich dabei auf Apps aus den Kategorien Finanzen, Geschäftliches, Kommunikation, Soziale Netzwerke und Werkzeuge, da sie hier besonders kritische Informationen vermuteten. Aus den 260 Apps, die im ersten Schritt der Untersuchung in diesen Kategorien als mögliche Ziele identifiziert wurden, wählten die Forscher die 100 populärsten Apps für einen manuellen Angriff aus.

Für die Durchführung des Angriffes wurde ein Samsung Galaxy Nexus mit installiertem Android 4.0 Ice Cream Sandwich verwendet. Die potenziell fehlerhaften Apps wurden installiert und die SSL-Verbindung über einen speziellen WLAN-Accesspoint via MITMA angegriffen. Abhängig von der untersuchten Schwachstelle wurde der dabei verwendete Proxy entweder mit einem selbstsignierten Zertifikat oder mit einem Zertifikat einer CA ausgestattet, das jedoch für einen anderen Hostnamen ausgestellt war.

Von den 100 angegriffenen Apps, enthielten 41 ausnutzbare Schwachstellen. Die Tester konnten erfolgreich Bankdaten, Zugangsdaten zu Geldtransferdiensten wie PayPal, American Express, Zugangsdaten zu Facebook, Email und Cloud-Speicherdiensten sowie Instant-Messaging-Anbietern abfangen und mitlesen. Schwachstellen wurden meist in Drittanbieter-Apps gefunden. Aber auch die Apps einiger namhafter Hersteller waren betroffen. Anmerkung: Alle betroffenen Hersteller wurden informiert und haben in der Zwischenzeit alle gefundenen Sicherheitslücken geschlossen.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2020