¿Cómo puede el malware de Equation Group HDD ayudar a evitar el FDE?

2

Actualmente hay mucha discusión en Internet acerca de la familia "Equation Group" de firmware de disco duro malicioso.

Una cosa que me hace preguntarme es la afirmación de que el firmware de la unidad de disco duro malintencionado podría acceder a los detalles de cualquier esquema de cifrado de disco completo en ejecución. Por ejemplo, tenemos Cómo funciona el piratería de firmware de la NSA y por qué es tan inquietante, por cable que declara, en parte (refiriéndose aquí a las partes no utilizadas del firmware EEPROM):

  

"Teniendo en cuenta el hecho de que su implante GrayFish está activo desde el inicio del sistema, tienen la capacidad de capturar la contraseña de cifrado y guardarla en esta área oculta", [Costin Raiu, director de Kaspersky's Global Research y el Equipo de Análisis] dice.

Tal vez me esté perdiendo algo obvio, pero no entiendo cómo sigue esto. Hay dos casos que puedo ver aquí:

  • Microsoft Windows, con Bitlocker habilitado. El cargador de firmware es aparentemente un ejecutable de Windows, y Windows es un sistema operativo común, por lo que podría tener algo de apalancamiento con el código "listo para usar".
  • Algunos otros sistemas operativos con FDE, por ejemplo, Linux con LUKS o FreeBSD con GEOM. Estos, al menos, no se verán afectados inmediatamente por un binario de Windows.

Cuando se usa el cifrado de disco completo, el dispositivo de almacenamiento (ya sea HDD, SSD, disquete o lo que sea) tiene la tarea de custodiar los bits encriptados. Se sabe que ciertos encabezados existen en diferentes esquemas FDE, a menudo contienen material clave y, presumiblemente, pueden detectarse en función de los números mágicos o la ubicación en el disco, pero las partes cargadas se cifran en el momento en que llegan al dispositivo de almacenamiento.

¿Cómo puede el firmware de un dispositivo de almacenamiento subvertir significativamente el cifrado disco completo , en el cual el dispositivo de almacenamiento solo ve datos cifrados en los comandos READ y WRITE?

La única posibilidad real que puedo ver es si el firmware del dispositivo de almacenamiento puede influir de alguna manera en otras partes del sistema, tal vez explotando DMA, pero ¿el administrador de memoria de la CPU no interviene allí? ¿O se realiza DMA siempre en modo supervisor (anillo 0 en la terminología de Intel)? Eso parece abrir una lata de gusanos completamente diferente.

Supongamos aquí una configuración FDE bastante típica: BIOS o UEFI, entregando un cargador de arranque pequeño sin cifrar que solicita al usuario una contraseña y procede a inicializar el estado del sistema de cifrado antes de pasar a los residentes para interceptar la E / S del disco y realizar el cifrado. descifrado a medida que los datos fluyen entre la capa de E / S normal del sistema operativo y el propio dispositivo de almacenamiento. Todos "de una forma u otra", dejando a un lado los detalles de la implementación técnica, a menos que estén directamente relacionados con la respuesta a la pregunta principal.

    
pregunta a CVn 23.02.2015 - 20:27
fuente

2 respuestas

1

Esto es equivalente a un ataque malvado de maid, que compromete al cargador de arranque (sin cifrar) para capturar su contraseña de FDE la próxima vez que inicie su computadora.

Esto supone que el gestor de arranque se mantiene en la misma unidad. Si ese no es el caso (por ejemplo, si mantiene su cargador de arranque en una unidad extraíble) y configura explícitamente su computadora para que no arranque desde la unidad de disco duro principal (para no ejecutar código potencialmente malintencionado) ) entonces este ataque no funcionará.

De forma predeterminada, tanto con LUKS como con Bitlocker, una pequeña parte de la unidad se mantiene sin cifrar y el cargador de arranque compatible con FDE vive allí y se ejecuta en cada arranque; así que la unidad hace más que guardar los bits encriptados . Un TPM podría ayudar a mitigar eso al verificar la integridad (hashes) del cargador de arranque antes de entregar las claves, y Bitlocker se aprovecha de eso por defecto. Para LUKS, no hay soporte oficial para TPM pero existen algunas soluciones como TrustedGRUB (para extender la cadena de confianza) y tpm-luks para guardar y recuperar la clave LUKS del TPM.

    
respondido por el user42178 26.03.2015 - 18:12
fuente
0

Me imagino que el firmware se remodela para presentar uno de los bloques "de repuesto" en el disco al MOBO para el arranque (después de escribir un rootkit en ese sector oculto) y luego para cargar en cadena lo que debería ser el " real "sector sector de arranque (es decir, el que contiene su cargador de arranque de disco cifrado) después de que el rootkit esté en la memoria.

Lea el kit de arranque empedrado aquí: enlace Si un atacante compromete el sistema operativo y puede plantar hacks de firmware que lo logren, El ataque es un asunto simple. Realmente todo lo que el firmware agrega es la persistencia.

No estoy seguro de cómo funcionaría esto con situaciones de bootstrap más modernas como UEFI, pero nuevamente sospecho que el momento de los ataques de la NSA fue anterior a la adopción a gran escala (es decir, la era de Windows 8).

Sería bueno si la gente de seguridad pudiera ponerse en contacto con una de estas unidades y ver si, por ejemplo, el hecho de que la carga del cargador de arranque con cifrado de disco de un USB o CDROM evite esto.

Otra cosa que se me ocurre es que el firmware coloque un kit de arranque que no haga nada más que escanear el búfer del teclado en busca de picaduras de cierta longitud seguidas de un retorno de carro, y luego almacenarlas en las pistas de mantenimiento del disco. O tal vez simplemente se queda allí escaneando la memoria hasta que encuentra algunas claves AES y las escribe en el almacenamiento.

El punto es que es una forma persistente de ser dueño de un sistema y una vez que eso sucede (bebe de acceso cero), todas las apuestas están apagadas y es posible realizar una serie bastante amplia de ataques.

    
respondido por el boggart 24.02.2015 - 00:10
fuente

Lea otras preguntas en las etiquetas