baldassarrefe/fep3370-advanced-ethical-hackingExploitation DHCP avec DynoRoot (CVE-2018-1111)
Ce projet démontre une vulnérabilité connue des machines Fedora et RedHat liée à une implémentation côté client non sûre du protocole de configuration dynamique des hôtes (DHCP). Un serveur DHCP malveillant peut concevoir des offres DHCP avec une charge utile malveillante qui est exécutée dans un shell root sur la machine victime.
La vulnérabilité est attribuée à Felix Wilhelm et est connue sous le nom de CVE-2018-1111 ou « DynoRoot ».
Le protocole de configuration dynamique des hôtes (DHCP) est un composant souvent négligé dans les systèmes en réseau. Son rôle est de permettre la configuration dynamique des machines hôtes qui se connectent à un réseau existant. Le cas d'usage le plus courant est d'attribuer une adresse IP aux hôtes nouvellement connectés et de les informer des routes existantes pour accéder à d'autres réseaux. Des options supplémentaires peuvent être spécifiées, par exemple l'adresse d'un serveur DNS local et la zone qu'il dessert, ou l'emplacement d'un fichier d'amorçage.
Analysons le protocole en 4 étapes qui est suivi lorsqu'un nouvel hôte veut rejoindre un réseau après s'y être connecté physiquement au moyen d'une connexion ethernet ou sans fil.
DISCOVER sur le réseau.OFFER, contenant : l'adresse IP, le
masque de sous-réseau, l'adresse du routeur, et d'autres options.REQUEST, demandant officiellement de louer l'adresse IP qui a été
proposée.ACK, indiquant que le client est autorisé à utiliser
l'adresse IP pendant une durée spécifiée.Après l'échange initial, le client peut renouveler le bail en envoyant simplement un autre message REQUEST. Le serveur vérifiera l'existence d'un bail avec l'adresse IP et l'adresse MAC du client et répondra avec un ACK.
Session DHCP (figure de Wikimedia Commons, sous licence CC BY-SA 4.0).
Quelques points à noter :
DISCOVER et REQUEST immédiatement une adresse. C'est
courant dans les scénarios où le client s'est déjà connecté au réseau par le passé et se souvient de
l'adresse précédente. Dans ce cas, le serveur vérifie la disponibilité de l'adresse et ACK la demande, ou, si le bail n'est pas disponible, envoie un NACK.RELEASE pour informer le serveur que
l'adresse est désormais disponible. Cependant, cela n'est pas exigé par le protocole et le serveur
récupérera périodiquement les bails expirés.OFFER de bails à de nouveaux clients.OFFERs,
il n'en acceptera qu'une seule, les autres serveurs observeront le REQUEST diffusé et invalideront
l'offre.La vulnérabilité se situe dans /etc/NetworkManager/dispatcher.d/11-dhclient, qui est exécuté
par le client pour analyser et définir les options reçues via DHCP.
declare est une commande intégrée de bash qui, utilisée sans arguments, liste toutes les variables déclarées.grep filtre toutes les variables liées au DHCP.while read opt itère sur les variables DHCP une par une, effectue une analyse et
imprime une ligne comme export new_optionname=value pour chaque option.eval.```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 -->
#### Fonctionnement normal
Dans des situations normales, le code fonctionnerait parfaitement et analyserait les nouvelles options DHCP.
Par exemple, le code suivant :```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
Affichera ces deux instructions export à évaluer avec eval :```bash
export new_option_one=42
export new_option_two='bla bla'
<!-- omit in toc -->
#### Injection de code
Cependant, en raison du `eval` non sécurisé, il est possible d'injecter des commandes bash :```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
)"
Cela entraînera l'évaluation de echo Hacked!:```text
[1] 1541
Hacked!
### Sources
- [Entrée de la base d'exploits](https://www.exploit-db.com/exploits/44890)
- [Annonce de RedHat](https://access.redhat.com/security/vulnerabilities/3442151)
- [Article de blog Tenable](https://www.tenable.com/blog/advisory-red-hat-dhcp-client-command-injection-trouble)
- [Dépôt GitHub](https://github.com/kkirsche/CVE-2018-1111)
- [Annonce sur Twitter](https://twitter.com/_fel1x/status/996388421273882626?lang=en)
## Configuration
La configuration minimale pour démontrer l'exploit se compose de seulement deux machines : la machine `victim`
exécutant Fedora 28, et une machine `attacker`. Dans cette configuration, l'attaquant doit simplement fournir un
service DHCP et attendre la connexion de la victime.
<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>Configuration minimale de l'exploit.</figcaption>
</figure>
Une configuration plus réaliste placerait les machines sur un réseau privé, où une troisième machine, la
`gateway`, est configurée comme serveur DHCP bénin et comme passerelle vers Internet.
Dans cette configuration, l'attaquant doit empêcher la victime de se connecter au serveur DHCP légitime
avant de pouvoir espérer mener l'attaque.