PKfail: claves de Secure Boot filtradas y firmadas en producción 12 años

El 25 de julio de 2024, Binarly publica los resultados de auditar el firmware de ~900 modelos de dispositivos de 10 vendors. La conclusión es seca: cientos de modelos en producción llevan como Platform Key del Secure Boot una clave de prueba con el subject literal DO NOT TRUST o DO NOT SHIP. La parte privada de esas claves está publicada en repos de GitHub desde 2018–2022, filtrada por error en código fuente de un ODM.

El bug recibe CVE-2024-8105 y la nota VU#455367 del CERT/CC. Binarly lo bautiza PKfail. Es un fallo de supply chain, no de implementación: el modelo de confianza del Secure Boot está roto en la mitad inferior — la firma vale, la cadena valida, todo el booting pasa. Solo que cualquiera con git clone puede firmar.

Lab descriptivo. Hay placa real involucrada y firma con clave robada. Solo escenario autorizado o equipo propio. La PoC pública de Binarly se ejecuta en un binario payload inocuo; este post no incluye ningún bootkit funcional.

Por qué importa

Secure Boot es el primer eslabón de la cadena de confianza en un PC moderno. El firmware UEFI carga un bootloader, verifica su firma contra una db de claves autorizadas, ese bootloader carga el kernel, y así sucesivamente. La db se valida contra una KEK (Key Exchange Key), que a su vez se valida contra la PK — la Platform Key. La PK es la raíz de confianza del dispositivo.

Cuando la PK que firma la db es una clave de prueba de AMI cuyo .pem está en un repo público:

1. Un atacante con permisos para escribir el bootloader del disco (admin local, o acceso físico durante mantenimiento) puede firmar un bootloader malicioso con esa clave privada.
2. El firmware verifica la firma con la PK válida embedded → la firma pasa → el bootloader se carga antes que el OS.
3. Bootkit persistente bajo el OS, antes que cualquier antivirus o EDR, con privilegios SMM-like según implementación.

Lo importante: el bug no da privilege escalation, da persistence. Un atacante que ya tiene admin local cambia el bootloader y se queda dentro a través de reinstalaciones de Windows. Format C: no lo limpia.

El bug en una línea

Una clave de prueba AMI distribuida en SDKs/reference code → publicada por descuido en un repo público → reutilizada en firmware de producción de Lenovo, HP, Dell, Acer, Fujitsu, Supermicro, Intel, Aopen, Formelife y Gigabyte → activa en máquinas a la venta entre 2012 y junio de 2024. 12 años de exposición.

Cómo se llega hasta aquí

El supply chain de un firmware UEFI moderno tiene varios actores:

• IBV (Independent BIOS Vendor): AMI, Insyde, Phoenix. Escriben la base del firmware.
• ODM: monta la placa con el firmware del IBV adaptado.
• OEM: pone su marca encima (Lenovo, HP, Dell). Personaliza, firma con su PK y vende.

El paso de generar la PK propia del OEM es lo que el modelo de Secure Boot espera. El OEM debería tener un HSM, generar una pareja de claves, embed la pública en el firmware, custodiar la privada. En la práctica, el build se hace con claves de prueba que AMI entrega como example en el SDK del IBV, con el subject literal DO NOT TRUST o DO NOT SHIP. La intención: que un ingeniero de QA pueda firmar el firmware durante el desarrollo sin tocar el HSM.

El problema viene cuando el firmware se shipea con esas claves de ejemplo en producción. Pasa por dos motivos: error operativo del ODM, o porque el OEM nunca llega a regenerar su PK. En 2022, Binarly ya había notado el patrón en algunos modelos; la auditoría sistemática de 2024 cuantifica: el 8 % de los modelos analizados en su corpus de firmware images (902 únicos) tiene PK comprometida.

Y entonces alguien sube el .pem privado a GitHub. Binarly encuentra 22 claves únicas no confiables en los firmwares. Para 4 de ellas, la parte privada está en repos públicos — la peor de las cuales se filtró en 2022 cuando un empleado de un ODM subió código con un .pem cifrado con una contraseña de 4 caracteres.

Verificación manual sobre una máquina

Si quieres saber si tu equipo está afectado, hay dos vías. La rápida es el scanner de Binarly: https://pk.fail/. La manual usa herramientas estándar de Linux.

Linux con efivar

# Leer la PK actual del NVRAM UEFI
sudo efi-readvar -v PK -o pk.esl

# Convertir a PEM para inspeccionar el certificado
sign-efi-sig-list -o PK pk.esl /dev/stdout | openssl x509 -text -noout

En una placa afectada, el output del Subject contiene literal:

Subject: CN=DO NOT TRUST - AMI Test PK, ...

o variantes con DO NOT SHIP. Binarly publica un fingerprint database de SHA-256 de las claves filtradas; comparar contra ese conjunto da el match exacto.

Windows con PowerShell

# La PK está en una variable UEFI no expuesta directamente,
# pero el certificado se puede leer desde el firmware capture:
Get-SecureBootUEFI -Name PK | Format-List

# El campo "Bytes" contiene el EFI_SIGNATURE_LIST.
# Para extraer el cert y mirar el subject:
$pk = Get-SecureBootUEFI -Name PK
[System.IO.File]::WriteAllBytes("C:\temp\pk.bin", $pk.Bytes)
# luego openssl o un parser de EFI_SIGNATURE_LIST

Cuando ves DO NOT TRUST en el subject, ese equipo arranca cualquier binario firmado con la pareja AMI cuya privada lleva años en GitHub.

La cadena de explotación

Asumiendo placa afectada y admin local en Windows:

1. Obtener la privada filtrada. Está en un repo público; Binarly no enlaza directamente pero los hashes para identificación están en su advisory. La privada es un .pem de 2048 o 3072 bits.

2. Generar un bootloader malicioso. Un EFI binary del tipo shellcode.efi o un fork modificado de shim que cargue un payload adicional antes de pasar el control al kernel original. Para una demo limpia, un binary que solo escribe un string en pantalla y devuelve.

3. Firmar con sbsign:

   sbsign --key leaked_pk.key --cert leaked_pk.crt \
     --output evil.efi.signed evil.efi

4. Colocar el binario en la EFI System Partition (/boot/efi/EFI/Boot/) y modificar el BootOrder con efibootmgr (Linux) o bcdedit (Windows con privilegios elevados).

5. Reiniciar. El firmware verifica la firma del evil.efi contra la db, la db está autorizada por la PK, la PK es legítima desde el punto de vista del firmware (su par pública está embedded). Arranca. Persistencia conseguida.

Lo curioso: la primitiva no es nueva. BlackLotus usaba bug en shim para algo parecido en 2023. Lo distintivo de PKfail es que no hay bug. La firma es legítima, los certificados son válidos, el flujo de validación funciona como diseñado. El problema es el modelo de confianza: las claves “de prueba” no se trataron como compromisas y nunca se renovaron.

El test de Binarly

Binarly publica un PoC público (vídeo grabado, no live) firmando un EFI binary con una de las claves filtradas y ejecutándolo bajo Secure Boot habilitado en una placa Lenovo afectada. Es uno de los pocos casos en años donde “Secure Boot bypass” se demuestra sin tocar ninguna vulnerabilidad de software — solo abusando del estado del PKI.

Mitigación

La mitigación real es del OEM, no del usuario:

1. El OEM publica un firmware update que sustituye la PK comprometida por una propia válida.
2. El usuario aplica el update vía Windows Update / LVFS / vendor-specific tool.

El proceso es no trivial: cambiar la PK puede invalidar bootloaders firmados con la db anterior. Microsoft y CERT/CC publican una herramienta para coordinar el reemplazo: https://github.com/CERTCC/PKfail. LVFS (Linux Vendor Firmware Service) la distribuye para los OEMs que cooperan.

A los dos meses, Binarly publica un follow-up: la adopción de los updates es lenta y muchos vendors no han publicado parche para modelos descatalogados. La huella de PKfail en infra real va a vivir años — no por falta de mitigación técnica, sino por la fragmentación del supply chain UEFI.

Lo que un equipo de seguridad puede hacer ahora:

• Inventario: pasar el scanner de Binarly sobre la flota. Identificar modelos afectados.
• Workstations sensibles: priorizar reemplazo de PK donde el OEM tenga update disponible.
• Servers: para los modelos afectados (Supermicro, partes de Dell PowerEdge), revisar advisories vendor por vendor.
• Detección runtime: cualquier solución de UEFI integrity monitoring (CHIPSEC, vendors EDR con módulo firmware) debería alertar de cargas de bootloaders no esperadas. Para hosts críticos, esto es complementario a la solución del firmware update.
• Threat model: PKfail asume admin local previo. Si tu adversario está ya dentro con admin, PKfail es una más en su toolkit de persistencia. No es el primer eslabón del compromiso, pero sí dificulta enormemente la limpieza post-incidente.

Verificación manual de PK comprometida — Linux y Windows

Las claves filtradas tienen huellas conocidas. Binarly publica la lista completa de fingerprints SHA-256 de las 22 PK/KEK/db comprometidas; los nombres canónicos en los certificados son cadenas tipo "DO NOT TRUST", "DO NOT SHIP", "AMI Test PK".

# Linux: extraer y inspeccionar la PK del sistema
# Requiere efivar instalado
sudo efivar -l | grep -i platformkey
sudo efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-PK | \
  openssl x509 -inform DER -text -noout | \
  grep -E "Subject:|Issuer:|DO NOT"

# Si aparece "DO NOT TRUST", "DO NOT SHIP" o "AMI Test PK" en CN/O:
# La máquina está usando una clave de prueba como Platform Key. PKfail.

# Alternativa via mokutil
sudo mokutil --pk
sudo mokutil --kek
sudo mokutil --db | grep -A 2 "issuer:"

# Windows: extraer la PK del firmware
# PowerShell as admin
$pk = [System.Text.Encoding]::ASCII.GetString(
    (Get-SecureBootUEFI PK).Bytes
)
$pk | Select-String -Pattern "DO NOT TRUST|DO NOT SHIP|AMI Test|Insyde Software Corp"

# Alternativa: scanner oficial Binarly
# https://github.com/binarly-io/efiXplorer
# Descargar binario, ejecutar:
.\efiXplorer.exe scan-platform-keys

Cadena explotable — sbsign con una PK propia (ejercicio en lab)

Binarly no redistribuye las privadas filtradas. La PoC pública es un vídeo grabado. Para ejercitar el flujo de firma del EFI en lab cerrado (placa propia con Secure Boot custom-mode), generar una PK propia y firmar:

# 1) Generar par PK/KEK/db propios (lab — sustituyen a la PK del firmware)
openssl req -new -x509 -newkey rsa:2048 -nodes -days 3650 \
    -subj "/CN=LAB-PK/" -keyout lab_pk.key -out lab_pk.crt

# 2) Crear un EFI binary trivial (que solo imprima un string) y firmarlo
sbsign --key lab_pk.key --cert lab_pk.crt \
       --output evil_signed.efi hello.efi

# 3) Verificar firma
sbverify --cert lab_pk.crt evil_signed.efi
# Signature verification OK

# 4) Importar la PK lab al firmware (placa en Setup Mode)
#    Sustituye la PK original — equivalente al estado real PKfail
#    pero con custodia propia de la privada.
efi-updatevar -f lab_pk.auth PK

El equivalente real del ataque PKfail es exactamente este flujo, pero con la privada que el atacante saca de un repo público filtrado en lugar de generarla. La huella sintáctica de la firma es indistinguible — por eso el bypass es completo.

El Enhanced Factory Reset no remedia esto — el problema vive en el var/PK del firmware, no en el disco.

YARA / fingerprint matching de claves comprometidas

Binarly publica las 22 fingerprints SHA-256 de las claves comprometidas. Match script trivial:

import hashlib
import sys

LEAKED_KEY_HASHES = {
    "7eb4a82e8e1e8c6f...": "AMI Test PK (Aptio V)",
    "5a3f1e2d8c7b9a4f...": "Insyde Test Platform",
    # 20 más en el blog de Binarly
}

def fingerprint_pk(pk_der_file):
    with open(pk_der_file, "rb") as f:
        return hashlib.sha256(f.read()).hexdigest()

if __name__ == "__main__":
    fp = fingerprint_pk(sys.argv[1])
    if fp in LEAKED_KEY_HASHES:
        print(f"PKFAIL: matches {LEAKED_KEY_HASHES[fp]}")
    else:
        print(f"OK: PK fingerprint {fp[:16]}... not in leaked set")

El patrón estructural

PKfail no es la primera fuga de claves de Secure Boot. En 2016, Microsoft filtró por error una golden key de su política de debug con BCD_FORCE_GOLD_FALLBACK que también permitía boot de no firmados; el incidente se conoció como Microsoft Secure Boot golden key leak. En 2022, Binarly publica BootHole-related findings sobre shim y bootloaders. En 2023, BlackLotus explota un bug en shim para parche persistente. En 2024, PKfail.

El failure mode de fondo es siempre el mismo: el firmware UEFI tiene una superficie de confianza grande, distribuida entre múltiples actores, sin auditoría sistemática y con un PKI poco operado. El Secure Boot fue diseñado para resistir un atacante con disco; lo que no aguanta es un PKI con prácticas de build improvisadas.

Para 2025, lo previsible: más claves no confiables descubiertas en golden images de OEMs, más coordinación CERT/CC, posibles dbx updates de Microsoft revocando masivamente certificados de prueba. Mientras tanto, una placa con PK DO NOT TRUST sigue arrancando lo que le firmes con la privada de GitHub.

Referencias

• Binarly research — PKfail (25 jul 2024): https://www.binarly.io/blog/pkfail-untrusted-platform-keys-undermine-secure-boot-on-uefi-ecosystem
• Binarly — Two months later (sep 2024): https://www.binarly.io/blog/pkfail-two-months-later-reflecting-on-the-impact
• Advisory BRLY-2024-005: https://github.com/binarly-io/Vulnerability-REsearch/blob/main/PKfail/BRLY-2024-005.md
• VU#455367 (CERT/CC): https://kb.cert.org/vuls/id/455367
• NVD — CVE-2024-8105: https://nvd.nist.gov/vuln/detail/cve-2024-8105
• Scanner público: https://pk.fail/
• Herramienta de remediación CERT/CC: https://github.com/CERTCC/PKfail