In diesem Artikel beschäftigen wir uns mit dem Thema DHCP-Spoofing und welche Rolle WPAD dabei spielt. Zudem zeigen wir auf, welche Möglichkeiten bestehen, diese Angriffe zu verhindern. Hier geht es jedoch nicht mehr um Grundlagen zum DHCP Protokoll. Diese Informationen findet Ihr in unserem ersten und zweiten DHCP Beitrag.
DHCP-Spoofing ist eine Technik die das Einbringen eines “inoffiziellen” DHCP-Servers beschreibt mit dem ein Angreifer Netzwerkkonfigurationen verteilen kann um Netzwerkverkehr mitlesen zu können – also ein klassischer Man-in-the-Middle-Angriff.
Das Problem besteht jedoch darin, schneller zu sein als der richtige DHCP-Server im Netzwerk. Um sicherzustellen, dass ein Client, beim Versuch ein DHCP-Lease zu erhalten, das Offer eines Angreifers annimmt kann man eine DHCP-Starvation Attack nutzen.
Kann der richtige DHCP-Server keine Leases mehr verteilen, wird unser “Rogue”-DHCP Server verwendet.
Unter Linux steht dafür der Dienst „dhcpd“ zur Verfügung. Die zu verteilende Configuration findet man in Linux unter:
/etc/dhcp/dhcpd.conf.
Diese kann man einfach mit vim editieren.
In der Config sind verschiedenste Netzwerkkonfiguration zu finden, wie beispielsweise:
Sobald der Angreifer seinen DHCP-Server konfiguriert hat, sprich Gateway etc. angepasst wurden, kann dieser gestartet werden.
Dazu führt man den Befehl „dhcpd“ aus.
Der gefälschte DHCP des Angreifer läuft nun. Alle kommenden Anfragen, auch Renews, werden ab diesem Zeitpunkt mit einer neuen gefälschten Konfiguration vom Angreifer-DHCP versorgt. Der Attacker trägt sich hier als Gateway / Router bei den anfragenden Clients ein, sodass der ganze Traffic über den Angreifer geleitet wird. Problematisch wird es jedoch bei großen Client-Netzwerken, da wirklich jeder Traffic über den Angreifer geht.
Über DHCP hat man jedoch auch die Möglichkeit Traffic gezielter “zu wählen”. Man verteilt einfach keine DHCP-Leases in denen man sich als Gateway ausgibt, sondern beispielsweise DHCP nutzt um WPAD (Web Proxy Auto Discover).
WPAD ist die Abkürzung für „Web Proxy Auto Discover“ und dient dazu, in einem Netzwerk einem Client einen Proxy-Server automatisch zuzuweisen.
Damit ein Client einen Proxy-Server über WPAD findet, schaut dieser zuerst in seinem DHCP-Lease, ob ein WPAD-Eintrag vorhanden ist. Wenn kein Eintrag vorhanden ist, stellt der Client eine DNS-Anfrage, und versucht eine IP-Adresse für den Eintrag „wpad.domain.com“ zu finden. Wird kein passender DNS-Eintrag gefunden, fragt der Client über den NETBIOS Name Service oder LLMNR nach einem WPAD-Server. Ist nach diesem Prozess die Suche immer noch nicht erfolgreich, scheint kein WPAD-Proxy im Einsatz zu sein.
Wird ein WPAD-Proxy über einen DHCP-Lease vergeben, dann sieht die dhcpd.conf wie folgt aus:
Mithilfe der Option „wpad code 252“ kann die WPAD-URL verteilt werden. Ein zusätzlicher Konfigurations-Eintrag „option wpad „http://Angreifer-IP/wpad.dat““ verweist auf die WPAD-Konfiguration wpad.dat. Der Vorteil für die Benutzung von WPAD aus Angreifersicht besteht darin, dass der Angreifer eindeutig Netzwerk-Traffic filtern kann und bestimmen kann, welchen Traffic er intercepten möchte.
Die WPAD-Konfiguration (wpad.dat) kann wie folgt aussehen:
Dabei wird als Proxy-Server die Adresse des Angreifers zurückgegeben. Zusammengefasst bedeutet dies, alles was an HTTP-Traffic kommt, wird über diesen Proxy-Eintrag an den Angreifer direkt weitergeleitet. Der eingehende Traffic kann dann vom Angreifer manipuliert werden.
Die WPAD-Konfiguration wird über einen einfachen HTTP-Server verteilt, welcher vom Angreifer aus gestartet werden muss. Gestartet wird dieser HTTP-Server wie folgt:
Wurde ein DHCP-Lease mit der WPAD Option erfolgreich verteilt sieht man nun welche Clients sich hier die wpad.dat herunterladen.
Startet ein Nutzer nun seinen Browser wird der Webtraffic über den Proxyserver geleitet, der in der WPAD verteilt wurde.
Bei dem Ganzen ist zu beachten, dass reiner HTTP-Traffic unverschlüsselt übertragen wird und somit einfach vom Angreifer intercepted werden kann. Für das Intercepten von HTTPS (HTTP over SSL) sind zusätzliche Herausforderungen und Bedingungen für ein erfolgreiches Intercepten gegeben;
DHCP Snooping ist eine Funktionalität, die dazu dient DHCP-Angriffe zu verhindern.
Beim DHCP Snooping werden an Switchen “Trusted Ports” konfiguriert, von dem DHCP-Offers akzeptiert werden. An einem dieser “Trusted Ports” ist der DHCP-Server angeschlossen, da dieser der einzige ist, der IP-Adressen dynamisch vergeben sollte. Auch Trunk-Ports müssen den “trusted” Status im Kontext des DHCP-Snoopings haben, da hier valide DHCP-Offers übertragen werden. Stellt der Switch fest, dass ein DHCP-Offer über einen anderen Port stattfindet, verwirft er das Paket.
Das Ergebnis des DHCP Snoopings ist die DHCP Snooping Database in der alle IP-und MAC-Adressen vermerkt sind die durch den DHCP-Server am “Trusted Port” vergeben wurden.
configure terminal
ip dhcp snooping vlan <vlan-number>
interface <interface-name>
ip dhcp snooping trust
exit
Der Abgleich mit der DHCP Snooping Database bietet keinen Schutz vor einer DHCP-Starvation Attack (Denial of Service). Anfragen können immer noch in Massen versendet werden, sodass der Pool eines legitimen DHCP-Servers ausgeschöpft wird. Damit dies verhindert wird, kann ein Rate-Limit auf dem Switch konfiguriert werden, welches vorschreibt, wie viele Anfragen pro Sekunde versendet werden dürfen.
Wird nun ein DHCP-Starvation Attack vom Angreifer ausgeführt, schlägt dieser nach 10 Anfragen fehl.
configure terminal
interface <interface-name>
ip dhcp snooping limit rate 10
exit
Wenn du das ganze Szenario mal in der Praxis sehen möchtest, dann schau dir doch unser Youtube-Video zu dem Thema mal an :D.
