Mit ein wenig Konfigurations-Fuu lässt sich das ohne Probleme umsetzen.

Die Ausgangssituation

Ich habe zwei Server:

Server A

• OpenVPN Server im 10.10.0.1/24 Netz
• Setzt Default-Route beim Client (push „redirect-gateway def1 bypass-dhcp“)

Server B

• OpenVPN Client mit 10.10.0.10/24 IP am tun1
• Benutzer dessen Traffic weitergeleitet werden soll namens „yacy“

Wie anfangs schon erwähnt möchte ich nur den ausgehenden Traffic des Benutzers „yacy“ über das VPN zu Server A schicken. Folgende Probleme gilt es also auf Server B zu lösen:

• Droppen der „Default“ Route
• Weiterleitung des ausgehenden Traffics des „yacy“ Benutzers
• Der restliche Traffic soll uneingeschränkt über das eth0 Netzwerkinterface laufen

Die Umsetzung

OpenVPN Konfiguration anpassen

Um das erste Problem zu lösen, müssen wir unserem OpenVPN Client mitteilen, das er die vom OpenVPN Server gepushte Default Route nicht annehmen soll. Dazu muss man die folgende Option in die entsprechende „.ovpn“ Konfigurationsdatei eintragen:

#No default route
route-nopull

Trafficweiterleitung

Wir werden später mittels den Iptables Pakete von unserem Benutzer markieren, um diese eine bestimmte Route zu schicken. Dazu erstellen wir zunächst eine neue Routing-Tabelle mit dem Namen „vpn.out“.

echo 201 vpn.out | sudo tee -a  /etc/iproute2/rt_tables

Danach erstellen wir eine Regel, welche alle Pakete mit der Markierung „1“ durch die Tabelle „vpn.out“ jagt:

sudo /sbin/ip rule add fwmark 1 table vpn.out

Bisher sollte unsere neue Routing-Tabelle noch leer sein und die Pakete wissen noch nicht wohin. Das ändert sich jetzt:

sudo /sbin/ip route add default via 10.10.0.10 dev tun1 table vpn.out

Default-mäßig werden alle Pakete die in diese Tabelle kommen über das tun1 Device zum Server A geschickt.

Als nächstes bringen wir unserem „tun1“ Device bei, das es etwas lockerer mit der Überprüfung der Routebarkeit von Paketen sein soll. Der Wert „2“ erlaubt das Akzeptieren des Paketes falls es irgendwie auf irgendeinem Device geroutet werden kann.

sudo /sbin/sysctl -w net.ipv4.conf.tun1.rp_filter=2

Als nächstes müssen wir sicherstellen das alle Pakete vom Benutzer „yacy“, die das System über eth0 verlassen wollen, mit „1“ markiert werden. Dazu verwenden wir die Iptables:

sudo /sbin/iptables -t mangle -A OUTPUT -m owner --uid-owner yacy -o eth0 -j MARK --set-mark 1

Zuletzt müssen wir uns noch darum bemühen das die Pakete auch wieder zu uns zurück finden. Ein Source-NAT ist dafür genau richtig:

sudo /sbin/iptables -t nat -A POSTROUTING -o tun1 -j SNAT --to-source 10.10.0.10

Fertig :)

~ Sebastian

Voraussetzungen

Während diesem Blogeintrag werden einige weitere Tools benötigt, welche ich zum entsprechenden Zeitpunkt einführe. Trotzdem sollte man die folgenden drei Voraussetzungen erfüllen, damit sich das Weiterlesen lohnt:

• Burp Proxy – http://portswigger.net/burp/proxy.html
• Exportierte CA Certicifate (PortSwigger) – http://portswigger.net/burp/help/proxy_options_installingCAcert.html
• Android SDK – http://developer.android.com/sdk/index.html

Im weiteren Verlauf werde ich davon ausgehen, dass diese Tools heruntergeladen, installiert und eingerichtet wurden. Dies sollte relativ intuitiv sein, und im Zweifel findet sich Hilfe im Internet.

Emulator einrichten

Wir müssen zunächst einen neuen Android-Emulator erstellen. Die entsprechende GUI rufen wir mit diesem Befehl auf:

android avd

Dort erstellen wir einen neuen Emulator. Spendiert diesem eine SD-Karte und aktiviert die „externe“ Tastatur. Der erstelle Simulator wird im Folgenden den Namen „BurpTesting“ tragen.

Sollte die Tastatur später nicht erkannt werden, so müsst ihr in einer Konfigurationsdatei die Option „hw.keyboard“ von „no“ auf „yes setzen.

~/.android/avd/BurpTesting.avd/config.ini
hw.keyboard=yes

Emulator mit Proxy starten

Zunächst starten wir die Burp Suite. Ich habe den Proxy auf 127.0.0.1:8888 konfiguriert.

Wenn Burp läuft, können wir den Emulator starten. Dabei hängen wir dem Programmaufruf noch einige Parameter an:

• HTTP-Proxy ist localhost:8888
• HTTP Debug auf der Konsole
• Interne Speicher ist 500MB groß
• Kein Sound
• GPU Rendering aktiv
• Keine Bootanimation

Der gesamte Befehl sieht dann so aus:

emulator -avd BurpTesting -http-proxy localhost:8888 -debug-proxy -partition-size 1000 -no-audio -no-boot-anim -gpu on

Der Emulator sollte nun langsam hochfahren. Es kann einige Minuten dauern, bis man beim Homescreen ankommt.

Portswigger CA Certificate installieren

Damit wir später ohne Probleme HTTPS Verbindungen untersuchen können, müssen wir das von Burp mitgelieferte CA Certificate im Emulator hinzufügen. Dazu schieben wir das Zertifikat zunächst auf die SD Karte. Im nächsten Schritt teilen wir „adb“ mit, welchen Emulator wir als nächstes ansprechen möchten:

adb devices

Dort sollte nun ein Emulator erscheinen. Als nächstes kopieren wir das angesprochene Zertifikat:

adb push PortSwiggerCA /sdcard/PortSwiggerCA.crt

Wichtig ist, dass auf der SD Karte das Zertifikat auf „.crt“ endet, ansonsten erkennt Android dieses nicht.

Als nächstes müssen wir einen Screen lock im Emulator festlegen, damit wir das Zertifikat installieren können. Geht im Emulator dazu auf „HOME“->“Settings“->“Security“->“Screen lock“. Ich habe die PIN-Methode gewählt, da sich dieser relativ einfach über die Tastatur eingeben lässt.

Ist der Screen lock gesetzt, könnt ihr auf der gleichen Einstellungsseite unter „Credential Storage“->“Install from SD card“ auswählen. Der Emulator sollte nun das PortSwigger Zertifikat erkennen und auf Euer abnicken installieren.

Zwischenfazit

Bis hierhin habt ihr den Emulator soweit eingerichtet, dass ihr dessen Traffic (auch HTTPS) im Burp sehen und manipulieren könnt.

Das macht natürlich nur Spaß, wenn man sich Apps zum Testen installieren kann.

Playstore auf dem Emulator einrichten

Wir möchten die zusätzlichen Apps über den Google Play Store beziehen. Dazu müssen wir diesen auf dem Emulator installieren.

Ich habe die für den Google Play Store benötigten APKs in einem Archiv zusammengestellt, und stelle Euch dieses hier zur Verfügung. Mittels der beigefügten „install.sh“ werden die Dateien über adb push auf den Emulator kopiert.

Download: http://uploads.blogpasis.net/Playstore.tgz

Nachdem ihr die Dateien nach den Anweisungen der „install.sh“ oder direkt per Aufruf der Datei auf den Emulator kopiert habt, solltet Ihr den Google Play Store in der Appübersicht sehen. Danach braucht Ihr nur noch darin anzumelden.

Den Google Play Store müsst Ihr bei jedem Start des Emulators erneut installieren, da ich keine Möglichkeit gefunden habe, die Änderungen beizubehalten.

Fazit

Ihr habt nun die Möglichkeit Euch Apps aus dem Google Play Store herunterzuladen, und dessen Traffic zu untersuchen. Dies kann bei sicherheitskritischen Apps, sowie auch bei kleinen Spielen interessant sein. Zudem sollte es möglich werden, genau zu überprüfen, welche Daten eine App an Ihren Server überträgt.

~ Sebastian