Microsoft Proxy Einstellungen werden ignoriert - Was nun?

Microsoft Proxy Einstellungen werden ignoriert

Was nun?

by Pascal Schaufelberger
time to read: 13 minutes

Wie im Labs Webapp Pentesting mit Burp von Marc Ruef beschrieben, nehmen wir gerne Burp zur Unterstützung eines Web Application Penetration Test zur Hand. Zur Kategorie Webapp gehören auch Applikationen, die ein Client-Frontend besitzen, welches über HTTP/HTTPS mit einem Webserver kommuniziert. Normalerweise lässt sich auch diese Verbindung über einen Proxy leiten. Es kommt aber auch ab und zu vor, dass eine solche Applikation sich einfach weigert den Traffic über einen Proxy zu schicken. Die Proxy-Einstellungen vom System werden ignoriert und die Applikation selbst bietet keine Möglichkeit einen Proxy anzugeben oder ignoriert selbst die eigenen Einstellungen. In diesen Fällen muss man den Traffic durch den Proxy zwingen. In diesem Artikel geht es um eine Möglichkeit, wie das zu realisieren ist.

Konzept

Ich bevorzuge Applikationen in einer virtuellen Umgebung zu testen. Zum einen habe ich für jeden Test eine neue Umgebung zur Verfügung, bei der ich sicher sein kann, dass keine Rückstände von einem früheren Test das Ergebnis beeinträchtigen. Zum anderen mag ich es nicht, Fremd-Applikationen auf meinem produktiven Client zu installieren.

Das Konzept dazu ist dann auch relativ einfach: Da der Client-Teil schon in einer virtuellen Umgebung ist, ist es ein Einfaches eine weitere Instanz zu kreieren, welche die einzige Aufgabe besitzt, den Traffic vom Client zur Burp Instanz weiterzuleiten. Konkret soll Traffic mit dem Ziel Port 80 (http) oder Port 443 (https) auf den Listener von Burp auf Port 8080 umgeleitet werden. Dies soll mit einer möglichst ressourcearmen Installation erreicht werden, damit noch genügend Ressourcen für das Hostsystem wie auch allfällige weitere Clients vorhanden sind.

Netzwerkzugriff via Burp Proxy

Environment

Wie vorhin schon erwähnt, soll die Router-Instanz möglichst Ressourcen sparend ausfallen. Deshalb habe ich mich für Ubuntu Server 12.4 LTS entschieden. Das virtuelle Environment basiert auf VirtualBox von Oracle, welches sich seit Jahren als gratis Alternative zu VMware Workstation etabliert hat und in den meisten Fällen von der Funktionalität völlig ausreicht.

Folgendermassen sieht meine Konfiguration der virtuellen Hardware aus. Natürlich können sich die Namen der NICs je nach eingesetzter Lösung unterscheiden. Wichtig ist nur, dass die Netzte logisch getrennt sind, und dass eine in dem gleichen Netz wie die Burp Instanz positioniert wird.

VM Einstellung Wert
CPU Cores 1
RAM 96 MB
Harddisk 8 GB
NIC1 NAT
NIC2 Host-only Adapter

IP-Konfiguration und DNS Forwarding

Nachdem Ubuntu installiert wurde, gilt es die Netzwerk Interfaces richtig zu konfigurieren. Hier verweise ich gerne auf die Dokumentation von Ubuntu, welche sehr umfangreich und gut bewirtschaftet ist.

Ein Beispiel für die IP-Konfiguration ist nachfolgend aufgeführt. DHCP für das externe Interface habe ich gewählt, damit die VM möglichst portabel bleibt. Der interne IP-Adressbereich wurde mir von VirtualBox vorgeschlagen, welchen ich dann auch übernommen habe. Die interne Konfiguration spielt sowieso praktisch keine Rolle, da das Netz nur auf dem Host selbst vorhanden ist. Die Anpassungen werden in der Konfigurationsdatei /etc/network/interfaces vorgenommen.

NIC Konfiguration
NIC1 (extern) auto eth0
iface eth0 inet dhcp
NIC2 (intern) auto eth1
iface eth1 inet static
address 192.168.56.1
netmask 255.255.255.0

Nun ist die VM in der Lage, auf der Netzwerkebene zu kommunizieren und sie ist nun bereit, die nächsten Dienste zur Verfügung zu stellen. Das erste ist das DNS-Forwarding. Dazu setzte ich Bind9 ein. Auch hier möchte ich auf die sehr gute Ubuntu Dokumentation verweisen. Nachfolgend sind die nötigen Schritte kurz zusammengefasst.

Wichtig: Die von mir gewählten DNS Server sind die öffentlichen Google DNS Server. Nicht von jedem Netzwerk aus sind direkte DNS Anfragen ins Internet erlaubt. Dann müssten hier lokale und erreichbare DNS Server eingetragen werden.

Schritt Beschreibung Wert
1 Installation von Bind9 apt-get install bind9
2 Bind9 Konfiguration öffnen Nano /etc/bind/named.conf.options
3 In Bind9 Konfiguration einfügen forwarders {
8.8.8.8;
8.8.4.4;
};
4 Bind9 neu starten /etc/init.d/bind9 restart

Routing Funktionalität

Nachdem auch das DNS Forwarding funktioniert, kommt es zum eigentlichen Routing. Hierbei habe mich an den Guide betreffend Routing von der Ubuntu Community gehalten. Das beschriebene Skript unter Punkt 4.5 musste nicht angepasst werden, da sich die Konfiguration nicht von meiner unterscheidet. DasSkript selbst habe ich mit dem Befehl ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript bootable gemacht, damit es nicht nach jedem Neustart des Systems manuell ausgeführt werden muss.

Rerouting

Als finaler Schritt werden die Verbindungen zum Burp Proxy umgeleitet. Dies geschieht mittels den folgenden Befehlen, welche die Iptables konfigurieren und alle Verbindungen, die auf die Ports 80 und 443 gemacht werden, zu Burp auf Port 8080 umgeleitet. In diesem Laborbeispielt hat der Burp Proxy die IP-Adresse 192.168.57.23.

-A PREROUTING -t nat -i eth1 -p tcp --dport 80 -j DNAT --to 192.168.57.23:8080
-A PREROUTING -t nat -i eth1 -p tcp --dport 443 -j DNAT --to 192.168.57.23:8080

Nun können wir natürlich auch diese Regeln in den Bootprozess einbinden. Vor allem da das Skript vom letzten Schritt die Regeln von Iptables immer wieder zurücksetzten, ist es sinnvoll, diese in das vorhergehende Skript einzubinden. Als erstes wird die Burp Proxy Verbindung in einer Variablen definiert:

EXTIF="eth0"
INTIF="eth1"
BURPDST="192.168.57.23:8080"
echo "   External Interface:  $EXTIF"
echo "   Internal Interface:  $INTIF"
echo "   Burp Destination:    $BURPDST"                                     #added

Danach werden die beiden neuen Regeln in das Skript eingefügt:

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
-A PREROUTING -i "$INTIF" -p tcp --dport 80 -j DNAT --to "$BURPDST"         #added
-A PREROUTING -i "$INTIF" -p tcp --dport 443 -j DNAT --to "$BURPDST"        #added
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

Nach dem Neustart des Systems wird nun jeglicher Traffic auf Port 80 und Port 443 auf den Burp Proxy auf Port 8080 umgeleitet. Die VM ist nun fertig konfiguriert und steht für die anstehenden Tests zur Verfügung.

Burp und Client Anpassungen

Da die Verbindungen umgebogen werden, hat Burp ein wenig Mühe damit, die Anfragen zu behandeln. Dies kann mit der folgenden Fehlermeldung enden:

Burp proxy error: Invalid client request received: First line of request did not contain an absolute URL – try enabling invisible proxy support

Um dieses Problem zu beheben, muss Burp in den Transparent-Mode geschaltet werden. Dies geschieht in den Proxy-Einstellungen, indem man die Option Support invisible proxying aktiviert.

Invisible Proxy von Burp aktivieren

Auf der Seite des Clients mit der Software bleibt noch das Problem mit dem SSL-Zertifikat, welches natürlich nicht mehr passt. Für Burp gibt es eine Online Anleitung, wie man dieses Problem lösen kann. Leider lässt es sich nicht für jede Applikation umsetzen. Da gibt es dann nur noch die Möglichkeit, innerhalb der Applikation die Zertifikatsvalidierung zu umgehen und so eine Verbindung zu erzwingen.

Fazit

In Ausnahmefällen bei denen die Proxyeinstellungen ignoriert werden, ist dies eine einfache und schnelle Lösung. Vor allem wenn die VM einmal aufgesetzt wurde, kann sie beliebig oft weiterverwendet werden. Leider bleibt auch hier noch ein kleiner Rest an Applikationen übrig, die sich auch mit dieser Methode weigern, den Traffic über den Proxy zu schicken.

Links

You want to test the security of your firewall?

Our experts will get in contact with you!

×
Security Testing

Security Testing

Tomaso Vasella

Active Directory certificate services

Active Directory certificate services

Eric Maurer

Foreign Entra Workload Identities

Foreign Entra Workload Identities

Marius Elmiger

Active Directory certificate services

Active Directory certificate services

Eric Maurer

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here