Recientemente, Microsoft finalmente solucionó la vulnerabilidad de derivación de arranque seguro (Secure Boot) que había estado acechando en el sistema desde 2013. Los investigadores de seguridad señalaron que el problema central expuesto por este incidente no era la vulnerabilidad en sí, sino los componentes antiguos con firmas digitales pero la falta de una gestión de seguimiento eficaz.
Esta vulnerabilidad de seguridad de larga data se debe a un simple descuido administrativo: los componentes obsoletos nunca fueron revocados oficialmente. Investigadores del conocido proveedor de seguridad ESET han descubierto que un conjunto de cargadores de arranque UEFI vulnerables, algunos de los cuales se remontan a 2013, todavía se consideran componentes confiables para los sistemas de Microsoft años después de que las vulnerabilidades fueron expuestas. Esto significa que los atacantes pueden eludir sin esfuerzo el mecanismo de arranque seguro en dispositivos Windows y Linux. Se informa que el problema involucra un total de 11 archivos binarios shim, que aún contienen firmas válidas y son aceptados por los sistemas que realizan un arranque seguro. Dado que la firma es la credencial clave que permite que el código se ejecute durante el proceso de inicio, una vez que el componente confiable se ve comprometido, todos los pasos de inicio posteriores se verán afectados.
El investigador de ESET, Martin Smolár, enfatizó: "El peligro de estas versiones anteriores de shims no es que empleen nuevas vulnerabilidades, sino que no se necesitan nuevas vulnerabilidades para evitar el arranque seguro UEFI. Los atacantes no necesitan exploits sofisticados, siempre y cuando tengan una copia antigua pero aún confiable y no revocada del binario shim, y tengan conocimientos básicos sobre cómo opera UEFI shim, es suficiente para saltar esta línea de seguridad vital". En escenarios de ataque reales, los piratas informáticos pueden utilizar estas correcciones para cargar firmware malicioso antes de que se inicie el sistema operativo. Este tipo de malware es extremadamente oculto y persistente, y es difícil eliminarlo por completo incluso si reinstalas el sistema operativo o incluso reemplazas dispositivos de hardware como discos duros.
El mecanismo de arranque seguro se introdujo por primera vez en 2012 y su intención original era evitar ataques de bajo nivel. Este mecanismo requiere que cada fragmento de código de la cadena de lanzamiento esté firmado digitalmente por una autoridad confiable. Microsoft actúa como raíz de confianza en el sistema y es responsable de firmar su propio cargador de arranque y las correcciones utilizadas por otro software como Linux. De hecho, el shim es un compromiso que permite que el software que no es de Microsoft se ejecute normalmente en un entorno de arranque seguro. Una vez que Microsoft proporciona una firma para una corrección, ésta puede usar su certificado integrado para aprobar componentes posteriores.
Sin embargo, la premisa para que este mecanismo funcione eficazmente es que una vez que se descubre que una corrección tiene una vulnerabilidad, debe revocarse inmediatamente. Pero en este incidente, este mecanismo de bloqueo falló por completo. Los shims afectados provienen de una amplia gama de fuentes, que abarcan distribuidores de Linux como Red Hat, openSUSE y Oracle, así como algunas herramientas de terceros. Algunos de estos componentes existían antes de la llegada de nuevos mecanismos de protección como las listas de denegación SBAT y MOK; otros contenían fallos de código o permitían la carga de componentes con vulnerabilidades conocidas. ESET señaló específicamente una corrección de Oracle que permite ejecutar archivos binarios con la vulnerabilidad CVE-2015-5381, y el umbral técnico para explotar la vulnerabilidad es bastante bajo.
Otra parte del problema es la creciente complejidad de los mecanismos de arranque seguro. Actualmente, el sistema se basa en múltiples capas para determinar qué código se puede ejecutar, incluida una base de datos de firmas confiables, listas de revocación y nuevos mecanismos basados en versiones, como SBAT. Cada enlace requiere actualizaciones y mantenimiento precisos. Como explica Smolár, dbx es responsable de revocar archivos binarios específicos, mientras que SBAT y Secure Boot SVN de Microsoft son responsables de revocar versiones específicas. Cada componente de inicio contiene metadatos con un número de versión y se supone que el sistema intercepta cualquier componente que caiga por debajo de un umbral establecido. Pero esto depende completamente de la actualización oportuna de los datos de umbral. Vale la pena señalar que incluso si el certificado de Microsoft utilizado para firmar estas correcciones caduca, no impide automáticamente su ejecución, lo que expone completamente la dependencia de todo el sistema de la revocación activa en lugar de los mecanismos integrados de falla de caducidad.
Actualmente, los sistemas Windows que han instalado las últimas actualizaciones ya no se ven amenazados por esta vulnerabilidad; Para los usuarios de Linux, los expertos recomiendan consultar con el responsable de la distribución correspondiente, o utilizar herramientas como fwupd para confirmar si el sistema ha sido protegido.
Sin embargo, lo que suscita preocupaciones más profundas en la industria es el frágil estado de este sistema de confianza. Gestionar relaciones de confianza entre numerosos componentes, proveedores y actualizaciones frecuentes ha demostrado ser una tarea extremadamente difícil. HD Moore, director ejecutivo y fundador de runZero, dijo sin rodeos en una entrevista: "Esta es una crítica severa a todo el modelo de arranque seguro". Señaló que hay demasiados componentes firmados que carecen de un seguimiento efectivo y aún pueden usarse con fines no deseados y peligrosos. Moore concluyó: "El resultado final es que hay una gran cantidad de componentes firmados (que nadie conoce excepto Microsoft) que pueden evitar el arranque seguro, algunos de los cuales se usan para arrancar otros programas, y también tienen agujeros de seguridad generales y otros errores, lo que significa que se pueden usar para arrancar casi cualquier cosa. Todo el ecosistema está roto hasta cierto punto y necesita un reinicio completo".