Libera tu mente y alcanza tus metas
Presionar ENTER para omitir el cifrado completo del disco de Linux con TPM
Presionar ENTER para omitir el cifrado completo del disco de Linux con TPM

Presionar ENTER para omitir el cifrado completo del disco de Linux con TPM

Al utilizar la vulnerabilidad descrita en este aviso, un atacante puede 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 de la computadora. Esta publicación de Michael Fincham explica cómo se identificó y aprovechó esta vulnerabilidad, sin necesidad de realizar soldaduras.

Esta es una exploración de una vulnerabilidad de seguridad real que Pulse Security descubrió y explotó mientras trabajaban con uno de sus clientes. Esta vulnerabilidad se puede utilizar para obtener acceso root local a una computadora Linux Ubuntu 20.04 protegida con TPM si utiliza el software Clevis y dracut de RedHat para implementar el desbloqueo desatendido para el 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 es un mensaje de inicio de sesión sin posibilidad de obtener acceso directo al sistema.

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.

Explotación

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. Aunque se lleva a cabo el desbloqueo del TPM desatendido, al usuario todavía se le presenta la solicitud de contraseña y la oportunidad de ingresar la información.

Aquí hay una foto de una computadora portátil con Ubuntu 20.04 esperando que alguien escriba una contraseña de descifrado del disco:

Ante esto, se puede realizar algunas pruebas de fuzzing para ver si podemos provocar un comportamiento inesperado que pueda ser útil. Esto plantea la cuestión de qué tipos de aportes podrían ser inesperados en esta situación.

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, entonces, ¿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:

Desde aquí es fácil usar manualmente el TPM para desbloquear el disco con las herramientas Clevis y montar el volumen raíz para desbloquear el disco y montar el sistema de archivos.

¿Por qué pasa esto?

Dracut depende de systemd para desbloquear discos cifrados con LUKS en el entorno de inicio temprano. Systemd utiliza una arquitectura de complemento 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.

Remediación

No está claro de quién es exactamente la culpa de este problema, ya que se encuentra en una desafortunada intersección de varias decisiones e implementaciones de diseño diferentes. Los investigadores también pudieron aprovechar este problema presionando la tecla ENTER muy rápido, por lo que tampoco es necesario un emulador de teclado.

La forma más sencilla de solucionar el problema más inmediato: 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

Otras lecturas

Fuente: Pulse Security