En el framework InsydeH2O, utilizado por muchos fabricantes para crear firmware UEFI para sus equipos (la implementación más común de UEFI BIOS), se han identificado 23 vulnerabilidades que permiten ejecutar código a nivel SMM (System Management Mode), que tiene un mayor prioridad (Anillo -2) que el modo hipervisor y un anillo de protección cero, y tener acceso ilimitado a toda la memoria. El problema afecta al firmware UEFI utilizado por fabricantes como Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel y Bull Atos.
La explotación de vulnerabilidades requiere acceso local con derechos de administrador, lo que hace que los problemas sean populares como vulnerabilidades de segundo nivel, utilizadas después de la explotación de otras vulnerabilidades en el sistema o el uso de métodos de ingeniería social. El acceso a nivel SMM permite ejecutar código a un nivel no controlado por el sistema operativo, el cual puede usarse para modificar firmware y dejar códigos maliciosos o rootkits ocultos en el SPI Flash que no son detectados por el sistema operativo, así como para deshabilitar la verificación en la etapa de arranque (UEFI Secure Boot, Intel BootGuard) y ataques a hipervisores para eludir los mecanismos de verificación de la integridad de los entornos virtuales.
La explotación de vulnerabilidades se puede llevar a cabo desde el sistema operativo utilizando controladores SMI (System Management Interrupt) no verificados, así como en la etapa previa a la ejecución del sistema operativo durante las etapas iniciales de arranque o al regresar del modo de suspensión. Todas las vulnerabilidades son causadas por problemas de memoria y se dividen en tres categorías:
- Llamada SMM: ejecución de su código con derechos SMM al redirigir la ejecución de controladores de interrupciones SWSMI a código fuera de SMRAM;
- Corrupción de la memoria que permite a un atacante escribir sus datos en SMRAM, un área de memoria aislada especial en la que el código se ejecuta con derechos SMM.
- Corrupción de la memoria en el código que se ejecuta en el nivel DXE (Driver eXecution Environment).
Para demostrar los principios de organización de un ataque, se ha publicado un ejemplo de un exploit que permite, a través de un ataque desde el tercer o cero anillo de protección, acceder al DXE Runtime UEFI y ejecutar su código. El exploit manipula un desbordamiento de pila (CVE-2021-42059) en el controlador UEFI DXE. Durante el ataque, el atacante puede colocar su código en el controlador DXE, que permanece activo después de reiniciar el sistema operativo, o realizar cambios en el área NVRAM del SPI Flash. Durante la ejecución, el código del atacante puede realizar cambios en áreas de memoria privilegiadas, modificar los servicios de EFI Runtime y afectar el proceso de arranque.
Fuente: opennet.ru