Ataques a BitLocker

Una lista de ataques públicos a BitLocker. Cualquier ataque público con el potencial de atacar BitLocker pero cuyo método exacto aún no sea público (como baton drop) queda fuera del alcance.

La mayoría de los ataques son para cuando la VMK está sellada únicamente por el TPM, que es la configuración predeterminada, y es lo que BitLocker automático usa junto con el depósito de la clave de recuperación en una cuenta Microsoft.

De forma predeterminada, a partir de Windows 8, se utiliza la validación de integridad de Secure Boot si Secure Boot está habilitado.

Si debes sellar la VMK únicamente con el TPM, la configuración más segura para ello es usar la validación de integridad heredada con las PCR 0, 2, 4, 7, 11 (y además mantener tu sistema completamente actualizado).
Ten en cuenta que esto solo protegerá contra ataques de software.

Contents

• Hardware attacks
• Software attacks

Hardware attacks

Los ataques de hardware suelen ser útiles solo cuando el atacante tiene acceso físico a un sistema donde la VMK está sellada únicamente por el TPM.

Software attacks

Los ataques de software suelen ser vulnerabilidades en bootmgr, o en alguna otra aplicación de arranque donde la explotación es posible con las claves de BitLocker derivadas en memoria para un volumen arbitrario.
Cuando se puede obtener ejecución de código dentro de una aplicación de arranque, puede ser posible para un atacante "evil cleaner" instalar un bootkit que a su vez se ejecutará con las claves derivadas en memoria (o cuando las claves aún pueden derivarse), y así comprometer un sistema donde se usa una contraseña o una clave de inicio en lugar de un TPM o además de él.

dangerous association

Un sistema vulnerable tendrá instaladas las actualizaciones de mayo de 2022 o junio de 2022, pero no las posteriores.

El GUID de opciones asociadas forma parte de los datos con hash, por lo que el elemento de dispositivo utilizado debe marcarse como no verificado.
No hay elementos que puedan usarse en Windows 7 y versiones anteriores (aunque cuando se usan configuraciones personalizadas no predeterminadas, aún podría ser posible).
En Windows 8 y versiones posteriores, osloader!osdevice no está verificado de forma predeterminada y, como tal, puede usarse.
La forma más fácil de explotar esto es usar el editor de dispositivos BCD en bruto, bcdeditmod, aunque también es posible editar manualmente la hive del registro BCD (resuélvelo tú mismo).

La explotación implica:

• tomar el BCD del dispositivo de destino y crear dos elementos de dispositivo
• copiar el osdevice de {default} al primero
• establecer el GUID de opciones asociadas en {default}!osdevice al primer elemento de dispositivo
• establecer el GUID de opciones asociadas en {first}!osdevice al segundo elemento de dispositivo
• establecer las opciones "peligrosas" (como debug) en el segundo elemento de dispositivo
• arrancar el dispositivo de destino usando ese BCD y el mismo binario bootmgfw que estaba usando

bitpixie

Esta vulnerabilidad existió durante más de 17 años; la compilación conocida más antigua en la que se introdujo es 6.0.5231.2 (winmain_idx03.051004-2120) de octubre de 2005.
Cuando se usa la validación de integridad de Secure Boot, un ataque de degradación (downgrade) aún funcionaría para explotar esta vulnerabilidad.Configure un servidor de arranque PXE con un bootmgfw.efi vulnerable (cuando se utiliza la validación de integridad heredada, este debe ser el bootmgfw.efi del dispositivo de destino) renombrado correctamente para el arranque EFI.

Para el BCD, configure una entrada predeterminada donde device sea el osdevice cifrado con BitLocker; path sea "\"; y una secuencia de recuperación.

La secuencia de recuperación debe apuntar a una única entrada startup, donde device sea boot, path apunte a una aplicación EFI que se ejecutará (desde el servidor PXE); y pxesoftreboot esté habilitado.

Cuando Secure Boot está deshabilitado, esa aplicación EFI puede ser simplemente una aplicación que escanee la memoria física buscando una keytable de BitLocker para volcarla.

Cuando Secure Boot está habilitado, esa aplicación EFI puede usar un bypass conocido de Secure Boot (que requiere acceso físico si es necesario).
Para explotar una aplicación de arranque de Windows de esta manera, necesitará reemplazar el BCD por el segundo en el servidor PXE.
Esto implica presionar una tecla de flecha durante el inicio de bootmgr para forzar que se muestre el menú de arranque; y luego reemplazar el BCD en el servidor PXE en ese momento.

descifrado con solo pulsar un botón

La explotación implica:

• Vuelque el osvolume protegido por bitlocker a una imagen de disco. ¡Este método para obtener el FVEK conlleva una pérdida real de datos!
• Arranque en WinRE por cualquier medio (fuércelo mediante la reparación de inicio si es necesario, o simplemente establezca el elemento BCD bootsequence, etc.).
• Inicie un restablecimiento (Solucionar problemas -> Restablecer este equipo -> Quitar todo). Es más rápido elegir "Reinstalación local". Asegúrese de elegir "Solo quitar mis archivos".
  • Elegir "mantener archivos" pedirá la clave de recuperación.
  • Si el WinRE del sistema no es vulnerable, también pedirá una clave de recuperación.
• Cuando el restablecimiento llegue aproximadamente al 98%, apague el sistema a la fuerza (manteniendo pulsado el botón de encendido durante 7 segundos / etc.).
• Vuelva a encender el sistema; debería arrancar de nuevo en WinRE y mostrar un error. Al descartar el error, debería reiniciarse.
• Cuando vea la pantalla azul de "actualizando", pulse Shift+F10 para obtener un shell.
• Ejecute manage-bde -pause C: seguido de manage-bde -protectors -delete C:
• Apague el sistema a la fuerza (de nuevo).

En este punto, los metadatos de BitLocker en el disco contendrán un VMK en texto plano.
Vuelque ese VMK y úselo para descifrar el FVEK.
El FVEK descifrado se puede usar en la imagen de disco creada anteriormente para descifrar la partición.

Tenga en cuenta: solo logré explotar este problema en Windows 10 en circunstancias muy específicas (BitLocker solo con TPM y sin clave de recuperación). Sin embargo, otros han explotado con éxito este problema usando un WinRE vulnerable en Windows 11 (Nickel).

fuga de RAM

Por lo que sé, esta vulnerabilidad ha existido desde que existe el administrador de arranque: parece estar presente ya en 6.0.5098.0 (winmain_beta1.050628-1740) de junio de 2005, aunque eso es anterior al BCD, por lo que la explotación sería diferente en compilaciones tan tempranas. El código relevante parece existir también antes (el código relacionado con ramdisk parece ser el mismo en la compilación 5048 de abril de 2005), pero la compilación 5098 es la más antigua volcada que tiene BitLocker presente de alguna forma.

Para explotar esto, necesita configurar una entrada predeterminada y una secuencia de recuperación como en bitpixie. Esto es para que las claves se deriven para el dispositivo del sistema operativo cuando se carga el archivo.

La secuencia de recuperación debe tener una entrada de dispositivo adicional para configurar el ramdisk. Use bcdeditmod para esto. Use un elemento personalizado como custom:21100000. Un ejemplo de entrada de dispositivo que podría usar aquí sería !raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]] - querrá reemplazar el dispositivo de bloque part2 aquí con el del BCD de su sistema de destino.

El archivo se puede volcar de la memoria usando cualquier método que le funcione. Prefiero usar una versión anterior de winload hacia mcupdate autofirmado a través del menú de opciones avanzadas, pero hay otras opciones disponibles (por ejemplo, reinicio suave por PXE hacia un sistema operativo de terceros; es posible volcar la memoria desde WinPE mediante un bugcheck o un controlador vulnerable conocido, pero winload marcará el área de memoria como libre en el mapa de memoria de NT, por lo que podría sobrescribirse sin algunos otros ajustes para marcar esa memoria como mala/etc. en winload).

Una implementación de prueba de concepto de mi método preferido se incluye en este repositorio como ramleak.zip. Lea el readme incluido para las instrucciones de uso.

Un agradecimiento a Maxim Suhanov; esto se inspiró al leer el análisis de CrashXTS y al encontrar otra forma de posiblemente volcar hiberfil.sys.

Y ahora mis propias opiniones sobre este bug y sobre yellowkey:

Esta fue la primera vez que tuve un problema real al enviar algo a MSRC, y se debió principalmente a un malentendido de su parte relacionado con Secure Boot. Dado que se estaba divulgando otro 0day de bitlocker, decidí publicar esto ahora; he estado guardándolo durante casi un año preguntándome qué hacer con él.

A diferencia de yellowkey, no haré afirmaciones exageradas de que esto sea una "backdoor"; en mi opinión, no creo que yellowkey sea una backdoor. El componente relacionado tiene que ver con WinPE (no específico de WinRE), y la principal "vuln" allí es lograr que se elimine winpeshl.ini para alcanzar esa ruta de código. Puedo entender perfectamente por qué Microsoft pensó que eliminarlo en un escenario de WinRE+bitlocker no era posible.

Dado que cargar un ramdisk desde una partición cifrada con bitlocker es en realidad una función del entorno de arranque, aunque tuve que usar un truco existente para lograr que funcionara, otras personas también podrían decir que esto era una backdoor si quisieran, pero no voy a llegar tan lejos. El entorno de arranque es complejo (y sigue creciendo; el último bootmgfw_ex.efi ya no cabe en una imagen de 2.88MB - fin de una era), se han descubierto varias vulns debido a cómo interactúan ciertas funciones entre sí.