Skip to content

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:

  1. Der eigene Rechner wurde in wpad umbenannt, ein darauf laufende Webserver akzeptierte Requests nach der Datei wpad.dat auf Port 80.
  2. 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.

Carsten Eilers

>
        </div>
                
        <footer class= Kategorien: Grundlagen

Trackbacks

Keine Trackbacks