Vulnerabilidad en Linux facilitaría privilegios root en 70 segundos

Durante el mes de Noviembre parece que asistimos a demostraciones frecuentes de cómo hackear sistemas en segundos. Primero fué Microsoft Edge, durante el último Pwnfest, donde se demostró que se podía hackear en tan solo 18 segundos. Después vino la demostración en Google Pixel, Safari, Flash…

Y ahora, cuando parecíamos a salvo de más sobresaltos, nos encontramos con esto: es posible hacerse con privilegios root en cualquier sistema Linux, de una forma extremadamente sencilla.

Vulnerabilidad en Linux facilita privilegios root

Debido a una mala implementación de la utilidad Cryptosetup en Linux, la cual es usada para cifrar los discos duros en este sistema operativo mediante LUKS (Linux Unified Key Setup), resulta que un atacante es capaz de obtener acceso a la cuenta root local sencillamente pulsando la tecla INTRO  durante un período de 70 segundos.

¿Por qué? Pues debido a que Cryptosetup adolece de un fallo de diseño que permite que se realicen intentos de inicio de sesión de forma contínua, sin límite (lo que se denomina panic en este tipo de entornos).

Una vez un atacante haya utilizado 93 combinaciones de usuario/contraseña incorrectas el sistema entra en error y se concede el acceso a una shell con privilegios root -BusyBox si hablamos de sistemas Ubuntu- y es por lo que hablamos de 70 segundos, ya que pulsar la tecla INTRO durante este lapso de tiempo equivale a introducir 93 credenciales en blanco para root.

Una vez esto ha ocurrido, el acceso se concede desde initramfs (sistema de archivos de inicio en RAM).

Detalles y sistemas afectados

La vulnerabilidad afectaría a las principales distribuciones UNIX del mercado. En las últimas horas se ha comprobado que los sistemas (como Fedora) que emplean Dracut en lugar de initramfs, también son vulnerables.

• Fedora / RedHat
• Debian / Ubuntu
• CentOs / RHEL

Este fallo ha sido reportado por el mismo experto que descubrió algo curioso unos meses atrás. Si os acordáis, en aquel momento se vió como era posible entrar a cualquier máquina Linux -en su configuración por defecto- simplemente pulsando la tecla retroceso 28 veces seguidas.

Aquí tenemos parte del código culpable de ofrecer una shell gratuitamente con accesos root:

 while true; do
98                        sleep 1
                              # local_block() calls to setup_mapping() 30 times,
                  # trying to unlock LUKS root filesystem.
99                        local_block "${dev_id}"
100                        if real_dev=$(resolve_device "${dev_id}") &&
101                           get_fstype "${real_dev}" >/dev/null; then
102                                wait_for_udev 10
103                                log_end_msg 0
104                                break
105                        fi
106                        slumber=$(( ${slumber} - 1 ))
107                        if [ ${slumber} -eq 0 ]; then
108                                log_end_msg 1 || true
109                                break
110                        fi
111                done
112        fi
113
114        # We've given up, but we'll let the user fix matters if they can
115        while ! real_dev=$(resolve_device "${dev_id}") ||
116              ! get_fstype "${real_dev}" >/dev/null; do
117                echo "Gave up waiting for ${name} device.  Common problems:"
118                echo " - Boot args (cat /proc/cmdline)"
119                echo "   - Check rootdelay= (did the system wait long enough?)"
120                if [ "${name}" = root ]; then
121                        echo "   - Check root= (did the system wait for the right device?)"
122                fi
123                echo " - Missing modules (cat /proc/modules; ls /dev)"
124                panic "ALERT!  ${dev_id} does not exist.  Dropping to a shell!"
125        done
126
127        DEV="${real_dev}"
128}

Peligros relacionados con el CVE-2016-4484

1. Escalado de privilegios: ya que la partición de arranque no suele estar encriptada: podría utilizarse la vulnerabilidad para almacenar un ejecutable con el bit SetUID activado. Esto se podría usar más tarde para elevar privilegios con usuario local. También podría suplantarse el kernel e imagen initrd.
2. Fuga de información: aunque este tipo de ataque no concede acceso a los contenidos ya cifrados en disco, si que resulta posible para un intruso copiar, destruir o alterar los contenidos del disco. Es más, este podría configurar la máquina para que filtre datos periódicamente a un servidor remoto.
3. Denegación de servicio: se podría borrar el contenido de cualquier disco.

Y no solo eso, ya que además de estar en peligro las máquinas a las que se accede físicamente, tampoco se libran los sistemas cloud –Amazon AWS, Microsoft Azure y similares. En resumidas cuentas, nos enfrentamos a peligros como:

¿Cómo proteger la cuenta root en Linux y evitarlo?

Lo que necesitamos en primer lugar es comprobar si nuestras particiones de sistema están utilizado cifrado mediante LUKS. Para verlo introduciremos este comando:

`dmsetup status | awk ‘BEGIN {FS=”:”} ; /crypt\s*$/ {print “Encrypted: ” $1}’'

Conseguiremos ver los nombres de las particiones cifradas. Si la lista se muestra vacía, quiere decir que estamos seguros. En caso de que estemos afectados, tocará buscar el parche correspondiente en la web de nuestro distribuídor de Linux. Pero, ¿qué hacemos si no vemos un parche?

Es posible modificar la configuración de arranque y protegernos ante la vulnerabilidad añadiendo la siguiente línea a nuestro archivo boot:

sed -i ‘s/GRUB_CMDLINE_LINUX_DEFAULT=”/GRUB_CMDLINE_LINUX_DEFAULT=”panic=5 /’ /etc/default/grub grub-install
grub-install

Lo que habremos hecho es introducir el argumento panic en la configuración GRUB, lo que provocará que tras el número determinado de intentos de acceso -en este caso hemos establecido 5- al sistema, si no son satisfactorios se nos pedirá reiniciar para seguir intentándolo.

Enlace al CVE-2016-4484 en CVE MITRE.