Una firma válida dejó de significar código seguro

Secure Boot hizo exactamente aquello para lo que se construyó, y ese fue el problema. El 14 de julio la firma de seguridad ESET publicó una investigación, dirigida por Martin Smolar, que muestra once cargadores de arranque firmados por Microsoft, todos en la versión 0.9 o inferior, que una máquina ejecuta sin reparos porque la firma es auténtica. El código tras esa firma tiene una década y está roto, pero Secure Boot comprueba al firmante, no la seguridad de lo firmado.

El resultado es un atacante capaz de ejecutar código no verificado en el arranque de casi cualquier ordenador con UEFI. ESET comunicó el hallazgo al centro de coordinación CERT/CC en febrero, y Microsoft añadió los once archivos a su lista de revocación el 9 de junio. La distancia entre una firma de confianza y un código digno de confianza es toda la historia, y el parche por sí solo no la cierra.

Cómo funciona la evasión

El atacante no rompe nada; aporta algo en lo que ya se confía. La mayoría de los sistemas UEFI llevan el certificado de terceros de Microsoft, el Microsoft Corporation UEFI CA 2011, en su lista de firmantes permitidos. Un atacante copia uno de los viejos cargadores firmados en la partición de sistema EFI, la pequeña zona de arranque del disco, y el firmware lo acepta porque la firma remite a ese certificado de confianza. No hacen falta permisos de administrador, solo la capacidad de escribir ese archivo.

A partir de ahí, tres viejas brechas hacen el trabajo. Los cargadores confían en código GRUB 2 obsoleto con un fallo de 2015 que ejecuta módulos no verificados; las versiones por debajo de 0.9 carecen de la lista de revocación que bloquearía certificados conocidos como maliciosos; y las anteriores a la 15.3 ignoran SBAT, el mecanismo más reciente pensado para retirar binarios vulnerables. Registrada como CVE-2026-8863 y CVE-2026-10797, la cadena termina con el código del atacante ejecutándose antes de que cargue el sistema operativo, el lugar ideal para esconderse.

Por qué el parche es lo fácil

Una revocación solo protege a la máquina que realmente la recibió. El arreglo de Microsoft del 9 de junio añade los once archivos a dbx, la lista de exclusión del firmware, y en las flotas Windows gestionadas esa actualización llega por los canales normales. El inconveniente es que muchas organizaciones retienen a propósito los cambios en la lista del firmware, porque una entrada dbx equivocada puede dejar un equipo sin arrancar, y ese riesgo es mayor en hardware antiguo o de arranque dual. La revocación existe; si llegó a sus máquinas es otra cuestión.

El problema de fondo es contar. El registro público de revisión de cargadores solo comenzó en 2017, y no hay una lista comparable de lo firmado antes, así que nadie puede afirmar con certeza cuántos cargadores viejos y aún de confianza andan sueltos. Once es la cifra que ESET pudo nombrar, no la que existe. Un control que depende de conocer a cada firmante de confianza es débil justo donde se acaba el inventario.

Qué conviene comprobar esta semana

Trate esto como una tarea de higiene de revocaciones, no como un único parche. Confirme que la actualización dbx del 9 de junio se aplicó de verdad en todo el parque en lugar de darlo por hecho; ESET remite a herramientas de auditoría y comprobaciones de PowerShell que informan del estado actual de revocación. Extienda la comprobación más allá de Windows, porque los servidores Linux y los dispositivos reciben el mismo arreglo a través del Linux Vendor Firmware Service, y los portátiles de arranque dual son el punto ciego clásico.

Para los operadores europeos el marco es ahora tan regulatorio como técnico. Bajo NIS2, la integridad de la cadena de arranque entra dentro de las medidas de seguridad que se espera que demuestre una entidad esencial, y un bootkit en el firmware es justo el tipo de persistencia por el que preguntará un supervisor tras un incidente. La acción del responsable es fácil de enunciar y fácil de saltarse: verifique en qué sigue confiando su firmware y demuestre que el bloqueo llegó.

Leer a continuación: 570 parches de Windows en un día, dos ya explotados  |  Un fallo de Cisco de 18 años con plazo de 3 días