Investigadores de seguridad de la empresa Binarly han identificado una vulnerabilidad para eludir el modo de arranque verificado UEFI Secure Boot en más de 800 productos fabricados por Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo y Supermicro. El problema ha sido denominado PKfail y está relacionado con el uso en los firmware de una clave de plataforma que no es de confianza (PK, Platform Key), generada por AMI (American Megatrends International) y suministrada como un ejemplo de prueba. Los firmware más antiguos que utilizaban la clave de prueba fueron lanzados en 2012, y los más recientes datan de junio de 2024. Según los investigadores, más del 10% de todos los firmware verificados son vulnerables.
En los parámetros de la clave se indicaba que no era de confianza y que no debía ser suministrada en sus productos. Se entendía que esta clave de prueba debía ser reemplazada por una propia, pero los fabricantes no prestaron atención a la advertencia y utilizaron en los firmware finales una clave genérica que se envía a todos los socios y clientes de AMI.
La parte privada de la clave de prueba de AMI, necesaria para la creación de firmas digitales, se hizo accesible públicamente tras una filtración de información por parte de uno de los fabricantes de hardware, cuyo empleado erróneamente publicó en un repositorio público en GitHub un código que contenía dicha clave. La clave privada fue almacenada en un archivo cifrado, cuyo cifrado utilizó una contraseña sencilla de 4 caracteres, que fue fácil de descubrir mediante un ataque de fuerza bruta.
La clave de la plataforma se utiliza como la raíz de confianza para la validación de la base de datos de claves para Secure Boot. La obtención de la parte privada de la clave de la plataforma compromete toda la cadena de confianza involucrada en la validación de los componentes del sistema de arranque. Conociendo la clave de la plataforma, se puede eludir la protección de Secure Boot y permitir la sustitución de componentes al arrancar mediante la manipulación de la clave KEK (Key Exchange Key) y las bases de datos «db» (Signature Database) y «dbx» (Forbidden Signature Database). La KEK es responsable de crear la cadena de confianza entre el firmware y el sistema operativo; «db» contiene certificados y firmas para el bootloader y componentes UEFI de terceros, mientras que «dbx» incluye firmas revocadas de componentes maliciosos conocidos.
Para llevar a cabo un ataque, basta con generar nuevas claves y certificados para KEK y db, y luego utilizar la clave de plataforma de prueba, que se ha hecho pública, para cargar el certificado KEK creado en el firmware UEFI. Al cargar el certificado KEK en el firmware, se puede utilizar la clave privada asociada para cargar un nuevo certificado en la base de datos db. Después de cargar el certificado db, la clave privada asociada puede ser utilizada para validar componentes EFI que se están cargando. openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj «/CN=BRLY KEK/» -out KEK.crt openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj «/CN=BRLY db/» -out db.crt efi-updatevar -a -c KEK.crt -k PK.key KEK efi-updatevar -a -c db.crt -k KEK.key db sbsign —key db.key —cert db.crt —output rogue.efi.signed rogue.efi
Para verificar la validez de la clave de la plataforma, basta con ejecutar la herramienta «efi-readvar -v PK» del paquete efitools y asegurarse de que la clave de la plataforma no sea de prueba: efi-readvar -v PK Variable PK, length 862 PK: List 0, type X509 Signature 0, size 834, owner 26dc4851-195f-4ae1-9a19-fbf883bbb35e Subject: CN=DO NOT TRUST — AMI Test PK Issuer: CN=DO NOT TRUST — AMI Test PK
Fuente: opennet.ru
