Microsoft BitLocker – exploit zero-day YellowKey

 (tomshardware.com)
1 puntos por GN⁺ 1 시간 전 | 1 comentarios | Compartir por WhatsApp
  • YellowKey de Chaotic Eclipse permite acceder a unidades bloqueadas con BitLocker usando solo archivos en un USB y el entorno de recuperación de Windows
  • En pruebas de Tom's Hardware, funcionó el procedimiento de copiar archivos FsTx en System Volume Information y, tras Shift+Restart, mantener presionada la tecla Control
  • Después de reiniciar, se ingresó a una línea de comandos con privilegios elevados sin preguntas ni menús, con acceso total a la unidad bloqueada con BitLocker sin introducir ninguna clave
  • Parece difícil abrir una unidad de Alice trasladándola al equipo de Bob, pero si se roba el dispositivo en sí, el TPM objetivo puede aprovecharse tal cual, aumentando el riesgo
  • Según SecurityOnline, YellowKey también funciona en Windows Server 2022 y 2025, pero no en Windows 10

Procedimiento de ataque de YellowKey y comportamiento observado

  • Chaotic Eclipse publicó YellowKey, un zero-day que permite acceder a unidades bloqueadas con BitLocker
  • Tom's Hardware verificó que realmente funciona el procedimiento de copiar ciertos archivos a una memoria USB y luego reiniciar en el Windows Recovery Environment
  • El procedimiento consiste en obtener acceso de escritura a System Volume Information, copiar allí la carpeta FsTx y su contenido, y luego entrar al entorno de recuperación con Shift+Restart mientras se mantiene presionada la tecla Control
  • Tras reiniciar, se entró a una línea de comandos con privilegios elevados sin preguntas ni menús, y fue posible acceder por completo a la unidad bloqueada con BitLocker sin introducir ninguna clave
  • Los archivos usados en el ataque desaparecieron de la memoria USB después de utilizarse una vez, y Tom's Hardware consideró que esto es un comportamiento similar al de una puerta trasera

Alcance del impacto y riesgo de robo físico

  • YellowKey crea un riesgo inmediato para los entornos que confían en BitLocker como mecanismo de cifrado de disco
  • BitLocker protege millones de dispositivos en hogares, empresas y gobiernos, y en especial está activado por defecto en Windows 11
  • Según lo que confirmó Tom's Hardware, no parece posible abrir en el equipo de Bob la unidad del dispositivo de Alice, porque la clave de cifrado está en el TPM del equipo de Alice
  • Sin embargo, si se roba el laptop, mini PC o desktop completo, puede aprovecharse directamente el TPM del dispositivo objetivo, por lo que el riesgo de robo físico aumenta
  • Según un reporte de SecurityOnline, YellowKey también funciona en Windows Server 2022 y 2025, pero no en Windows 10

Configuración TPM·PIN y contexto de la divulgación

  • Eclipse afirma que incluso usar una configuración completa de TPM-and-PIN no ayuda
  • También dijo que tiene una variante para esa configuración, pero que no publicó esa prueba de concepto (PoC)
  • Eclipse señaló que la vulnerabilidad estaba bien escondida y que podría haber ganado mucho dinero vendiéndola, pero que la divulgó por su postura frente a Microsoft
  • El mes pasado, Chaotic Eclipse también publicó los zero-days BlueHammer y RedSun, que hacen que Windows Defender entregue privilegios de administrador del sistema
  • Esa divulgación ocurrió después de la afirmación de que el equipo de seguridad de Microsoft rechazó el reporte de la vulnerabilidad

GreenPlasma, publicado junto con esto

  • GreenPlasma, publicado junto con esto por Chaotic Eclipse, no tiene una PoC completa, pero se afirma que puede obtener acceso a nivel sistema mediante elevación local de privilegios
  • GreenPlasma manipula el proceso CTFMon para colocar un objeto de sección de memoria alterado en una sección específica del Windows Object Manager
  • Se afirma que esa sección está en una ubicación donde el usuario SYSTEM tiene permisos de escritura y que elude el control de acceso normal
  • Después, el código del exploit puede acceder a áreas de memoria a las que no debería poder entrar, y con ello obtener acceso completo al sistema
  • En desktops, un programa arbitrario podría obtener acceso total, y en servidores es aún más grave porque un usuario común podría controlar el servidor y los datos de otros usuarios

Estado de la respuesta de Microsoft

  • Al momento de redactarse el artículo, Microsoft no ha emitido una postura oficial sobre YellowKey ni GreenPlasma
  • BlueHammer ya fue parcheado
  • Chaotic Eclipse afirma que Microsoft parchó RedSun silenciosamente, pero tampoco hay una postura oficial al respecto

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 시간 전
Comentarios de Hacker News

  • La fuente original es https://deadeclipse666.blogspot.com/2026/05/two-more-public-...
    Otros enlaces: https://github.com/Nightmare-Eclipse/YellowKey, https://github.com/Nightmare-Eclipse/GreenPlasma

  • La vulnerabilidad de BitLocker parece simple pero muy peligrosa.
    Empresas y personas han confiado en BitLocker para proteger su información cuando pierden un dispositivo, pero da la impresión de que Microsoft no se toma la seguridad en serio, a pesar de lo que promete.
    ¿Qué hará falta para que más empresas entiendan de verdad el riesgo de depender de Windows y de la plataforma de Microsoft?

    • Desde hace tiempo, Microsoft no parece tomarse BitLocker en serio.
      En la época de Windows 7, podías meter el CD de instalación de Windows y presionar una combinación como Shift+F7 para obtener un símbolo del sistema con la unidad ya desbloqueada.
      Si iban a permitir que el instalador desbloqueara BitLocker, uno pensaría de inmediato: “entonces todo el instalador tiene que ser tan seguro como la pantalla de inicio de sesión”, pero parece que no fue así.
    • Hay que fijarse en que RedSun y Bluehammer fueron parcheados silenciosamente, sin que Microsoft respondiera al CVE ni reconociera el trabajo del investigador.
      Esto es resultado de que Microsoft intenta salirse con la suya manteniendo malas prácticas de seguridad.
      El investigador afirma que tiene preparada otra versión similar capaz de saltarse también TPM+PIN, y me parece creíble.
      Que la misma persona encuentre cinco zero-days de ring 0 en menos de tres meses es demasiado improbable estadísticamente; parece alguien que realmente domina los exploits, al nivel de Juan Sacco.
    • La mayoría de las distribuciones de Linux ni siquiera activan por defecto el cifrado de disco completo, y cuando lo hacen, muchas veces usan exactamente el mismo método que BitLocker: desbloqueo automático sellado a TPM PCR.
      En ese caso, si es posible eludir la autenticación después de arrancar una imagen de sistema operativo firmada o inspeccionar el estado de la memoria del sistema, se obtiene el contenido del disco, así que comparten la misma debilidad.
      Es una concesión arquitectónica que puede elegirse en cualquier plataforma, y no tiene que ver con la “dependencia”.
      Configurar el cifrado de disco de BitLocker de una manera más segura es sencillo, pero suele evitarse porque impone una carga importante a los administradores.
      Creo que Apple tiene mejores valores predeterminados con FileVault, porque “activarlo” se parece más a envolver también con la contraseña del usuario la clave existente ligada al UID del hardware.
      Aun así, esta estrategia puede causar grandes problemas con la rotación remota de contraseñas o con autenticación delegada como Active Directory, así que parece lógico que Microsoft no la elija por defecto.
    • No entiendo cómo un solo bug lleva a concluir que “no se toman la seguridad en serio”.
    • Si lees el tercer párrafo del artículo, sí suena como una puerta trasera sembrada intencionalmente.

  • Crikey, parece que la gran noticia de la puerta trasera se está perdiendo bastante.
    Todos estos parecen exploits muy valiosos y en su mayoría, si no es que todos, bastante terminados.
    Su valor en el mercado sería astronómico, y habrían sido ideales para agencias de seguridad pública que usan empresas que ofrecen desbloqueo como servicio.
    Por eso se agradece mucho que se hayan divulgado públicamente.

    • Estoy convencido de que esto no es un bug sino una puerta trasera intencional, aunque también hay que considerar que los organismos gubernamentales probablemente ya tenían formas de acceder de todos modos: https://news.ycombinator.com/item?id=46735545

  • BitLocker en general sirve de poco si el hardware no es seguro desde el principio.
    Existen muchas implementaciones de Boot Guard que integran certificados en el hardware para que los OEM puedan crear firmware que solo ellos puedan arrancar, pero ha habido al menos dos casos en que esos certificados se filtraron y dejaron expuesto todo el hardware que usaba esa firma, además de existir otras formas de evasión.
    Parte de Boot Guard es “flash guard”, que solo permite flashear firmware firmado, así que no impide escribir directamente en el chip SPI BIOS.
    Alguien ya demostró que se puede parchear el módulo SMM del firmware conservando los valores PCR sin activar en absoluto el bloqueo de BitLocker.
    Es decir, si tienes unos dos minutos para desarmar una laptop o desktop y flashear el firmware, puedes escribir desde afuera un BIOS que incluya el módulo SMM.
    Esto es especialmente grave cuando no hay autenticación por PIN, porque basta con robar la laptop para extraer los datos.
    Si sí hay PIN, puedes dejar una carga útil que exfiltre datos por red después de que el usuario arranque el equipo, o volver a escribir la clave de descifrado en una partición no cifrada, o dañar algunos sectores al final del disco y escribirla allí, para luego robar el equipo otra vez.
    Si modificas SMM, también puedes parchear el proceso de arranque para cargar una carga maliciosa en el hipervisor o en el kernel.

    • Solo es inútil si asumes un atacante perfectamente competente.
      No todos los atacantes son actores estatales; en la práctica, algunos son bastante amateurs.
      No ayuda asumir que, si no puedes detener al atacante más fuerte, entonces todo es inútil y no vale la pena preocuparse.
      Sé que el candado de mi bicicleta también puede ser cortado en segundos por alguien suficientemente hábil y persistente, pero igual la voy a dejar con candado.
    • Bajo la premisa de “si el hardware no es seguro”, la mayoría del cifrado de disco por hardware que ejecutan los controladores HDD/SSD es cien veces peor que BitLocker mismo.
      Está lleno de bugs y vulnerabilidades de seguridad, y usar eso sería una locura.

  • https://infosec.exchange/@wdormann/116565129854382214

    • Dice que la mitigación es usar BitLocker con PIN.
      Sin embargo, el autor de YellowKey dice que no está de acuerdo con que el PIN sea una protección suficiente.

  • Vaya sorpresa. ¿Microsoft sufrirá un golpe serio a su reputación por la puerta trasera, o es tan indispensable para la mayoría de las organizaciones que al final no pasará nada?

    • Parece probable que la UE impulse más rápido la desvinculación por cosas como esta.
    • Creo que cualquiera que haya prestado atención durante al menos 20 años ya asumía que, de una u otra forma, había puertas traseras en los productos de Microsoft.
      Con solo ver las revelaciones originales de Snowden, si antes no estaba claro, después quedó clarísimo.
      Las empresas usan Microsoft porque creen que, aunque existan puertas traseras, a ellas no les afecta.
      Asumen que no son terroristas ni criminales de pornografía infantil, y que obedecerían una citación exista o no una puerta trasera en BitLocker.
      Las personas a las que sí les importan la seguridad y la privacidad guardan sus cosas en algún volumen de VeraCrypt.
    • En realidad, no parece haber evidencia concreta de una “puerta trasera” intencional.
    • Esto no es una puerta trasera real.
      Lo que pasó es que el atacante encontró una forma de arrancar en modo de recuperación y luego explotar Windows.
      La seguridad de los archivos del dispositivo depende de que el atacante no pueda comprometer Windows desde ninguna superficie expuesta antes de que el usuario desbloquee el sistema.
      Por eso sistemas operativos como GrapheneOS desactivan los puertos USB durante el arranque inicial para reducir la superficie de ataque accesible al atacante.
    • Nadie usa Windows por privacidad, así que dudo que a alguien le importe.

  • No estoy seguro de que copiar la clave después de desbloquear el sistema pueda considerarse una puerta trasera.
    Si el sistema operativo prometió restringir el acceso a la clave y falló, entiendo la lógica de que la gente lo llame puerta trasera.
    Pero no es lo mismo que tener una omisión deliberada de la clave o una clave precompartida, y el artículo da un poco esa impresión.
    Por suerte, yo no uso Windows.

    • Exacto. Esto es una evasión de autenticación de Windows que funciona cuando BitLocker está activado.
      Con BitLocker usando solo TPM, cualquier técnica que permita eludir la autenticación después del arranque o extraer el contenido de memoria ya es vulnerable, y en este caso concreto tanto el autor como la prensa le dieron demasiado peso a una técnica de evasión especialmente tonta y rara.
      Todos los sistemas operativos que desbloquean cifrado de disco basándose únicamente en la identidad del hardware son vulnerables al mismo tipo de ataque.
      Las configuraciones de cifrado de disco completo en Linux también pueden quedar mal armadas para permitir entrar a un shell de recuperación, o pueden tener varias formas de explotación.
      Aun así, sigue siendo muchísimo mejor que “no tener protección de disco”, especialmente porque bloquea todos los escenarios donde el disco se separa del hardware.
      Pero la superficie de ataque después del arranque es enorme, y frente a un atacante serio no deberías considerar esta capa de protección como más que un simple tope de velocidad.

  • Vi en Reddit que preguntaban si, incluso después del parche, se puede escribir una versión vulnerable conocida de WinRE en la unidad o en otra unidad.
    No sé mucho de BitLocker o TPM, pero ¿esas tecnologías también impiden algo así?

  • No entiendo por qué en cada hilo hay tantas respuestas tratando de restarle importancia a esto.
    Es raro que muchas vengan sobre todo de cuentas nuevas.
    Sigo viendo variaciones de “esto no es un exploit de BitLocker sino un bug de autenticación/elevación de privilegios”, “aunque el atacante advirtió explícitamente que puede saltarse TPM+PIN, en realidad no puede o no quiso decir eso”, “no hay que concluir apresuradamente que es una puerta trasera”, y “ya sabíamos que BitLocker con solo TPM no era seguro”.
    La última es especialmente extraña, dado que muchas organizaciones están configuradas para depender justamente de eso.

    • Estos sistemas están configurados para descifrado automático.
      Si puedes atacar Windows con éxito entre el desbloqueo y el inicio de sesión del usuario, acceder a los archivos es una consecuencia demasiado obvia.
      Si este es ese tipo de ataque, entonces no es un defecto de BitLocker en sí.
      Tampoco es injusto pedir “enséñalo” respecto de la afirmación de que se puede saltar TPM+PIN.
      Y también es cierto que no hay que concluir apresuradamente que se trata de una puerta trasera.
      Además, BitLocker con solo TPM no es tanto algo “conocidamente inseguro” como algo con una superficie de ataque enorme ya conocida.
    • Los textos que critican a una gran tecnológica normalmente reciben ese tipo de respuestas.
      Aquí pasa siempre, y no parece haber forma de frenar respuestas que se ven 100% auténticas, así que lo mejor es simplemente ignorarlas.

  • Esto se parece demasiado a una puerta trasera intencional, así que ahora resulta todavía más sospechoso que en 2014 TrueCrypt recomendara de repente que todos se cambiaran a BitLocker.
    Esta puerta trasera específica no habría existido en ese momento, ya que parece exclusiva de Windows 11, pero hace más plausible que hubiera otras.
    Aun así, si mataron TrueCrypt para empujar a la gente hacia un cifrado con posibilidad de puerta trasera, queda la duda de por qué permitieron que existiera VeraCrypt.
    VeraCrypt es de código abierto y ha pasado auditorías independientes, así que no debería tener puertas traseras.