Un fallo en el arranque permite eludir el cifrado de disco completo en varias distribuciones, y no es un error de software: es una omisión de seguridad.
Una nueva investigación ha puesto al descubierto una preocupante carencia de seguridad en los sistemas Linux con cifrado de disco completo. El hallazgo, documentado por el investigador Alexander Moch y el equipo de seguridad de ERNW, revela que en múltiples distribuciones —incluyendo Ubuntu, Fedora y Debian— es posible obtener una shell de depuración (debug shell) desde el entorno de arranque initramfs, sin autenticación y con acceso suficiente para comprometer el sistema.
Este tipo de ataque, conocido como evil maid attack, requiere acceso físico al equipo, pero demuestra una vez más que cifrar el disco no garantiza una protección total si otros elementos del arranque permanecen vulnerables o sin firmar.
¿Qué es initramfs y por qué importa?
El initramfs (Initial RAM Filesystem) es un sistema de archivos mínimo cargado en memoria durante el arranque. Su función es preparar el entorno para montar el disco raíz —especialmente cuando está cifrado— y entregar el control al sistema operativo. Sin él, en configuraciones con cifrado, el arranque simplemente no es posible.
En teoría, el usuario debe introducir la contraseña para descifrar el disco. Pero si se introduce varias veces de forma incorrecta, algunas distribuciones ofrecen —como mecanismo de recuperación— una shell de emergencia no autenticada. Este comportamiento, útil para administradores que necesitan recuperar sistemas, también puede ser utilizado por atacantes con acceso físico.
El vector de ataque: shell sin protección
La investigación detalla cómo, tras fallar la autenticación del cifrado varias veces (por ejemplo, tres intentos en Ubuntu 25.04), el sistema presenta una shell. Desde ella, el atacante puede montar un USB con un sistema Linux preparado, acceder al entorno chroot, modificar el initramfs, e inyectar scripts maliciosos.
Estos scripts se ejecutarán con privilegios de root en el siguiente arranque legítimo, una vez introducida correctamente la contraseña. No rompen el cifrado, pero lo sortean: actúan después del descifrado, comprometiendo el sistema operativo sin alertar al usuario.
¿Es esto una vulnerabilidad?
Técnicamente, no es un bug. Es una omisión de seguridad. Las distribuciones permiten esta shell de emergencia como ayuda para recuperar sistemas, pero no contemplan su abuso como vector de ataque físico. Además, muchas de estas imágenes de arranque no están firmadas, lo que permite modificarlas sin invalidar el arranque en sistemas con Secure Boot habilitado.
De hecho, ni los benchmarks de seguridad del CIS (Center for Internet Security), ni los perfiles STIG del NIST (National Institute of Standards and Technology), ni herramientas de auditoría como Lynis advierten de este riesgo.
Impacto por distribución (según pruebas reales)
| Distribución | ¿Shell accesible? | ¿USB accesible? | ¿Ataque viable? |
|---|---|---|---|
| Ubuntu 25.04 | Sí (tras 3 intentos) | Sí | ✅ |
| Debian 12 | Sí (tras tiempo de espera) | Sí | ✅ |
| Fedora 42 / AlmaLinux 10 | Sí (rescue mode vía GRUB) | No (por defecto) | ⚠️ Parcial |
| OpenSUSE Tumbleweed | No (boot cifrado) | No | ❌ |
⚠️ Parcial: requiere pasos adicionales para obtener herramientas o cargar módulos USB.
Cómo mitigar el riesgo
Mitigar esta vulnerabilidad es posible y relativamente sencillo, aunque requiere atención técnica:
1. Desactivar el acceso a la shell de emergencia:
- En sistemas Ubuntu:
Añadirpanic=0al parámetro de arranque del kernel. - En sistemas Red Hat/Fedora:
Añadirrd.shell=0 rd.emergency=haltpara evitar shells automáticas.
2. Cifrar la partición de arranque (boot):
Solo algunas distribuciones, como OpenSUSE en configuraciones avanzadas, cifran el /boot. Esto impide modificar initramfs sin la clave.
3. Usar imágenes firmadas (Unified Kernel Images):
Un enfoque más robusto consiste en usar imágenes UKI (Unified Kernel Images), donde el kernel, initramfs y el cargador están firmados como una sola unidad.
4. Configurar contraseñas para arrancar el sistema:
No solo para modificar entradas del GRUB, sino para arrancar el sistema en sí.
Reflexión: el enemigo tiene llave física
Este caso vuelve a subrayar que el acceso físico sigue siendo una de las mayores amenazas en ciberseguridad. Aunque muchas veces el foco está en los ataques remotos, los entornos mal protegidos localmente (portátiles, servidores de laboratorio, sistemas en oficina) son un objetivo silencioso y vulnerable.
Como señala Alexander Moch en su blog:
“El shell de depuración en
initramfsrepresenta un vector de ataque raramente discutido, pero completamente viable. Cuando la seguridad física falla, el cifrado y Secure Boot no bastan si el resto de la cadena no está blindado”.
Conclusión
Este hallazgo no implica que Linux sea inseguro, sino que muchas instalaciones estándar no endurecen adecuadamente el proceso de arranque. La comunidad de seguridad, desarrolladores de distribuciones y administradores de sistemas deben tomar nota: una cadena de arranque segura es tan fuerte como su eslabón más débil, y ese eslabón puede estar en el arranque, antes de que el sistema operativo siquiera despierte.
Fuentes:
