Software seguridad La empresa Binarly descubrió en 2023 que los dispositivos de Acer, DellGigabyte, Intel y Supermicro habían comprometido el arranque seguro. La clave criptográfica que protegía esos modelos se filtró a finales de 2022 en un repositorio público de GitHub. Cualquiera que la descargara podía eludir la protección que ofrecía el arranque seguro.
Aparte de la filtración de 2022, Ars-Tecnica También se informó que más de 300 modelos más usaban 21 claves de plataforma marcadas como “NO ENVIAR” o “NO CONFIAR”. Estas 21 claves fueron proporcionadas por American Megatrends, Inc. (AMI) como claves de prueba para los fabricantes de placas base para personalizar su firmware UEFI. Eso significa que casi todos los fabricantes que trabajaron con AMI tenían una copia de estas claves, y son un secreto a voces de la industria que conocen cientos, si no miles, de personas.
El fundador y director ejecutivo de Binarly, Alex Matrosov, dijo: “Imaginemos que todas las personas de un edificio de apartamentos tienen la misma cerradura y llave en la puerta de entrada. Si alguien pierde la llave, podría ser un problema para todo el edificio. Pero ¿qué pasa si las cosas son aún peores y otros edificios tienen la misma cerradura y las mismas llaves?”. Y agregó: “Si se filtra la llave, esto afectará al ecosistema. No afectará a un solo dispositivo”.
Además de las cinco empresas afectadas por la clave filtrada en GitHub, los siguientes fabricantes también se vieron afectados por las claves de prueba: Aopen, Foremelife, Fujitsu, caballos de fuerzay Lenovo. El impacto generalizado de esta fuga de Secure Boot, Binarly lo denominó PKfail (falla de la clave de plataforma), en reconocimiento del fracaso de toda la industria en la gestión adecuada de las claves criptográficas.
Según el equipo de Binarly, PKfail destaca varios problemas relacionados con la seguridad de la cadena de suministro:
- Mala gestión de materiales criptográficos y aparición de las claves privadas directamente en los repositorios de código con la ruta codificada desde los scripts de compilación.
- Uso de claves criptográficas que no sean de producción responsables de la seguridad de la plataforma de firmware y dispositivos de producción.
- No hay rotación de las claves criptográficas de seguridad de la plataforma por línea de productos. Por ejemplo, se confirmaron las mismas claves criptográficas en productos relacionados con el cliente y el servidor. Se detectó un comportamiento similar con la fuga de la clave del código de referencia de Intel Boot Guard. El mismo OEM utilizó las mismas claves criptográficas relacionadas con la seguridad de la plataforma para el firmware producido para diferentes fabricantes de dispositivos. Se detectó un comportamiento similar con la fuga de la clave del código de referencia de Intel Boot Guard.
Lamentablemente, los usuarios individuales no pueden solucionar este problema si se ven afectados. A menos que el fabricante de la placa lance una actualización del BIOS, no es posible reparar un dispositivo con esta vulnerabilidad.
“Mi conclusión es que sí, (los fabricantes) siguen arruinando el Arranque Seguro, esta vez debido a una gestión de claves poco rigurosa, pero obviamente no se trató de un cambio en mi forma de ver el mundo (el Arranque Seguro es una medida de seguridad encubierta en muchos casos)”, dice HD, un experto en seguridad de firmware y director ejecutivo de runZero. “La historia es que toda la cadena de suministro de UEFI es un desastre y no ha mejorado mucho desde 2016”.
