1. Was sendet eine App?
Per E-Mail bekomme ich häufig Anfragen, wie der App-Verkehr auf Android oder iOS mitgeschnitten werden kann. Der Hintergrund solcher Anfragen ist meist derselbe: Die Nutzer möchten wissen, welche Daten eine App von ihnen sammelt und im Hintergrund ungefragt bspw. an Werbeunternehmen oder Trackingdienstleister versendet. Das Herauszufinden ist ein legitimer Wunsch – doch in der Praxis für den Durchschnittsanwender kaum durchführbar.
Das notwendige Wissen für die Durchführung von App-Mitschnitten ist im Internet verfügbar. Doch viele der Informationen sind entweder veraltet oder App-Entwickler arbeiten mit neuen Tricks, um den Datenmitschnitt zu verhindern. In den App-Rezensionen, die ich für mobilsicher.de durchführe, stoße ich selbst hin und wieder auf Probleme bei der Analyse, obwohl ich mich täglich mit der Thematik beschäftige.
Im vorliegenden Beitrag möchte ich kurz die von mir eingesetzten Tools und Techniken vorstellen, die bisher noch jede App bezwungen haben. Eines gleich vorweg: Dies ist keine Anleitung für die Durchführung von App-Mitschnitten, sondern eher als Einblick in meine Arbeit gedacht. Womöglich hilft es auch dem ein oder anderen Pentester weiter.
2. Widerspenstige Apps
2.1 Festgenagelte Zertifikate
Der Mitschnitt bzw. die Analyse von Apps ist im Grunde genommen nicht schwierig. Bereits im Jahr 2012 hatte ich aufgezeigt, wie der Netzwerkverkehr mit mitmproxy analysiert werden kann. Doch immer häufiger ist dies aufgrund neuer Schutzmaßnahmen wie Certificate Pinning schwierig mit herkömmlichen Geräten durchführbar. Erst durch zusätzliche Helfer lässt sich das Certificate Pinning überlisten und der TLS-verschlüsselte Datenverkehr einsehen – das Einspielen selbst signierter Zertifikate einer selbst verwalteten Certificate Authority (CA) genügt meist nicht mehr. Diese werden im Fall von Certificate Pinning als nicht gültig akzeptiert und als Fälschung eingestuft. Das Ergebnis: Man-in-the-Middle-Angriffe werden unbrauchbar und die TLS-verschlüsselte Kommunikation lässt sich nicht mehr analysieren.
2.2 Ignorant oder einfach nur clever?
Durch Tools wie mitmproxy, der Burp Suite oder Charles Proxy kann der App-Verkehr zur Analyse geschleust werden. Diese agieren dann als eine Art »Mittelsmann« zwischen der App und der Gegenstelle im Internet. Damit der App-Verkehr analysiert werden kann, muss er jedoch zunächst auf den Proxy umgeleitet werden. Sowohl Android, als auch iOS bieten dafür systemweit gültige Proxy-Einstellungen – bspw. für das WLAN-Interface. Doch einige Apps ignorieren diesen Proxy schlichtweg und verhindern damit eine Umleitung des Datenverkehrs zur Analyse. Selbstverständlich gibt es auch hierfür einen Workaround. Dennoch stellt sich mir die Frage, warum der systemweite Proxy oftmals schlichtweg übergangen wird.
3. Android App-Sniffing
Von Emulatoren und anderen Basteleien bekommt ihr auf die Dauer Kopfschmerzen. Für die ernsthafte Durchführung von App-Analysen auf Android benötigt ihr nach meiner Auffassung Folgendes:
- Richtige Hardware, also ein echtes Smartphone (keinen Emulator)
- Mindestens Android 4.4.4
- Gerootetes Gerät
- Das Xposed Framework
- Kenntnisse im Umgang mit iptables
3.1 SSL/TLS-Cert Pinning umgehen
Das Umgehen von Cert Pinning erledigt die Xposed Erweiterung JustTrustMe. Nach der Installation müsst ihr das Modul in Xposed aktivieren. Anschließend werden Funktionen, die für das Certificate Pinning zuständig sind, von JustTrustMe ausgehebelt.
3.2 App-Verkehr auf Proxy umleiten
Wir bereits angesprochen ignorieren Apps häufig den systemweiten Proxy. Abhilfe schafft ein iptables Skript, mit dem jeglicher HTTP/HTTPS Verkehr auf einen Rechner umgeleitet wird, wo der Proxy euer Wahl auf Verbindungsanfragen wartet. Ob die App das nun will oder nicht spielt keine Rolle. Eingespielt wird das Skript direkt über adb Befehle. Die Developer-Funktion in Android muss also aktiviert sein und das Gerät bspw. per USB an euren Rechner angeschlossen sein, über den ihr das Skript anschließend ausführt.
#!/bin/sh # iptables Firewall Skript echo "Loading Firewall ..." #################### # Disable IPv6 # #################### adb shell "echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6" adb shell "echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6" adb shell "echo 1 > /proc/sys/net/ipv6/conf/wlan0/disable_ipv6" #################### # Purge/Flush # #################### # Clear all rules adb shell "iptables -F" adb shell "iptables -t nat -F" adb shell "iptables -t mangle -F" adb shell "ip6tables -F" adb shell "ip6tables -t nat -F" adb shell "ip6tables -t mangle -F" # Clear all chains adb shell "iptables -X" adb shell "iptables -t nat -X" adb shell "iptables -t mangle -X" adb shell "ip6tables -X" adb shell "ip6tables -t nat -X" adb shell "ip6tables -t mangle -X" #################### # Defaults # #################### # IPv4 connections adb shell "iptables -P INPUT ACCEPT" adb shell "iptables -P FORWARD ACCEPT" adb shell "iptables -P OUTPUT ACCEPT" # IPv6 connections adb shell "ip6tables -P INPUT DROP" adb shell "ip6tables -P FORWARD DROP" adb shell "ip6tables -P OUTPUT DROP" ##################### # Redirect Traffic # ##################### # Redirect HTTP traffic to Burp adb shell "iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 192.168.1.100:8080" # Redirect HTTPS traffic to Burp adb shell "iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination 192.168.1.100:8080" # Activate Masquerading adb shell "iptables -t nat -A POSTROUTING -p tcp --dport 80 -j MASQUERADE" adb shell "iptables -t nat -A POSTROUTING -p tcp --dport 443 -j MASQUERADE" # Disable netd / Force DNS over Router adb shell "iptables -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination 192.168.1.1:53" adb shell "iptables -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:53" echo ".............. done!"
4. iOS App-Sniffing
Auch in der iOS-Welt empfehle ich die Durchführung von App-Analysen mit einem echten Gerät. Emulatoren bereiten euch wie schon erwähnt nach kurzer Zeit Kopfschmerzen. Für die Durchführung benötigt ihr Folgendes:
- Richtige Hardware, also ein echtes Smartphone (keinen Emulator)
- Mindestens iOS 8.4
- Gejailbreaktes Gerät
- Den alternativen App-Store Cydia
- Kenntnisse im Umgang mit dem Terminal
- Rudimentäre Point-to-Point Tunneling Protocol (PPTP) VPN-Kenntnisse
3.2 SSL/TLS-Cert Pinning umgehen
Auch auf iOS ist ein zusätzliches Hilfsmittel notwendig, um das Cert Pinning zu umgehen. Das Hilfsmittel nennt sich SSL Kill Switch 2. Ähnlich wie bei JustTrustMe für Android hebelt die Erweiterung nach der Aktivierung unter »Einstellungen -> SSL Kill Switch 2« das Certificate Pinning aus.
Der Kuketz-Blog ist spendenfinanziert!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
4.2 App-Verkehr auf Proxy umleiten
Im Gegensatz zu Android ist auf iOS leider keine iptables Firewall verfügbar. Die elegante Lösung mittels iptables den gewünschten Traffic direkt vom Gerät auf den Proxy umzuleiten entfällt damit leider. Mein vorgeschlagenes Konzept für iOS ist mit etwas mehr Aufwand verbunden, das Ergebnis steht dem auf Android allerdings in nichts nach. Über eine VPN-Verbindung wird der gesamte Netzwerkverkehr vom iOS Gerät auf einen Rechner geschleust, auf dem auch der Proxy aktiv ist. Dieser Rechner ist gleichzeitig der VPN-Server bzw. die Gegenstelle auf dem mit Hilfe von iptables der gewünschte Traffic auf den Proxy umgeleitet wird. Ihr benötigt also Folgendes:
- Einen Linux Rechner als VPN-Server bzw. Gegenstelle, auf dem auch der Proxy eurer Wahl läuft
- Als VPN-Server nutze ich das Debian Paket pptpd
Der gesamte Netzwerkverkehr vom iOS Gerät wird über die VPN-Verbindung gesendet und bei der Gegenstelle wieder ausgepackt. Mittels iptables Befehlen können wir nun gewisse Ports auf den Proxy umleiten. Wie auch beim iptables Skript von Android ist dies jeglicher HTTP/HTTPS Verkehr:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080 iptables -t nat -I PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8080
Dabei solltet ihr das IP Forwarding nicht vergessen:
sysctl -w net.ipv4.ip_forward=1
Ob die App den systemweiten Proxy nun umgehen möchte spielt keine Rolle. Der Netzwerkverkehr wird komplett über die VPN-Verbindung geschleust und danach mit iptables entsprechend zum Proxy umgeleitet.
5. Fazit
Neben den genannten Fallstricken wie Certificate Pinning oder das Umgehen des systemweiten Proxys existieren in der Praxis noch weitere Gemeinheiten, um die App-Analyse zu erschweren. App-Entwickler greifen zunehmend in die Trickkiste, um ihre Apps bestmöglich vor neugierigen Blicken zu schützen. So geschehen bei der pushTAN-App der Sparkasse oder der Root-Erkennung von Uber.
Beispiele dieser Art begegnen mir immer häufiger. Da hat wohl offensichtlich jemand etwas zu verbergen? Denn obwohl Maßnahmen wie Certificate Pinning die Sicherheit beim Datenaustausch erhöhen können, bleibt ein fader Beigeschmack. Insbesondere dann, wenn man Recht behält und dank JustTrustMe oder SSL Kill Switch zweifelhafte Praktiken aufdeckt.
Bildquellen:
Dog: ClkerFreeVectorImages, Creative Commons CC0
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
AFWall+: Wie ich persönlich die Android-Firewall nutze
AFWall+: Digitaler Türvorsteher – Take back control! Teil4
F-Droid und AFWall+ – Android ohne Google?! Teil4
AFWall+ unter Android Oreo: Custom-Script Vorlage
Android: DNS-Server für mobiles Netz einstellen
10 Ergänzungen zu “App Verbindungen mitschneiden auf Android und iOS”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit.
Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Diese Schutzmaßnahmen wie z.B das Certificate Pinning von Apps sollte man nicht direkt als ,,Gemeinheiten“ deklarieren. Vielmehr dienen sie als Schutz der Kommunikation vor Angreifer, die Verbindungen mitschneiden wollen. Daher ist es aus Sicherheitsgründen sogar vorteilhaft. Aus Sicht der App-Analyse ist es aber ein Nachteil.
Hier liegt genau das Problem:
Transparenz und Sicherheit widersprechen sich hier.
Ich freue mich über jede App, die Cert Pinning korrekt implementiert hat – ernsthaft. Es kann die Sicherheit tatsächlich verbessern. Aber für mich als Pentester stellt es dennoch erstmal eine »Gemeinheit« dar, die es zu überwinden gilt. ;-)
Bei „das Certificate Pinning von Apps sollte man nicht direkt als ,,Gemeinheiten“ deklarieren“ bin ich noch bei Dir.
Bei „Daher ist es aus Sicherheitsgründen sogar vorteilhaft.“ und “ Transparenz und Sicherheit widersprechen sich hier.“ jedoch nicht mehr:
Der Grund für den ganzen Zirkus liegt ja ein Level höher. Würden die Apps im Quelltext vorliegen, könnte man sich so einiges sparen und besser nachvollziehen und erst dann wäre Dein gepriesenes Certificate pinning ein „Sicherheitsfeature“.
Solange ich aber nicht weiss, was die App genau macht und ich nicht weiss, was darüber geschickt wird, ist und bleibt es ein noch grössres Sicherheitsrisiko.
Das alte „Security though obscurity“? Ernsthaft? Transparenz und Sicherheit haben sich noch nie widersprochen. Intransparent und Sicherheit widersprechen sich.Und zwar immer.
Was du mit ,,Sicherheitsrisiko“ meinst, ist eigentlich der Datenschutzaspekt. Daher sollte man Datenschutz und Sicherheit voneinander unterscheiden. Mit Sicherheit meine ich den Schutz der Kommunikation vor Dritten.
Der Umgang mit den Daten durch die App gehört zur Kategorie: Datenschutz.
Whatsapp hat jetzt die standardmäßige Verschlüsselung von Nachrichten eingeführt.
Es wäre interessant zu wissen, wie leicht/schwer man diese Nachrichten entschlüsseln kann.
Mit der hier genannten Methode bin ich daran gescheitert.
Die WhatsApp Ende-zu-Ende (E2E) Verschlüsselung existiert schon seit knapp 1,5 Jahren – jedenfalls für Android Geräte. Seit dem Update werden nun auch iOS, Windows und Blackberry Geräte unterstützt.
Zur E2E-Verschlüsselung von WhatsApp hatte ich mich schon in einem Kommentar geäußert.
Die hier dargestellte Methode eignet sich nicht zum Mitlesen einer E2E-Verschlüsselung, wie sie WhatsApp implementiert hat. Mit JustTrustMe und SSL Kill Switch können SSL-verschlüsselte Verbindungen »aufgebrochen« werden, die Cert Pinning implementiert haben.
Den IPtables-/VPN-Umweg könnte man sich sparen, wenn man die Verbindung selbst (leicht bei WLAN mittels Internetfreigabe oder tcpdump am Router) mitschneidet. Geht klarerweise nicht (so einfach) für die Daten über Mobilfunk. Außer vielleicht in Zukunft: http://laforge.gnumonks.org/blog/20160328-osmocom-in-debian/.
Nein den Umweg kann man sich leider nicht sparen, wenn man über einen Proxy in die Pakete »reinschauen« möchte.
Klar kann ich auch direkt auf einem iOS oder Android mit Wireshark die Verbindungen mitschneiden – nur der Inhalt bleibt mir (je nach Verschlüsselung) dann verborgen bzw. lässt sich nicht manipulieren.
Hi, vielen Dank für diesen interessanten Beitrag!
Ich habe auf meinem Android-Gerät JustTrustMe installiert und den App-Verkehr auf meine Burp Suite weitergeleitet, indem ich das Skript für mich angepasst habe. Jetzt versuche ich den Verkehr der Twitter-App mitzulesen, was allerdings nicht funktioniert. Gibt es dafür eine Lösung bzw. eine andere App, deren Verkehr ich erst einmal mitlesen kann, um zu prüfen, ob mein Setup passt?
Einfach mit dem Google Chrome, Firefox oder einem anderen Browser testen. Zur Twitter-App existiert übrigens ein Issue.