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 hicieron posible que los atacantes instalaran 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 carga esté firmado digitalmente por el fabricante de la computadora. Boot Guard protege contra la posibilidad de que alguien manipule el SPI-chip flash conectado que almacena el UEFA, que es una pieza compleja de firmware que une el firmware del dispositivo de una PC con su sistema operativo.
Seguridad reforzada por hardware
Estos tipos de piratería ocurren normalmente 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.
Trammel 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 pueda suceder 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 controles robustos de políticas de arranque aplicadas por hardware a los fabricantes y propietarios de plataformas para autorizar qué código de BIOS puede ejecutarse en esa plataforma. Intel Boot Guard proporciona esa raíz de confianza (RoT) basada en hardware para la verificación de inicio de la plataforma, que es responsable de verificar la imagen del BIOS antes de la ejecución del BIOS. Intel Boot Guard eleva el listón de seguridad de la plataforma, lo que reduce los vectores de ataque anteriores y dificulta 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.
Guardia de bota subvertidora
Un atacante que pueda eludir Boot Guard durante la activación podría realizar una serie de actividades maliciosas. El principal de ellos es obtener las claves que se utilizan para cifrar los discos duros, siempre que las claves estén almacenadas en la memoria, como ocurre con muchas computadoras durante la 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 malintencionado que es difícil o imposible de detectar) que se ejecutaría en modo de gestión del sistema hasta el próximo reinicio. Tales implantes SMM son el tipo de cosas que se informa que tiene la NSA.
Si bien este tipo de exploits son graves, los escenarios de ataque son limitados porque el hack 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 flash de código abierto desarrollado por Hudson. en un artículo publicado esta semana, Hudson escribió:
Dado que CVE-2020-8705 requiere acceso físico, es más difícil de usar para un atacante que un exploit remoto. Sin embargo, existen algunos escenarios de ataque realistas en los que podría usarse.
Un ejemplo es el despacho de aduanas en un aeropuerto. La mayoría de los viajeros cierran su computadora portátil durante el descenso y le permiten entrar en suspensión S3. Si la agencia contradictoria toma el dispositivo al aterrizar, las claves de cifrado del disco todavía están en la memoria. El adversario puede quitar la cubierta inferior y conectar un emulador 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 localizar el proceso de la pantalla de bloqueo del sistema operativo y deshabilitarlo, 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 trasladado 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] utilizado 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 del currículum. Dado que la FPGA puede distinguir fácilmente entre un arranque en frío y la validación del sistema que se reanuda desde la suspensión, el dispositivo puede proporcionar una versión limpia del firmware con la firma correcta cuando una herramienta como flashrom lo valida o lee, y solo proporciona la versión modificada durante un currículum 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 se verá fuera de lugar en la placa base.
La solución está en
Una de las vulnerabilidades de Boot Guard provino de ajustes de configuración que los fabricantes literalmente queman 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 se debe a que 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 notificada de una vulnerabilidad que afecta a Intel Boot Guard en la cual un ataque físico puede evitar 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 está diciendo cómo solucionó una vulnerabilidad que se deriva de la configuración de los fusibles que no se pueden restablecer. Hudson sospecha que Intel hizo el cambio utilizando firmware que se ejecuta en Intel Management Engine, un coprocesador de seguridad y administración dentro del chipset de la CPU que maneja el acceso a los fusibles OTP, entre muchas otras cosas. (A principios de esta semana, Intel publicó detalles nunca antes divulgados sobre ME aquí.)
Las otras dos vulnerabilidades provienen de fallas en la forma en que las CPU recuperan el firmware cuando se encienden. Las tres vulnerabilidades se indexaron con el ID de seguimiento único CVE-2020-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 arriba, tiene una descripción mucho más detallada y técnica.