imágenes falsas
A medida que la cantidad de datos confidenciales almacenados en las computadoras se ha disparado durante la última década, los fabricantes de hardware y software han invertido cantidades cada vez mayores de recursos para proteger los dispositivos contra ataques físicos en caso de pérdida, robo o confiscación. A principios de esta semana, Intel corrigió una serie de errores que permitían a los atacantes instalar firmware malicioso en millones de computadoras que usan sus CPU.
Las vulnerabilidades permitieron a los piratas informáticos con acceso físico anular una protección integrada por Intel en las CPU modernas que evita que se ejecute firmware no autorizado durante el proceso de arranque. Conocida como Boot Guard, la medida está diseñada para anclar una cadena de confianza directamente en el silicio para garantizar que todo el firmware que se cargue esté firmado digitalmente por el fabricante de la computadora. Boot Guard protege contra la posibilidad de que alguien manipule el chip flash conectado a SPI que almacena el UEFI, que es una pieza compleja de firmware que une el firmware del dispositivo de una PC con su sistema operativo.
Seguridad aplicada por hardware
Estos tipos de piratería suelen ocurrir cuando los atacantes conectan hardware al interior de una computadora y usan Dediprog o herramientas de programación de chips similares para reemplazar el firmware autorizado con firmware malicioso.
trasmallo hudson
Como explica Intel aquí:
La ejecución del código UEFI BIOS generalmente no está vinculada al hardware subyacente, lo que significa que este código UEFI BIOS se ejecuta sin ser verificado o medido. Por lo tanto, esto hace que todo el proceso de arranque sea vulnerable a la subversión del BIOS, ya sea que eso ocurra a través de un proceso de actualización desprotegido o simples ataques de hardware usando el reemplazo de memoria flash SPI o usando un Dediprog.
Intel Boot Guard proporciona sólidos controles de política de arranque aplicados por hardware a los fabricantes y propietarios de plataformas para autorizar qué código de BIOS se permite ejecutar en esa plataforma. Intel Boot Guard proporciona ese Root-of-Trust (RoT) basado en hardware para la verificación de arranque de la plataforma, que es responsable de verificar la imagen del BIOS antes de la ejecución del BIOS. Intel Boot Guard eleva el nivel de seguridad de la plataforma, reduciendo los vectores de ataque anteriores y dificultando el lanzamiento de ataques para subvertir el proceso de arranque.
A principios de este año, el investigador de seguridad Trammell Hudson descubrió tres vulnerabilidades que impedían que Boot Guard funcionara cuando una computadora salía del modo de suspensión. Conocido técnicamente como S3, este modo conserva todos los elementos almacenados en la memoria de la computadora, pero apaga la CPU por completo.
Protector de arranque subvertido
Un atacante que pueda eludir Boot Guard durante la reactivación podría llevar a cabo una gran cantidad de actividades maliciosas. El principal de ellos es obtener las claves utilizadas para cifrar los discos duros, siempre que las claves se almacenen en la memoria, como ocurre con muchas computadoras durante el modo de suspensión. Con eso, un atacante podría obtener las versiones descifradas de todos los datos almacenados en la computadora sin requerir la contraseña del usuario.
Un atacante también podría infectar la máquina con un rootkit (código malicioso que es difícil o imposible de detectar) que se ejecutaría en modo de administración del sistema hasta el próximo reinicio. Tales implantes SMM son el tipo de cosa que se informa que tiene la NSA.
Si bien estos tipos de vulnerabilidades son graves, los escenarios de ataque son limitados porque el ataque no se puede realizar de forma remota. Para muchas personas, los ataques que requieren acceso físico no forman parte de su modelo de amenazas. También requeriría experiencia en hardware y firmware y herramientas especiales como Dediprog o Spispy, un emulador de flash de código abierto que ha desarrollado Hudson. En un artículo publicado esta semana, Hudson escribió:
Dado que CVE-2023-8705 requiere acceso físico, es más difícil de usar para un atacante que un exploit remoto. Sin embargo, hay algunos escenarios de ataque realistas en los que podría usarse.
Un ejemplo es al pasar la aduana en un aeropuerto. La mayoría de los viajeros cierran su computadora portátil durante el descenso y permiten que entre en suspensión S3. Si la agencia adversaria toma el dispositivo al aterrizar, las claves de cifrado del disco aún están en la memoria. El adversario puede quitar la cubierta inferior y conectar un emulador de flash en el sistema como el spispy al chip flash. Pueden activar la máquina y proporcionarle su firmware a través del spispy. Este firmware puede escanear la memoria para ubicar el proceso de la pantalla de bloqueo del sistema operativo y desactivarlo, y luego permitir que el sistema se reanude normalmente. Ahora tienen acceso al dispositivo desbloqueado y sus secretos, sin necesidad de obligar al propietario a proporcionar una contraseña.
El adversario también puede instalar su propio rootkit SMM «Ring -2» en este punto, que permanecerá residente hasta el próximo reinicio completo. Esto podría proporcionarles la ejecución de código en el sistema cuando se haya movido a una red confiable, lo que podría permitir el movimiento horizontal.
Otro ejemplo es un implante de hardware que emula el flash SPI. El iCE40up5k [a small field-programmable gate array board] usado en una de las variantes del spispy cabe fácilmente dentro o debajo de un paquete SOIC-8, lo que permite un ataque persistente contra la ruta de reanudación. Dado que la FPGA puede distinguir fácilmente entre un arranque en frío y la validación del sistema que se reanuda desde el modo de suspensión, el dispositivo puede proporcionar una versión limpia del firmware con la firma correcta cuando una herramienta como flashrom lo valida o lo lee, y solo proporciona la versión modificada durante una reanudación del sueño. Este tipo de implante sería muy difícil de detectar a través del software y, si se hace bien, no parecería fuera de lugar en la placa base.
La solución está en
Una de las vulnerabilidades de Boot Guard provino de los ajustes de configuración que los fabricantes literalmente graban en la CPU a través de un proceso llamado fusibles programables de una sola vez. Se supone que los OEM tienen la opción de configurar el chip para ejecutar Boot Guard cuando una computadora sale de S3 o no. Hudson no está seguro de por qué los cinco fabricantes que probó lo tenían apagado, pero sospecha que es porque las máquinas se reanudan mucho más rápido de esa manera.
En un correo electrónico, una portavoz de Intel escribió: “Intel fue notificado de una vulnerabilidad que afecta a Intel Boot Guard en la que un ataque físico puede eludir la autenticación de Intel Boot Guard cuando se reanuda desde el estado de suspensión. Intel lanzó mitigaciones y recomienda mantener la posesión física de los dispositivos”.
Intel no dice cómo solucionó una vulnerabilidad que se deriva de la configuración de fusibles que no se puede restablecer. Hudson sospecha que Intel realizó el cambio utilizando firmware que se ejecuta en Intel Management Engine, un coprocesador de seguridad y administración dentro del conjunto de chips de la CPU que maneja el acceso a los fusibles OTP, entre muchas otras cosas. (A principios de esta semana, Intel publicó aquí detalles nunca antes revelados sobre ME).
Las otras dos vulnerabilidades surgieron de fallas en la forma en que las CPU obtuvieron el firmware cuando se encendieron. Las tres vulnerabilidades se indexaron con el ID de seguimiento único CVE-2023-8705, que recibió una calificación de gravedad alta de Intel. (Intel tiene una descripción general de todos los parches de seguridad de noviembre aquí. Los fabricantes de computadoras comenzaron a ofrecer actualizaciones esta semana. La publicación de Hudson, vinculada anteriormente, tiene una descripción mucho más detallada y técnica.
