baton drop (CVE-2022-21894): Vulnerabilidad de omisión de la característica de seguridad de Secure Boot

Las aplicaciones de arranque de Windows permiten que la configuración truncatememory elimine bloques de memoria que contienen rangos "persistentes" de datos serializados del mapa de memoria, lo que provoca una omisión de Secure Boot.

• El elemento BCD truncatememory eliminará toda la memoria por encima de una dirección física especificada del mapa de memoria.
• Esto se realiza para cada aplicación de arranque durante la inicialización, antes de que la política serializada de Secure Boot se lea desde la memoria.
• Por lo tanto, dicho elemento se puede usar para eliminar la política serializada de Secure Boot del mapa de memoria.
• Esto permitirá que se utilicen configuraciones peligrosas en una aplicación de arranque (bootdebug, testsigning, nointegritychecks), rompiendo así Secure Boot.

Este problema se solucionó con dos cambios diferentes:

• Después de intentar cargar una política serializada de Secure Boot, si no se cargó ninguna política, y Secure Boot está habilitado, y la aplicación de arranque no fue cargada directamente por el firmware UEFI, y la aplicación de arranque no es bootmgr, la inicialización de la aplicación de arranque falla.
• Al cargar una aplicación de arranque, si tiene un recurso VERSIONINFO que contiene un OriginalFilename, si ese nombre de archivo está incluido en una lista de bloqueo (que contiene bootmgr.exe y hvloader.exe; en Nickel, se agregó hvloader.efi pero esto no se retroportó), la carga falla.
  • En Windows 8 y Windows 8.1, hvloader.exe no está incluido en la lista de bloqueo de winload; originalmente lo estaba, ¡lo que rompió la carga de Hyper-V!
  • Desde Windows 10 versión 1809, si se establece un cierto bit de banderas (usado con el elemento flightedbootmgr para cargar bootmgr desde el disco), el OriginalFilename debe ser bootmgr.exe.

Explotación

El atacante necesita asegurarse de que la Política de Secure Boot serializada esté asignada por encima de una dirección física conocida.

• Por defecto, se asigna en la dirección más baja posible.
• Originalmente, la Política de Secure Boot serializada se asigna después de cargarse, antes de usar cualquier configuración cargada desde el BCD.
  • Desde RS1, la Política de Secure Boot serializada se asigna al cargar una aplicación de arranque.
  • Desde RS2, cualquier Política de Secure Boot serializada existente se libera al serializar una Política de Secure Boot.
• La Política de Secure Boot serializada se reasigna si, al cargar una aplicación de arranque, el osdevice de la entrada BCD es una partición cifrada con BitLocker donde el VMK se derivó usando el TPM.
  • Esto se puede falsificar estableciendo el bit 0 de las banderas de clave después de un desellado exitoso del TPM; este bit se puede establecer manualmente en los metadatos de BitLocker, con metadatos adicionales agregados para especificar que se está usando Secure Boot para la validación de integridad.

El elemento avoidlowmemory se puede usar para garantizar que todas las asignaciones de memoria física estén por encima de una dirección física especificada:

• Desde Windows 10, este elemento no está permitido si VBS está habilitado, pero como se usa durante la inicialización de la aplicación de arranque, antes de que la política serializada de Secure Boot se lea desde la memoria, cargar bootmgr y especificar una ruta BCD personalizada (usando el elemento bcdfilepath aka custom:22000023) se puede usar para evitar esto.
• Si BitLocker está presente en el volumen del SO, o el sistema de destino está ejecutando TH1 o TH2, entonces este método fallará; por lo tanto, también es posible ejecutar el ataque una vez con un bootmgr de Windows 8.x para deshabilitar VBS y luego volver al cargador de arranque original.
  • Windows 10 cambió la inicialización de la aplicación de arranque para limitar todos los PCR del TPM una vez, por lo que un bootmgr de Windows 8.x no podrá desellar el VMK en un sistema Windows 10+.

hvloader.efi se puede cargar con el elemento nointegritychecks para cargar un mcupdate.dll auto-firmado, cuyo punto de entrada se llamará antes de ExitBootServices.

Alternativamente, en sistemas que no son AMD64, winload.efi anterior a TH2 se puede usar con el elemento testsigning; esto permite binarios auto-firmados con el EKU szOID_NT5_CRYPTO en el certificado.

En sistemas ARMv7, cargar un hal.dll auto-firmado parcheado con una importación a mcupdate.dll será necesario para obtener ejecución de código.

En sistemas x86 y AMD64, el archivo cargado como mcupdate.dll debe llamarse mcupdate_*.dll, donde * es la cadena del fabricante de CPUID (GenuineIntel, AuthenticAMD, etc.).

En sistemas ARM64, esta técnica no se puede usar debido a que la compilación de producción firmada más antigua disponible es un WinPE de RS2; por lo tanto, actualmente solo se puede realizar ejecución de código con cable (usando bootdebug).

Archivos incluidos

Este repositorio incluye los siguientes archivos:

• Se proporciona el código fuente para un payload simple. Este payload solo espera una interrupción infinitamente, ya que sin encontrar funciones y variables interesantes en la aplicación de arranque que lo llama, es imposible hacer cualquier otra cosa.
  • Debido a que mcupdate.dll se ejecuta en una dirección virtual con paginación habilitada, es imposible llamar a funciones EFI directamente (es necesario deshabilitar la paginación para llamar a funciones EFI, regresar a una dirección virtual con paginación desactivada no lleva a un buen lugar).
  • Para llamar a funciones EFI, un payload necesitaría llamar a BlImgLoadPEImageEx o BlImgLoadPEImageFromSourceBuffer con el bit 0 establecido en las banderas para cargar un payload adicional en una asignación 1:1 de dirección física-dirección virtual.
    • Alternativamente, puede llamar a BlImgAllocateImageBuffer con el mismo bit establecido para asignar memoria en una asignación 1:1 de dirección física-dirección virtual; luego cargar un payload por sí mismo (o reasignarse allí).
• Un ISO que explota este problema en AMD64 usando el bootmgfw de Windows 8 RTM y el hvloader de TH1 RTM.
  • El payload usado aquí imprime un mensaje en la pantalla usando una función de hvloader obtenida por desplazamiento y luego bucle infinito.
• Un ISO que explota este problema en AMD64 usando bootmgr de RS1 y el hvloader de TH1 RTM.

Posdata

Este problema se puede usar para volcar claves de BitLocker (donde se usa Secure Boot para la validación de integridad).

• Aunque es posible, el método exacto para obtener ejecución de código con claves de BitLocker derivadas para un volumen arbitrario en memoria no será divulgado.

La corrección de este problema también solucionó otro problema que no tiene CVE.

• bootmgr ignora cualquier tabla de claves de BitLocker ya presente en la memoria y asigna una nueva, sin borrar la antigua.
  • Por lo tanto, un atacante podría cargar bootmgr de RS2+ desde bootmgr (especificando un osdevice arbitrario donde se usa Secure Boot para la validación de integridad), arrancar a WinPE, cargar un controlador vulnerable conocido y usarlo para buscar y volcar la tabla de claves de BitLocker existente en la memoria física.

Ninguna aplicación de arranque vulnerable conocida ha sido revocada todavía.

• Hasta que ocurra la revocación, un atacante puede simplemente traer su(s) propio(s) cargador(es) de arranque vulnerable(s).
• La revocación causaría que todos los medios de instalación/recuperación de Windows existentes, y las copias de seguridad antiguas, no puedan arrancar.
  • El fallo de arranque ocurriría incluso con Secure Boot deshabilitado debido a que bootmgr verifica su propia firma.

Actualización (2023-05-10)

Ocurrió una revocación incompleta, y otro CVE (CVE-2023-24932). Todavía hay bootmgfws vulnerables que no fueron revocados, así como parches adicionales que solo solucionan el caso donde bootmgr carga bootmgr. Solo se necesitó un bootkit pegado para que MS actuara ;)
Si eres lo suficientemente creativo, encontrarás una forma de sortear la revocación de más de 2000 archivos bootmgfw ;)