El estándar de toda la industria para proteger dispositivos Windows contra infecciones de firmware existe desde hace siete meses (y más) utilizando tecnología simple. El martes, Microsoft finalmente parchó la vulnerabilidad. El estado de los sistemas Linux aún no está claro.
Registrada como CVE-2014-7344, la vulnerabilidad hizo posible que un atacante que ya había obtenido acceso privilegiado a un dispositivo ejecutara firmware malicioso durante el arranque. Este tipo de ataques son particularmente dañinos porque las infecciones se esconden dentro del firmware que se ejecuta en una etapa temprana, incluso antes de que se cargue Windows o Linux. Esta ubicación estratégica permite que el malware evada las protecciones instaladas por el sistema operativo y le 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 mediante la creación de una cadena de confianza que vincula cada archivo que se carga. Cada vez que se inicia un dispositivo, Secure Boot verifica que cada pieza de firmware esté firmada digitalmente antes de permitir su ejecución. Comprueba 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 sin firmar está oculta
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 sistemas en tiempo real disponible de Hover Technologies. Enterrada en lo más profundo se encuentra la aplicación UEFI reloader.ifi con codificación XOR. Proceso de revisión interna Para aplicaciones UEFI de terceros.
En lugar de habilitar las funciones UEFI loadimage y startimage para realizar el proceso de arranque seguro, Reloader.efi utiliza un archivo personalizado Cargador de PE. Este cargador personalizado no realizó las comprobaciones requeridas. Cuando Smolar investigó más, descubrió que reloader.ifi no sólo se encontraba en la devolución del sistema de Howar, sino también en el software de recuperación de otros seis proveedores. Lista completa:
