Secure Boot de Microsoft: 13 años roto por shims olvidados

¿Qué ha ocurrido?

Investigadores de la firma de seguridad ESET descubrieron 11 imágenes de arranque defectuosas, conocidas como shims, que permanecen firmadas por Microsoft a pesar de tener vulnerabilidades conocidas desde al menos 2013. Estos shims, diseñados originalmente para extender Secure Boot a dispositivos Linux y software de utilidad, pueden ser explotados por atacantes para eludir por completo la protección de Secure Boot. La técnica es lo suficientemente simple como para ser ejecutada por hackers novatos, según el informe de ESET. Este hallazgo, reportado por Ars Technica, revela que Secure Boot, un estándar de seguridad creado por Microsoft para proteger Windows y posteriormente Linux contra infecciones de firmware, ha sido trivial de eludir durante 13 de sus 14 años de existencia.

El problema radica en que Microsoft, que supervisa la firma de los shims, no revocó estas imágenes una vez que se descubrieron las vulnerabilidades. Esto ha permitido que shims defectuosos estén disponibles públicamente durante más de una década. La falla es comparable a dejar una llave maestra bajo el felpudo durante años. Los shims son imágenes de arranque diseñadas para extender Secure Boot a sistemas que no son de Windows, como distribuciones de Linux y herramientas de utilidad. Al estar firmados digitalmente por Microsoft, el sistema los considera de confianza y les permite ejecutarse durante el arranque. Sin embargo, los shims descubiertos contienen vulnerabilidades que permiten a un atacante cargar código no firmado, rompiendo la cadena de confianza.

¿Por qué es importante?

Secure Boot es un estándar de seguridad integrado en la interfaz de firmware UEFI de las placas base. Su función es garantizar que solo se ejecute firmware y software de arranque firmado digitalmente durante el inicio del sistema, creando una cadena de confianza desde el firmware hasta el sistema operativo. La vulnerabilidad afecta tanto a usuarios de Windows como de Linux, ya que el shim puede instalarse en dispositivos con ambos sistemas operativos. Una vez explotado, un atacante puede instalar firmware malicioso que se carga temprano en el proceso de arranque y persiste incluso después de reinstalar el sistema operativo o reemplazar el disco duro. Esto proporciona una persistencia a nivel de firmware extremadamente difícil de detectar y eliminar.

El impacto es significativo. Según datos de ESET, al menos uno de los shims data de 2013, lo que significa que la ventana de exposición ha sido de más de una década. Durante ese tiempo, cualquier atacante con acceso físico o privilegios de administrador podría haber explotado estas imágenes para comprometer sistemas. La simplicidad de la técnica, descrita como accesible para hackers novatos, agrava el riesgo, ya que reduce la barrera de entrada para ataques sofisticados. Las organizaciones que dependen de Secure Boot para proteger sus sistemas críticos, como servidores empresariales, infraestructuras gubernamentales o dispositivos de Internet de las Cosas (IoT), deben revisar sus políticas de actualización de firmware y considerar la revocación de certificados.

Antecedentes y contexto

El concepto de shim no es nuevo. Fue introducido para permitir que sistemas operativos alternativos, como Linux, pudieran aprovechar las protecciones de Secure Boot sin necesidad de deshabilitarlo. Sin embargo, el proceso de firma de shims por parte de Microsoft no incluyó una revisión rigurosa de seguridad a largo plazo. Una vez que un shim es firmado, permanece válido a menos que sea explícitamente revocado mediante una actualización de la lista de revocación de Secure Boot (DBX). En este caso, Microsoft no emitió dichas revocaciones, a pesar de que las vulnerabilidades eran conocidas desde 2013. Esto contrasta con incidentes anteriores, como la vulnerabilidad BootHole en 2020, que afectó a GRUB2 y requirió una actualización masiva de DBX. En aquella ocasión, Microsoft y otros proveedores actuaron rápidamente para revocar los cargadores de arranque comprometidos. La diferencia aquí es la falta de acción durante años, lo que sugiere un fallo en los procesos de supervisión de Microsoft.

Históricamente, Secure Boot ha sido un pilar de la seguridad en el arranque, pero ha enfrentado múltiples desafíos. En 2016, investigadores demostraron que era posible eludir Secure Boot en dispositivos con firmware mal configurado. En 2018, se descubrieron vulnerabilidades en el propio firmware UEFI que permitían deshabilitar Secure Boot. Sin embargo, el caso actual es particularmente grave porque los shims defectuosos están firmados por Microsoft, lo que les otorga un nivel de confianza inherente. Como señaló Ars Technica, "el error es el resultado de que Microsoft, que supervisa la firma de los shims, no revocó las imágenes disponibles públicamente una vez que se encontraron vulnerabilidades en ellas".

¿Qué consecuencias tendrá?

La exposición de esta vulnerabilidad tiene implicaciones graves para la seguridad de millones de dispositivos. Los atacantes podrían obtener persistencia a nivel de firmware, lo que dificulta su detección y eliminación. Las organizaciones que dependen de Secure Boot para proteger sus sistemas críticos deben revisar sus políticas de actualización de firmware y considerar la revocación de certificados. Microsoft deberá emitir actualizaciones de seguridad para revocar estos shims y restaurar la confianza en Secure Boot. Se espera que Microsoft publique una actualización de DBX que incluya los hash de los shims defectuosos, lo que evitará que se carguen en sistemas actualizados. Sin embargo, el proceso de distribución de estas actualizaciones puede ser lento, especialmente en entornos con políticas de actualización estrictas.

Para los usuarios domésticos, el riesgo es menor, ya que la explotación requiere acceso físico o privilegios de administrador. No obstante, en entornos corporativos, donde los atacantes pueden obtener acceso físico a dispositivos o escalar privilegios mediante otras vulnerabilidades, la amenaza es real. Empresas de sectores como finanzas, salud o infraestructuras críticas deben considerar la implementación de monitoreo de integridad de firmware y soluciones de arranque seguro adicionales, como Trusted Platform Module (TPM) y medidas de verificación en tiempo de ejecución. Además, este incidente subraya la necesidad de que los fabricantes de hardware y software revisen sus procesos de firma y revocación para evitar que vulnerabilidades conocidas persistan durante años.

¿Qué deben saber los lectores?

Los usuarios deben asegurarse de tener instaladas las últimas actualizaciones de firmware y sistema operativo. Las empresas deben implementar monitoreo de integridad de firmware y considerar soluciones de arranque seguro adicionales. Aunque la vulnerabilidad es crítica, la explotación requiere acceso físico o privilegios de administrador, lo que reduce el riesgo para usuarios domésticos, pero sigue siendo una amenaza significativa para entornos corporativos. Es recomendable que los administradores de sistemas verifiquen si sus dispositivos tienen instalados shims afectados y apliquen las actualizaciones de DBX tan pronto como estén disponibles. Asimismo, deben revisar las políticas de arranque seguro y considerar la desactivación temporal de shims no esenciales hasta que se emitan las correcciones.

“La técnica es lo suficientemente simple como para ser ejecutada por hackers novatos”, señala el informe de ESET.

En conclusión, este descubrimiento pone de manifiesto una brecha crítica en la seguridad de Secure Boot que ha permanecido abierta durante más de una década. La falta de revocación por parte de Microsoft es un error que debería servir como lección para toda la industria: la seguridad no termina con la firma inicial, sino que requiere un monitoreo continuo y una respuesta rápida ante vulnerabilidades conocidas. Los usuarios y organizaciones deben mantenerse vigilantes y aplicar las actualizaciones de seguridad tan pronto como estén disponibles.