Cómo eludir BitLocker en Windows 11 con un volcado de memoria

 (noinitrd.github.io)
2 puntos por GN⁺ 2025-01-01 | 1 comentarios | Compartir por WhatsApp
  • Es una demostración de cómo volcar la RAM con Memory-Dump-UEFI en un entorno de Windows 11 24H2 para encontrar la FVEK, la clave de cifrado de volumen completo, y acceder a un volumen protegido con BitLocker
  • Si un atacante puede acceder físicamente al dispositivo, puede apuntar a las claves que permanecen en la RAM justo después de reiniciar, pero cuanto más tiempo pase sin energía, mayor será el riesgo de corrupción del contenido de la RAM
  • La demostración usó un método de reinicio haciendo corto en los reset pins de la placa madre para reiniciar sin pérdida de energía, y dejó los casos de evasión de Secure Boot fuera del alcance del demo
  • En los volcados de Windows 11, la FVEK se encontró bajo las etiquetas dFVE y None en lugar de FVEc de Windows 7 o Cngb de Windows 8.1/10
  • Aunque Microsoft intenta destruir las claves con funciones como SymCryptSessionDestroy, estas pueden permanecer en el heap, por lo que el debugging a nivel kernel es la forma más directa de analizar la implementación de BitLocker

Alcance de la demostración de evasión de BitLocker en Windows 11

  • El objetivo es Windows 11 version 24H2, y el método consiste en extraer de la memoria la FVEK, la clave de cifrado de volumen completo de BitLocker
  • Se usa la aplicación UEFI Memory-Dump-UEFI para volcar el contenido de la RAM
  • La premisa clave es que el atacante pueda tener acceso físico al dispositivo

Condiciones para que el volcado de RAM sea viable

  • La RAM de una instancia reciente de Windows en ejecución puede conservar información sensible como la FVEK
  • Si se corta la energía, el contenido de la RAM se degrada rápidamente, así que durante el reinicio hay que minimizar el tiempo en que la computadora permanece completamente apagada
  • Entre los métodos para reducir la degradación de la RAM están el enfriamiento físico o mantener una fuente de energía externa; en la demostración se reinició sin pérdida de energía haciendo corto en los reset pins de la placa madre
  • Secure Boot es un estándar de seguridad que restringe qué puede ejecutarse al iniciar el dispositivo, pero existen casos de evasión mediante shim y similares, aunque este demo no los trata en detalle

Preparación del USB de arranque y creación del volcado

  • El USB de arranque necesita un dispositivo de almacenamiento con más capacidad que la RAM del sistema objetivo
  • El script flashimage.sh simplifica la preparación de la aplicación arrancable
  • El procedimiento para crear y usar la aplicación de arranque está resumido en MemoryDumpUEFI
  • La probabilidad más alta de encontrar la FVEK fue al reiniciar cuando Windows ya estaba cargando pero antes de que apareciera la pantalla de inicio de sesión
  • Después, se arrancó de inmediato desde el dispositivo USB con Memory-Dump-UEFI y se ejecutó app.efi desde el shell de UEFI
    • El método de ejecución tiene pasos adicionales en el README de la aplicación
    • El tiempo del volcado depende de la capacidad de la RAM y de la velocidad del dispositivo USB
    • Para evitar escribir por error en la unidad equivocada, conviene desconectar otros dispositivos de almacenamiento USB

Procesamiento de los archivos de volcado y herramientas de búsqueda

  • Memory-Dump-UEFI puede generar varios archivos de volcado
  • Para ajustarse a la especificación UEFI, debe usarse el sistema de archivos FAT32, y FAT32 tiene un límite de 4 GB por archivo
  • concatDumps en el directorio tools une varios volcados en uno solo en orden cronológico
  • Como el volcado contiene datos sin procesar de lo que estaba en memoria en ese momento, puede revisarse de forma más legible con herramientas como xxd
  • searchMem permite buscar patrones hexadecimales dentro del volcado y moverse al offset donde se encontraron

Pool tags y ubicación de la FVEK

  • Un pool tag es un identificador de 4 caracteres que indica a qué parte del pool de memoria del kernel de Windows pertenece una región
  • Los pools de memoria asignados por el kernel de Windows pueden ser buenos lugares para buscar información sensible
  • pooltag.txt contiene una lista de pool tags e información sobre el propósito de cada uno
  • En versiones anteriores de Windows, la ubicación de las claves de BitLocker era distinta
    • En Windows 7, era posible recuperar la clave desde el pool tag FVEc, correspondiente a asignaciones de cifrado de fvevol.sys
    • En Windows 8.1 y Windows 10, las claves podían encontrarse en el pool de memoria con la etiqueta Cngb, asociado al módulo ksecdd.sys
  • En los volcados de Windows 11 no se encontraron claves en FVEc ni en Cngb; en cambio, la FVEK apareció en dos ubicaciones
    • La primera está bajo el pool tag dFVE, que representa memoria asignada por dumpfve.sys
    • dumpfve.sys está relacionado con el filtro de crash dump de cifrado de volumen completo de BitLocker drive encryption
    • La ubicación dFVE fue el punto donde la clave se encontró de forma más fácil y consistente
    • Antes de la clave en esa ubicación aparecía 0x0480, que indica el tipo de cifrado y en el entorno de la demostración significaba XTS-AES-128
    • La segunda está bajo la etiqueta None, relacionada con llamadas a ExAllocatePool
    • En esa ubicación, la primera mitad de la clave aparecía dos veces y la segunda mitad una vez

Acceso a volúmenes BitLocker con la FVEK

  • A la clave obtenida hay que anteponerle el valor del algoritmo de cifrado en uso
  • En el ejemplo, se antepone el valor del algoritmo 0x8004 en formato little endian como 0480
  • El valor resultante puede guardarse en un archivo para usarlo como output.fvek
  • Se recomienda el conjunto de herramientas dislocker para verificar el algoritmo y el valor necesarios, y para desbloquear la partición protegida con BitLocker
  • Si el procedimiento es correcto, output.fvek permite acceder a los datos del volumen protegido con BitLocker

Análisis de la implementación de BitLocker y claves remanentes en el heap

  • La forma más directa de entender la implementación de BitLocker es el debugging a nivel kernel con windbg
  • El debugging del kernel puede hacerse con relativa facilidad en una máquina virtual o con un cable USB 3.0 A/A crossed over
  • Seguir paso a paso el proceso de arranque de Windows y observar el funcionamiento de BitLocker ayudó a localizar las claves
  • Microsoft intenta destruir las claves con funciones como SymCryptSessionDestroy, pero las claves pueden permanecer en el heap, por lo que no logra eliminarlas todas

Enlaces de referencia

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-01-01
Opiniones de Hacker News

  • Creo que BitLocker ofrece su mayor ventaja cuando se usa TPM (PCR 7+11)+PIN
    Sin el PIN no debería poder leerse la FVEK, así que esto puede mitigar este ataque y, si BitLocker está bien implementado, cuando se ingresa mal el PIN demasiadas veces el TPM entra en modo de bloqueo contra ataques de diccionario
    Desde hace meses intento lograr la misma configuración en Linux, pero systemd-cryptsetup/cryptenroll son para LUKS, y mi caso es cifrar con fscrypt algunos directorios sensibles (claves de secure boot y /home) en una eMMC interna lenta
    Siento que, cuando uno va más allá de lo básico, programar el TPM es extremadamente difícil: atarlo al PCR 7, atarlo al PCR 11 que cambia con cada actualización de kernel/init/cmdline, usar un PIN en lugar de AuthValue, usar la misma política de autorización para reiniciar el contador de bloqueo DA al iniciar sesión y, a la vez, tener una contraseña larga/AuthValue para reinicio manual, además de hacer coincidir la firma de PCR 11 y la clave pública que proporciona systemd-stub
    Hay muy poco material aparte de las guías básicas de TPM, así que si hay algún experto, me gustaría recibir ayuda. Es un proyecto personal, pero si algún día lo termino pienso documentarlo en un artículo

    • LUKS tiene varias ranuras de clave, así que recuerdo que se podía usar una ranura para el desbloqueo con TPM y otra para recuperación con una contraseña larga
      Vale la pena considerar ese enfoque como mecanismo de recuperación
      Una de las razones por las que poca gente toca el tema de TPM open source como hobby es que hay muchas alternativas que resuelven necesidades parecidas con mucha más facilidad
      Si quieres vincular claves de cifrado importantes al hardware, puedes comprar una Yubikey; si te resulta molesta la contraseña de cifrado del disco de la laptop, puedes usar suspensión al cerrar la tapa en vez de apagarla por completo
      Si la contraseña de inicio de sesión te incomoda, existen lectores de huellas o Yubikey con autenticación biométrica; y si necesitas que arranque sin contraseña, como en un kiosco desatendido o un laboratorio de computación escolar, puedes meterla en una caja metálica resistente y encadenarla a la pared
      Si un servidor de datacenter necesita arrancar sin intervención, muévelo a un datacenter con seguridad física confiable y, si aun así te preocupa, usa Dropbear o Tang para que solo arranque si está en la red correcta
      Si estás jugando con TPM como hobby en un homelab, conviene preguntarte si de verdad trabajar con TPM te resulta divertido, y probablemente descubras que no
    • Aunque Windows exija un PIN para que el TPM obtenga inicialmente la FVEK, al final guardará la FVEK en RAM
      Si no, ¿habría que introducir el PIN cada vez que se descifra un bloque del disco? Además, llamar al TPM en cada operación de disco tendría un gran impacto en el rendimiento
      Como este ataque lee la clave desde la RAM, no veo cómo un PIN de TPM sería una mitigación
    • Creo que tal vez sería mejor usar cifrado con clave dividida o una clave secreta cifrada
      Si antes de arrancar introduces una contraseña y esa contraseña debe combinarse con una clave del TPM para abrir la unidad, eso ayuda en situaciones donde más adelante se descubre la clave del TPM
      Dicho eso, es difícil estar seguro de qué contramedidas ayudarían y cuánto frente a este ataque. Para que el OS mantenga acceso de lectura/escritura a la unidad, tiene que guardar la clave en algún lugar, así que si solo cambia el lugar donde se busca la clave, en la mayoría de los escenarios seguirá siendo posible recuperar datos de la RAM de esta forma
      Recuerdo que en los dispositivos Apple la clave no sale del enclave seguro, así que no creo que sean vulnerables a este tipo de ataque. TPM 3.0 parece necesitar acercarse mucho más a eso
    • Creo que la contraseña de encendido del BIOS también debería funcionar. Sin ella, el sistema no llegaría al punto en que el TPM libera la FVEK
      En las ThinkPad se puede usar la huella digital en lugar de la contraseña de encendido, y como para un ladrón vuelve el equipo casi inutilizable, prefiero esa configuración a un PIN de BitLocker
      Claro que la contraseña de encendido y la autenticación por huella solo son tan fuertes como el TPM, pero ¿no pasa lo mismo con BitLocker TPM+PIN?
    • Me pregunto si el TPM no es una especie de honeypot
      Después del éxito del software de cifrado open source, se siente raro que la tendencia haya pasado al TPM. Parece como si dijeran: hay una bóveda ultrasegura provista por grandes empresas, no se preocupen ni hagan preguntas
      Me da la sospecha de que necesariamente existe una puerta trasera con la que las agencias de inteligencia pueden descargar todos los PIN y contraseñas y acceder a los datos

  • Básicamente no termino de entender bien el modelo de seguridad de BitLocker
    En la mayoría de las instalaciones, parece que al presionar el botón de encendido arranca Windows
    Entonces, si alguien roba un equipo con un disco duro cifrado, ¿solo tiene que encenderlo? No puede ser así, pero al mismo tiempo tampoco sé cómo se evita este ataque en particular
    Supongo que habría que asumir que el tráfico del bus SPI está cifrado y que no se puede volcar la clave de esta forma, pero de todos modos parece que la máquina entrega la clave con bastante facilidad
    LUKS al menos tiene un prompt de contraseña para desbloquear la unidad

    • El tráfico del bus SPI no está cifrado
      Curiosamente, Microsoft no usa cifrado de parámetros del TPM, así que cada uno o dos años algún investigador de seguridad arma y demuestra un dispositivo para hacer sniffing del TPM
      LUKS también depende de la configuración. Linux se puede configurar aquí igual que Windows, y mi servidor de seguridad de videos casero también tiene que reiniciarse sin intervención, así que lo dejé configurado de esa manera. Sé que es vulnerable a ataques de arranque en caliente/frío y a la superficie de ataque de software, pero si alguien solo se lleva la unidad, está a salvo
      Windows también se puede configurar para pedir contraseña o para usar una clave sellada en el TPM con autenticación por PIN
      Dejando de lado el cifrado de parámetros y el problema del sniffing del bus, BitLocker mueve el límite de “cualquiera puede leer la unidad” a “hay que hacer un ataque a nivel de plataforma para obtener el contenido de la memoria, o hackear servicios que corren en la pantalla de inicio de sesión”
      Como evita muy bien escenarios como robar datos financieros de discos duros reutilizados al azar, en la práctica es una mejora de seguridad bastante buena
    • Si enciendes un equipo robado, solo llegas a la pantalla de inicio de sesión, y sin contraseña o autenticación biométrica no pasas de ahí
      Necesitas un desvío, como una vulnerabilidad de ejecución remota de código o arrancar con un bootloader de Windows antiguo y vulnerable. Como la unidad está bloqueada, no sirve el típico bypass de “cambiar el teclado en pantalla por cmd.exe”
      Sin BitLocker, puedes conectar la unidad de Windows a otra PC y ver todos los archivos. Con BitLocker, tienes que lidiar con software vulnerable de Microsoft, vulnerabilidades, memoria volcada y cosas por el estilo, y aun así no siempre funciona
      Si configuras BitLocker en modo TPM+PIN, ni siquiera puedes hacer eso porque no hay una contraseña para abrir el TPM. También puedes dejar BitLocker en modo solo contraseña, pero es mucho más vulnerable a fuerza bruta
      Con LUKS pasa lo mismo: hoy la mayoría de las distribuciones de Linux soportan TPM y TPM+PIN
    • Correcto, pero la idea es que en la pantalla de inicio de sesión (winlogon) hay muy poco que realmente puedas hacer si no tienes credenciales de una cuenta de esa computadora o biometría registrada
      Si intentas reiniciar en modo seguro, o reiniciar con otro OS, una utilidad de actualización de firmware, etc., tienes que ingresar la clave de recuperación de BitLocker
      No estoy muy seguro de cómo funciona internamente cuando se “hackea” un sensor de huellas o una webcam de reconocimiento facial
    • El objetivo principal de usar BitLocker con PIN+TPM es convertir una computadora apagada, o la propia unidad, en un ladrillo
      Hay que asumir que el TPM no tiene una vulnerabilidad que permita extraer claves
      La clave es cuando está apagada
      En el cifrado de unidad de propósito general, el TPM es demasiado lento para descifrar datos masivos reales, así que al final el OS termina teniendo una clave que se puede extraer
    • Un volumen BitLocker puede tener varios protectores, y puede usar archivos de clave, frases de contraseña, PIN y almacenamiento en TPM: https://learn.microsoft.com/en-us/windows-server/administrat...
      En la edición Pro, también se puede exigir mediante directiva de grupo un paso de interacción al arrancar. Funciona incluso sin TPM; en ese caso pide la contraseña cada vez que inicia

  • Esto se puede bloquear por completo con https://trustedcomputinggroup.org/resource/pc-client-work-gr...
    Si está activado y el OS no se apagó correctamente, de modo que no tuvo oportunidad de borrar la clave de cifrado, antes del siguiente arranque el firmware se detiene y borra la RAM
    Me pregunto si Windows no lo usa, o si el sistema probado no lo implementaba

    • Se sabe que Windows usa esta función: https://learn.microsoft.com/en-us/windows/security/operating...
      Dice que “BitLocker usa TCG Reset Attack Mitigation, también conocido como MOR bit (Memory Overwrite Request), antes de extraer las claves en memoria”
      Sin embargo, no confío para nada en la mayoría de las implementaciones de plataforma. Nunca he visto una plataforma UEFI que esté siquiera cerca de implementarlo correctamente de alguna forma
      Sería interesante saber qué plataforma usó este investigador y si esa plataforma afirma soportar el MOR bit
    • Esa mitigación es muy torpe, porque se puede interferir incluso mientras se sobrescribe la RAM
      Basta ver cómo Team Tweezers atacó la Wii original
      La mitigación real son las funciones de cifrado de memoria de los CPU modernos. Como están dentro del die, las pinzas no llegan; solo hay que borrar la clave, así que se elimina de inmediato, y aun si sobreviviera a un ciclo de energía sería muy difícil interferir
    • Aun así, no impide sacar todo el módulo de RAM y volcarlo offline
      Idealmente, la clave debería permanecer solo dentro de la caché SRAM del CPU y nunca salir del die del CPU

  • Soy quien escribió el artículo. Si tienen preguntas, pueden mandarme mensaje a esta cuenta
    Fue un trabajo muy divertido y agradezco mucho el interés

  • Charla de 38C3 relacionada con el bypass de BitLocker en Windows 11: https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou...

  • Es bastante sabido que BitLocker solo protege correctamente una computadora apagada, y aun así solo cuando está configurado para exigir una contraseña de arranque de BitLocker
    [0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...

  • Windows tiene una opción de cifrado de memoria propuesta junto con la compresión de memoria
    Tanto Intel como AMD están trabajando para incorporar esta función en sus CPU
    Sin embargo, el objetivo parece ser servidores que ejecutan varias máquinas virtuales, no laptops

    • Microsoft se está moviendo cada vez más hacia la seguridad basada en virtualización, incluyendo la capacidad de ejecutar “enclaves” para proteger piezas específicas de software: https://learn.microsoft.com/en-us/windows/win32/trusted-exec...
      No sería sorprendente que pronto se usaran “máquinas virtuales” cifradas como medio para almacenar esos valores secretos. Lo que hace falta es soporte de hardware ampliamente generalizado en plataformas de consumo
      Sin embargo, ataques previos de canal lateral a CPU demostraron que también se puede atacar la memoria cifrada (https://www.usenix.org/conference/usenixsecurity21/presentat...). Apuntan a la caché cuando la CPU descifra la memoria para operar normalmente
      Ayudaría a neutralizar los volcados de memoria, pero la RAM cifrada no acabará con la posibilidad de volcar claves desde la memoria. Especialmente ante atacantes pacientes o altamente capacitados
    • Intel actualmente ofrece esto con la función Total Memory Encryption. En el ecosistema Windows, acertadamente, apunta al lado de las máquinas virtuales
      https://techcommunity.microsoft.com/blog/windowsosplatform/m...
      La compresión de memoria existe desde hace mucho, al menos desde Windows 10 RTM. Todos los principales sistemas operativos la implementaron, pero no tiene relación con la seguridad

  • Artículo relacionado: eludir BitLocker en laptops Lenovo con un analizador lógico barato
    https://news.ycombinator.com/item?id=37249623

  • En ataques que dependen de leer un volcado de memoria de la máquina objetivo, me pregunto qué tan realista sería, teniendo acceso físico, un dispositivo intercalado que copie o modifique los datos que entran y salen de la RAM
    Pienso en algo como el “Action Replay” de los viejos Gameboy, que permitía hacer trampas modificando la memoria que se cargaba desde el cartucho del juego al sistema, o que se ejecutaba. Se insertaba el cartucho en el Action Replay, y el Action Replay en el Gameboy
    ¿Se podría hacer algo parecido entre la RAM y la placa madre? Es decir, insertar la RAM en un dispositivo, conectar ese dispositivo a la placa madre y observar las lecturas/escrituras de memoria para capturar el estado de la memoria en un momento arbitrario
    Así se evitaría la molestia de apagar manualmente el equipo y esperar que los datos necesarios sigan ahí
    No soy ingeniero eléctrico, así que quizá sea una propuesta totalmente imposible. Las limitaciones de espacio físico y ancho de banda claramente parecen grandes, pero ¿sería posible?

    • En teoría, es posible. En la práctica, al configurar un enlace DDR hay mucha negociación entre el controlador de memoria y la RAM, y no es fácil crear una situación en la que se vuelquen los datos manteniendo la misma temporización
      Es difícil esperar que aparezca una solución comercial lista para usar
    • Las CPU AMD/Intel modernas soportan cifrado completo de memoria transparente, así que un dispositivo intercalado de ese tipo solo vería datos cifrados de la RAM

  • Poca gente sabe que las CPU Intel/AMD lanzadas en los últimos años soportan cifrado completo de memoria transparente
    El contenido de la RAM se cifra con una clave aleatoria que se conserva dentro del controlador de memoria de la CPU y se genera al reiniciar
    Normalmente viene desactivado en la BIOS porque implica una pequeña pérdida de rendimiento de memoria (0,1%~1%)
    Pero este ataque puede bloquearse por completo

    • Según entiendo, AMD llama a esta función SME(Secure Memory Encryption), e Intel la llama TME-MK(Total Memory Encryption-Multi Key)