Alrededor de 200.000 dispositivos Framework con Linux fueron distribuidos con componentes de UEFI Shell firmados legítimamente que incluyen la orden memory modify (mm). Según Eclypsium, esta configuración puede explotarse para burlar Secure Boot e implantar bootkits persistentes. Framework ha confirmado el problema y está liberando correcciones; se recomienda aplicar actualizaciones de firmware/BIOS/UEFI y limitar el acceso físico hasta completar todos los parches.
UEFI Shell con comando mm: por qué debilita Secure Boot
UEFI Shell es una utilidad de diagnóstico de bajo nivel que algunas plataformas distribuyen firmada para mantener la compatibilidad con Secure Boot. En la configuración afectada, el comando mm otorga acceso directo de lectura/escritura a la memoria del sistema. Eclypsium señala que un atacante puede manipular estructuras críticas, incluida la variable gSecurity2, utilizada en la verificación de firmas de módulos UEFI.
Impacto en la cadena de confianza y riesgo de bootkits
Secure Boot impone una cadena de confianza donde solo se ejecuta código verificado por claves fiables. Si gSecurity2 se sobrescribe con NULL, las comprobaciones de firma pueden deshabilitarse, permitiendo la carga de controladores o aplicaciones UEFI no confiables antes del inicio del sistema operativo. Este escenario es coherente con técnicas vistas en bootkits modernos (por ejemplo, campañas similares a BlackLotus), que buscan persistencia a nivel de arranque y evaden controles del sistema operativo.
Alcance, origen y vector de explotación
Eclypsium estima que el problema afecta a cerca de 200.000 dispositivos Framework. No hay indicios de compromiso de la cadena de suministro; el origen es una configuración insegura del UEFI Shell firmado. El atacante necesita capacidad para ejecutar el Shell en el equipo objetivo, algo plausible con acceso físico o la posibilidad de iniciar desde medios extraíbles. La explotación puede automatizarse mediante scripts de arranque UEFI (p. ej., startup.nsh), lo que facilita la persistencia tras reinicios e incluso después de reinstalar la OS.
Mitigaciones y buenas prácticas para Framework y Linux
1) Aplique las actualizaciones del fabricante: instale sin demora los parches de firmware/BIOS/UEFI de Framework que bloquean el uso inseguro de UEFI Shell y refuerzan Secure Boot. Verifique también que el sistema tenga al día la lista de revocación DBX y los metadatos SBAT que utilizan las distribuciones Linux para endurecer la validación de shim.
2) Endurezca la fase de arranque: establezca contraseñas de administración de UEFI/BIOS, deshabilite el arranque desde USB u otros medios externos, y aplique políticas de arranque restringidas (bloqueo del orden de arranque, requerir presencia física para cambios críticos).
3) Limite o desactive UEFI Shell: cuando la opción exista, deshabilite el Shell o restrinja la ejecución de controladores/aplicaciones UEFI no autorizadas. Minimizar la superficie de funcionalidades en firmware reduce el riesgo.
4) Medida temporal: retirar la clave DB de Framework: si no hay parche disponible, la eliminación de la clave DB de Framework vía BIOS puede impedir la ejecución de componentes firmados susceptibles de abuso. Esta medida puede afectar la compatibilidad; restaure las claves tras actualizar.
5) Monitorice la integridad del arranque: supervise cambios en políticas de Secure Boot y eventos de carga usando TPM Measured Boot (PCRs y registros del TCG), así como herramientas de atestación remota. Revise periódicamente la configuración UEFI en busca de modificaciones no autorizadas. Tenga en cuenta que las soluciones EDR tradicionales tienen visibilidad limitada en la fase pre-OS.
6) Respuesta ante sospecha: si se sospecha compromiso, reflash del firmware desde imágenes verificadas, limpieza de variables NVRAM y rotación de claves de Secure Boot son prácticas recomendadas para restablecer la cadena de confianza.
Este incidente demuestra que incluso herramientas diagnósticas legítimas pueden convertirse en puntos de fallo en Secure Boot. Actualizar el firmware con rapidez, reducir la posibilidad de ejecutar código en prearranque y adoptar el principio de mínimo privilegio en la capa de UEFI son medidas clave. Los equipos de TI y usuarios deberían actuar ahora: parchear, endurecer el arranque y vigilar la integridad para minimizar el riesgo de bootkits persistentes.
