Vulnerabilidad en la configuración de cifrado LUKS con TPM
Vulnerabilidad en la configuración de cifrado LUKS con TPM

Vulnerabilidad en la configuración de cifrado LUKS con TPM

Un atacante puede aprovechar una vulnerabilidad para tomar el control de una computadora Linux cifrada durante el proceso de inicio temprano, desbloquear manualmente el cifrado de disco basado en TPM y modificar o leer información confidencial almacenada en el disco. Esta vulnerabilidad fue identificada y explotada por Pulse Security mientras trabajaban con uno de sus clientes.

Configuración vulnerable

La vulnerabilidad se puede aprovechar para obtener acceso root local a una computadora Linux Ubuntu 20.04 protegida con TPM, siempre que utilice el software Clevis y dracut de RedHat para implementar el desbloqueo desatendido del cifrado completo del disco LUKS.

Esta configuración es deseable cuando una computadora necesita tener cifrado de disco pero aún así permitir reinicios remotos sin que alguien la desbloquee manualmente después. En circunstancias normales, todo lo que vería un atacante que se presente en la computadora cifrada sería un mensaje de inicio de sesión sin posibilidad de obtener acceso directo al sistema.

Proceso de inicio y vulnerabilidad

Cuando enciende su computadora Linux cifrada, probablemente tenga que ingresar dos contraseñas antes de poder usarla: primero debe ingresar la contraseña de cifrado del disco para desbloquear LUKS (Linux Unified Key Setup) y luego debe ingresar una contraseña de usuario para iniciar sesión. Esto es un poco molesto cuando la computadora está frente a usted, pero es un verdadero obstáculo si desea cifrar un servidor o un dispositivo en una ubicación remota donde no habrá alguien presente para escribir la contraseña cada vez que se reinicie la computadora.

Generalmente, una computadora Linux que utiliza cifrado de disco desatendido protegido por TPM aún permitirá al usuario ver el resultado del proceso de arranque y, opcionalmente, ingresar manualmente una contraseña de descifrado con el teclado. Esto permite situaciones en las que la computadora no arranca y necesita que alguien solucione el proceso de inicio.

Se pueden realizar pruebas de fuzzing para ver si se puede provocar un comportamiento inesperado que pueda ser útil. En 2016, se reveló una vulnerabilidad en el script de inicio cryptsetup de Debian que permitía a un atacante simplemente mantener presionada la tecla ENTER y obtener acceso raíz al entorno de inicio temprano de una computadora Debian cifrada.

Hay un período de tiempo limitado antes de que el TPM desbloquee el disco y el proceso de arranque avance automáticamente hasta el mensaje de inicio de sesión. ¿Cómo podemos eliminar de manera efectiva esta oportunidad de entrada? ¿Y si pudiéramos escribir más rápido que un ser humano? Usando un microcontrolador Atmel ATMEGA32U4 se puede emular un teclado que envía pulsaciones de teclas virtuales esencialmente a la velocidad máxima que aceptará la computadora.

Un segundo después de estar conectado, este programa comienza a simular presionar la tecla ENTER en un teclado virtual cada 10 milisegundos. Esto es aproximadamente 10 veces más rápido que la velocidad de repetición habitual del teclado, y Linux parece reconocer alrededor de 70 caracteres por segundo usando este método, o una pulsación de tecla aproximadamente cada 15 milisegundos.

Al enviar pulsaciones de teclas tan rápido se alcanza rápidamente el número máximo de reintentos de ingreso de contraseña, al mismo tiempo que se evita que el sistema desbloquee el disco automáticamente debido a la limitación de la tasa de adivinación de la contraseña, y systemd finalmente deja de intentar desbloquear el disco. Toma uno o dos minutos, pero la acción de recuperación en este escenario de falla es brindarnos un shell root en el entorno de inicio temprano.

Causas y remediación

Dracut depende de systemd para desbloquear discos cifrados con LUKS en el entorno de inicio temprano. Systemd utiliza una arquitectura de «agente» para el cifrado de disco, donde un grupo de diferentes «respondedores» puede responder a una solicitud de una contraseña para todo el sistema, incluido un script que proporciona automáticamente una contraseña y el método habitual de simplemente «preguntar al usuario». Clevis implementa un agente de contraseña systemd para desbloquear, pero el usuario también puede ingresar una contraseña utilizando el agente interactivo normal. Ambos agentes responden a la misma solicitud emitida por systemd.

Desafortunadamente, en este caso, exponer una solicitud de contraseña al usuario nos brinda una superficie de ataque para influir en el comportamiento del proceso de inicio temprano.

Solución

La forma más sencilla de solucionar el problema más inmediato es agregar rd.shell=0 y rd.emergency=reboot a la línea de comando del kernel. Esto garantiza que si algo falla durante el proceso de inicio temprano, la computadora se reiniciará inmediatamente en lugar de caer en una shell root.

Microsoft evita parte de este problema desbloqueando la clave de cifrado del disco muy temprano en el proceso de arranque y extendiendo inmediatamente PCR11, lo que significa que cuando un usuario obtiene algún tipo de acceso interactivo a la computadora ya no puede realizar su propio desbloqueo.