**Descubren 11 aplicaciones UEFI firmadas por Microsoft que permiten eludir Secure Boot en sistemas actuales**
—
### 1. Introducción
En un reciente hallazgo que pone en jaque la integridad del arranque seguro en millones de equipos, investigadores en ciberseguridad han identificado 11 aplicaciones UEFI antiguas, firmadas legítimamente por Microsoft, que pueden ser aprovechadas para eludir los mecanismos de Secure Boot en la mayoría de sistemas modernos. Este descubrimiento subraya la amenaza persistente que supone la cadena de arranque, convertida en objetivo prioritario para actores maliciosos que buscan persistencia y evasión de controles de seguridad a bajo nivel.
—
### 2. Contexto del Incidente
El Unified Extensible Firmware Interface (UEFI) es el estándar predominante en firmware para hardware moderno, sustituyendo a la antigua BIOS y dotando a los sistemas de capacidades avanzadas de arranque y seguridad, entre ellas Secure Boot. Secure Boot impide la ejecución de código no autorizado durante el arranque del sistema, validando la cadena de arranque con firmas digitales. Sin embargo, la confianza depositada en binarios firmados puede convertirse en un arma de doble filo cuando aplicaciones con vulnerabilidades conocidas siguen presentes en la cadena de confianza.
El equipo de investigadores detectó que, a pesar de su antigüedad, estas 11 aplicaciones UEFI, firmadas por Microsoft, continúan siendo aceptadas por la infraestructura de Secure Boot, permitiendo la ejecución de código potencialmente malicioso en las primeras fases del arranque de la máquina.
—
### 3. Detalles Técnicos
Las aplicaciones identificadas corresponden a versiones antiguas de componentes UEFI, firmadas digitalmente por Microsoft, y que presentan vulnerabilidades explotables para la ejecución de código arbitrario en contexto de firmware. Aunque no se ha publicado una lista exhaustiva de los identificadores CVE asociados a cada binario, la naturaleza del hallazgo es similar a incidentes anteriores como el caso de BlackLotus (CVE-2022-21894), donde binarios UEFI vulnerables, firmados y no revocados, permitían la instalación de bootkits persistentes.
El vector de ataque principal consiste en la sustitución o inclusión de uno de estos binarios vulnerables en la partición EFI de un sistema objetivo. Debido a que están firmados por Microsoft y no figuran en la base de datos de revocación DBX, Secure Boot los acepta como legítimos. Un actor malicioso puede así cargar un bootkit UEFI, evadir detecciones tradicionales y obtener persistencia a nivel de firmware.
En cuanto a técnicas y tácticas, los ataques se alinean con las matrices del framework MITRE ATT&CK para Enterprise, especialmente T1542.001 (Component Firmware), T1202 (Indirect Command Execution) y T1547.001 (Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder). Indicadores de compromiso (IoC) relevantes incluyen la presencia de estos binarios específicos en la partición EFI, cambios no autorizados en la configuración de Secure Boot y artefactos de bootkits conocidos.
—
### 4. Impacto y Riesgos
El potencial de explotación es elevado: cualquier sistema que utilice Secure Boot pero acepte estos binarios vulnerables corre el riesgo de sufrir la ejecución de malware en modo pre-OS, eludiendo soluciones EDR, antivirus y otras herramientas de monitorización a nivel de sistema operativo. Los atacantes pueden desplegar bootkits UEFI, modificar la cadena de arranque y, en última instancia, obtener control total sobre el endpoint afectado.
El alcance es global, dado que la mayoría de fabricantes OEM utilizan firmas Microsoft y los binarios afectados están presentes en dispositivos de consumo, estaciones de trabajo y servidores. La ausencia de revocación en DBX implica que, según estimaciones conservadoras, más del 80% de los sistemas con firmware actualizado podrían estar expuestos, dado que las actualizaciones de DBX dependen de la coordinación entre OEMs, Microsoft y los usuarios finales.
—
### 5. Medidas de Mitigación y Recomendaciones
Para mitigar el riesgo, se recomienda:
– **Actualizar la base de datos de revocación (DBX):** Seguir las instrucciones de Microsoft y fabricantes OEM para aplicar la última actualización de DBX, revocando la confianza en los binarios vulnerables.
– **Monitorizar la partición EFI:** Implementar controles de integridad y alertas ante cambios inesperados en la partición EFI.
– **Restricción de arranque externo:** Configurar la BIOS/UEFI para impedir el arranque desde dispositivos externos no autorizados.
– **Auditoría continua:** Revisar periódicamente los registros de arranque y firmware, incluyendo el análisis de integridad de componentes UEFI.
– **Formación y concienciación:** Mantener a los equipos de respuesta y administración informados sobre las amenazas emergentes y procedimientos de recuperación ante compromisos de firmware.
—
### 6. Opinión de Expertos
Especialistas en ciberseguridad como Alex Matrosov, CEO de Binarly, advierten: “El abuso de binarios UEFI firmados pero vulnerables representa una de las vías de persistencia más difíciles de erradicar, especialmente en entornos corporativos con parque heterogéneo de hardware.” Por su parte, Microsoft ha reconocido la complejidad de revocar binarios sin afectar la compatibilidad, pero subraya la importancia de mantener actualizada la DBX y seguir las mejores prácticas de seguridad de firmware.
—
### 7. Implicaciones para Empresas y Usuarios
El incidente pone de manifiesto la necesidad crítica de gestionar la cadena de confianza en entornos Secure Boot, más allá de la actualización de sistemas operativos. Para organizaciones afectadas por normativas como GDPR o NIS2, un compromiso de firmware puede derivar en incidentes de seguridad graves con impacto regulatorio y sanciones asociadas. En el mercado, se observa una tendencia creciente hacia soluciones de monitorización específica de firmware y una presión sobre los fabricantes para acelerar la publicación de parches y revocaciones.
—
### 8. Conclusiones
La existencia de aplicaciones UEFI firmadas por Microsoft y vulnerables, aún no revocadas, abre la puerta a ataques avanzados que desafían los controles de Secure Boot y comprometen la integridad de los sistemas desde la raíz. Las empresas deben priorizar la actualización de base de datos DBX, reforzar la monitorización de firmware y adoptar una aproximación proactiva ante la gestión de la cadena de arranque, en línea con la evolución de la amenaza y las exigencias regulatorias.
(Fuente: feeds.feedburner.com)