{"id":118325,"date":"2024-07-26T15:43:00","date_gmt":"2024-07-26T13:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-806-modelyah-materinskih-plat-vyyavlen-testovyj-klyuch-pozvolyayushhij-obojti-uefi-secure-boot"},"modified":"2024-07-26T15:43:00","modified_gmt":"2024-07-26T13:43:00","slug":"v-806-modelyah-materinskih-plat-vyyavlen-testovyj-klyuch-pozvolyayushhij-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/v-806-modelyah-materinskih-plat-vyyavlen-testovyj-klyuch-pozvolyayushhij-obojti-uefi-secure-boot","title":{"rendered":"Se ha descubierto una clave de prueba en 806 modelos de placas base, que permite eludir el UEFI Secure Boot.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Investigadores de seguridad de la empresa Binarly han identificado una vulnerabilidad para eludir el modo de arranque verificado UEFI Secure Boot en m\u00e1s de 800 productos fabricados por Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo y Supermicro. El problema ha sido denominado PKfail y est\u00e1 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\u00e1s antiguos que utilizaban la clave de prueba fueron lanzados en 2012, y los m\u00e1s recientes datan de junio de 2024. Seg\u00fan los investigadores, m\u00e1s del 10% de todos los firmware verificados son vulnerables. <\/p>\n
En los par\u00e1metros de la clave se indicaba que no era de confianza y que no deb\u00eda ser suministrada en sus productos. Se entend\u00eda que esta clave de prueba deb\u00eda ser reemplazada por una propia, pero los fabricantes no prestaron atenci\u00f3n a la advertencia y utilizaron en los firmware finales una clave gen\u00e9rica que se env\u00eda a todos los socios y clientes de AMI. <\/p>\n
La parte privada de la clave de prueba de AMI, necesaria para la creaci\u00f3n de firmas digitales, se hizo accesible p\u00fablicamente tras una filtraci\u00f3n de informaci\u00f3n por parte de uno de los fabricantes de hardware, cuyo empleado err\u00f3neamente public\u00f3 en un repositorio p\u00fablico en GitHub un c\u00f3digo que conten\u00eda dicha clave. La clave privada fue almacenada en un archivo cifrado, cuyo cifrado utiliz\u00f3 una contrase\u00f1a sencilla de 4 caracteres, que fue f\u00e1cil de descubrir mediante un ataque de fuerza bruta. <\/p>\n
La clave de la plataforma se utiliza como ra\u00edz de confianza para certificar la base de datos con claves para Secure Boot. Obtener la parte privada de la clave de la plataforma compromete toda la cadena de confianza involucrada en la verificaci\u00f3n de los componentes del sistema cargado; conocer la clave de la plataforma permite eludir la protecci\u00f3n de Secure Boot y realizar sustituciones durante el arranque mediante la manipulaci\u00f3n de la clave KEK (Key Exchange Key) y las bases de datos \u00abdb\u00bb (Base de Datos de Firmas) y \u00abdbx\u00bb (Base de Datos de Firmas Prohibidas). KEK es responsable de crear la cadena de confianza entre el firmware y el sistema operativo, \u00abdb\u00bb contiene certificados y firmas para el cargador de arranque y componentes UEFI de terceros, mientras que \u00abdbx\u00bb incluye firmas revocadas de componentes maliciosos conocidos. <\/p>\n
Para llevar a cabo un ataque, es suficiente con generar nuevas claves y certificados para KEK y db, y luego utilizar la clave de plataforma de prueba que ha sido divulgada 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. Una vez cargado el certificado db, la clave privada asociada puede ser utilizada para certificar los componentes EFI que se cargan. 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 \u2014key db.key \u2014cert db.crt \u2014output rogue.efi.signed rogue.efi <\/p>\n
Para verificar la validez de la clave de la plataforma, basta con ejecutar la utilidad \u00abefi-readvar -v PK\u00bb del paquete efitools y asegurarse de que la clave de la plataforma no es una clave de prueba: efi-readvar -v PK Variable PK, longitud 862 PK: Lista 0, tipo X509 Firma 0, tama\u00f1o 834, propietario 26dc4851-195f-4ae1-9a19-fbf883bbb35e Sujeto: CN=NO CONFIAR \u2014 AMI Test PK Emisor: CN=NO CONFIAR \u2014 AMI Test PK
![\"Reproducir](\"https:\/\/img.youtube.com\/vi\/CveWt3gFQTE\/hqdefault.jpg\")
\r\n