Angriffe auf/über das Web Proxy Auto-Discovery Protokoll WPAD, Teil 1
Was das Web Proxy Auto-Discovery Protokoll (WPAD, auch "autoproxy" genannt) macht habe ich bereits beschrieben. Dass WPAD gefährlich ist, ist schon länger bekannt. Jedes Mal, wenn WPAD nach einem Proxy sucht, kann jeder auf die Anfrage antworten und sich als Web Proxy ausgeben - und damit als Man-in-the-Middle agieren. Besondere Beachtung hat dies Gefahr lange Zeit aber nicht gefunden.
Angriffe auf und über WPAD
Bis 2015 einige Forscher von Trend Micro das Problem genauer untersucht haben. Unter anderem, weil sich das Benutzerverhalten seit der Einführung von WPAD stark verändert hat. Anfangs wurde WPAD vor allem in Unternehmensnetzen genutzt, in denen die Benutzer nur über einen Proxy ins Web gehen durften. Damals waren die Clients meist stationäre Rechner und blieben auf Dauer in diesem Netz, sie suchten deshalb nur sehr selten nach einem neuen Web Proxy. Inzwischen sind viele Geräte mobil und in immer wieder anderen Netzen unterwegs, so dass sie entsprechend oft nach einem neuen Web Proxy suchen.
Maxim Goncharov von Trend Micro hat dann auf der Black Hat USA 2016 auf die Gefahren hingewiesen, die dies uralte Protokoll für die SSL/TLS-Verschlüsselung darstellt: "badWPAD" (Whitepaper als PDF)
Angriffe im lokalen Netz
Im folgenden wird davon ausgegangen, dass sich der Angreifer bereits im lokalen Netz befindet. Z.B., weil der Angreifer ein bösartiger Benutzer ist, oder ein externer Angreifer einen Rechner im lokalen Netz kompromittiert hat.
Ein üblicher Angriff besteht dann darin, durch das Verbreiten von
gefälschten DHCP NetBIOSNameService Informationen für den Namen
des lokalen WPAD-Servers wpad.lokale-domain.example
dafür
zu sorgen, dass der Angreifer die Anfragen an diesen Server erhält und
mit seiner eigenen, manipulierten wpad.dat
beantworten kann.
Dafür ausgenutzte Schwachstellen wurden von Microsoft bereits 2009
behoben. Der Angreifer kann aber auch einfach den Namen seines Rechners in
wapd.[lokale Domain]
ändern.
Alles, was der Angreifer außer der Umleitung der Requests für
die WPAD-Konfigurationsdateien zu seinem Rechner zusätzlich
benötigt, ist ein auf seinem Rechner laufender Webserver, der die
manipulierte wpad.dat
bereitstellt. Es gibt z.B. ein
Metasploit-Modul,
das diese Aufgabe übernimmt.
Meist wird die manipulierte wpad.dat
dann den Rechner des
Angreifers als Proxy konfigurieren, der dadurch als MitM agieren kann.
Danach kann er alle Daten aufzeichnen, beliebige Netzwerkverbindungen (z.B.
die zu Onlinebanking-Websites) auf einen anderen Server umleiten oder die
übertragenen Daten manipulieren.
Angriffe über DNS
Beim Angriff über DNS muss der Angreifer z.B. im Fall des obigen
Beispiels den Server wpad.unternehmen.example
einrichten, was
nur im lokalen Netzwerk möglich ist. Wenn dieser Server vom Opfer vor
dem echten WPAD-Server gefunden wird, kann der Angreifer darüber seine
manipulierte wpad.dat
einschleusen.
Wird im lokalen Netz kein WPAD-Server gefunden, probieren es die Clients
zuletzt mit dem Server wpad.example
, der sich im Internet
befindet. ist Falls der Angreifer also diese Domain registrieren kann ist
ein Angriff darüber möglich.
Wenn der Domainname des angegriffenen LANs z.B.
unternehmens-name.com
lautet wäre der passende
WPAD-Server im Internet wpad.com
.
2009 hat Microsoft ein Security Advisory (971888) samt Update veröffentlicht, dass diese Angriffe, bei denen ein externer Server wie einer im lokalen Netz behandelt wird, erschwert.
Das Trend-Micro-Experiment
Die Forscher von Trend Micro wollten wissen, wie erfolgreich WPAD-Angriffe in zwei Umgebungen sind: Zum einen in einem lokalen Netzwerk eines Unternehmens, zum anderen in einem öffentlichen WLAN. In beiden Umgebungen wurde der oben beschriebene Angriff getestet, und zwar in zwei Varianten:
- Der eigene Rechner wurde in
wpad
umbenannt, ein darauf laufende Webserver akzeptierte Requests nach der Dateiwpad.dat
auf Port 80. - Es wurde Metasploit mit dem wpad-Modul verwendet.
Die ausgelieferten wpad.dat
-Dateien waren jeweils leer, so
dass keine Benutzerverbindungen umgeleitet wurden. Es wurde nur
protokolliert, welche Geräte die Datei heruntergeladen haben. Dabei
wurde besonders auf den User-Agent-String geachtet, um die Geräte zu
identifizieren.
Die Tests in lokalen Netzen fanden innerhalb von Trend Micro statt, die Tests in WLANs an einer Reihe öffentlicher Orte:
- Toronto Airport Wi-Fi
- Business Lounge Lufthansa Terminal 2 (ohne Angabe des Flughafens)
- Lufthansas Onboard-Wi-Fi
- Emirates Airlines Onboard-Wi-Fi
- freies Wi-Fi des San Francisco International Airports
- Enigma Conference Wi-Fi
- Ein Heim-Wi-Fi
Das Experiment lief von Oktober 2015 bis Januar 2016.
Ach, wie gut, dass niemand weiß, wie ich heiß!
Auffallend war, dass viele Geräte keinen User-Agent-String sendeten, also nicht dadurch identifizierbar waren. 43% der Geräte blieben dadurch unbekannt. Die entsprechenden Statistiken sind hier nicht weiter interessant, bei Bedarf finden Sie sie auf Seite 18 im Whitepaper (PDF) zum Black-Hat-Vortrag von Maxim Goncharov.
In der nächsten Folge geht es mit den Angriffen auf und über WPAD weiter.
Kategorien: Grundlagen
Trackbacks