Durante los últimos siete meses (y más), se puede eludir un estándar de toda la industria que protege los dispositivos Windows contra infecciones de firmware mediante una técnica simple. El martes, Microsoft finalmente solucionó la vulnerabilidad. El estado de los sistemas Linux aún no está claro.
Registrada como CVE-2024-7344, la vulnerabilidad hizo posible que los atacantes que ya tenían acceso privilegiado a un dispositivo ejecutaran firmware malicioso durante el arranque. Este tipo de ataques son particularmente dañinos porque las infecciones pueden infiltrarse en las primeras etapas del firmware en ejecución, incluso antes de que se cargue Windows o Linux. Este nivel estratégico permite que el malware eluda las protecciones instaladas por el sistema operativo y brinda la capacidad de sobrevivir incluso después de reformatear los discos duros. A partir de ese momento, el «bootkit» resultante controla el inicio del sistema operativo.
Desde 2012, Secure Boot se ha diseñado para prevenir este tipo de ataques creando una cadena de confianza que vincula cada archivo que se carga. Cada vez que se inicia un dispositivo, Secure Boot verifica que cada componente de firmware esté firmado digitalmente antes de permitir su ejecución. Verifica la firma digital del gestor de arranque del sistema operativo para garantizar que la política de arranque seguro confíe en él y que no haya sido manipulado. Secure Boot está integrado en UEFI, abreviatura de Unified Extensible Firmware Interface, el sucesor del BIOS responsable del arranque de dispositivos Windows y Linux modernos.
Una aplicación UEFI no firmada está al acecho
El año pasado, Martin Smolar, investigador de la firma de seguridad ESET, notó algo curioso sobre SysReturn, un paquete de software de recuperación de computadoras en tiempo real de Havair Technologies. Enterrada en lo más profundo hay una aplicación UEFI codificada con XOR llamada reloader.efi, que está firmada digitalmente después de superar de alguna manera a Microsoft. Proceso de inspección interna Para aplicaciones UEFI de terceros.
En lugar de implementar las funciones UEFI LoadImage y StartImage para implementar el proceso de arranque seguro, reloader.efi utilizó una personalizada. Cargador PE. Este cargador personalizado no realiza las pruebas necesarias. Cuando Smolar investigó más, encontró reloader.efi no sólo en SysReturn de Havyar, sino también en el software de recuperación de seis proveedores. Lista completa:
