Los rootkit, un veneno que puedes tener dentro de tu equipo sin saberlo.
Si existe un elemento malicioso con poder, temible y endiabladamente silencioso todo el mundo tiende a pensar en un rootkit. Un rootkit se instala en el mismo corazón del sistema, ahí construye su morada, habita y sale de caza cuando las condiciones le son propicias. Es devastador, el depredador perfecto, con capacidad para engañarte y los privilegios del núcleo del sistema e incluso más. Lo más parecido a un rootkit en el mundo real sería una cuenta en un paraíso fiscal. Oculta, poderosa, resistente a la ingeniería inversa y pensada para aprovecharse de los recursos del sistema mediante la perversión.
El dominio de un rootkit se mide por la capacidad de este para penetrar en el sistema. Más profundo, más privilegios. Todo el mundo piensa en el núcleo, pero imagina por un momento que antes de que el propio núcleo tenga la oportunidad de pasar por la CPU, mucho antes, existe un proceso de arranque que toma el control de todos los elementos para finalizar entregando el mando al sistema. Si es posible llegar hasta ese lugar donde comienza a despertar la máquina, el rootkit no solo será poderoso, también será inmortal.
Todo esto es lo que podría haber pasado por la cabeza del investigador portugués Pedro Vilanças (@osxreverser) cuando descubrió que todos los MacBook de Apple, anteriores a mediados de 2014, podían ser envenenados y al despertar de la hibernación notar la extraña presencia de un nuevo inquilino en el lugar.
Vilanças se interesó por los ataques a la EFI (Extensible Firmware Interface) a raíz de la recuperación de una contraseña de firmware que olvidó. Hablar de firmware e ingeniería inversa es hablar de adentrarse en una nueva dimensión donde parte del tiempo el investigador ha de alejarse del teclado para llevar sus dedos sobre los propios chips donde ya no se habla de simples variables, punteros o estructuras en memoria, sino de pulsos, frecuencias y voltajes.
A raíz de los trabajos de los investigadores: Trammell, (http://events.ccc.de/congress/2014/Fahrplan/speakers/4825.html) y Rafal Wojtczuk junto con Corey Kallenberg (http://events.ccc.de/congress/2014/Fahrplan/events/6129.html), se podía llegar a la conclusión de que la modificación del firmware con acceso físico era posible a través del ataque de Trammell, ayudado con un dispositivo denominado OptionROM. Eso dejaba el vector de ataque limitado por ese "acceso físico", lo cual no es práctico para un atacante (ya sabéis lo engorroso que es eso de montar una operación de campo: alquilar disfraces, distraer al objetivo y vigilarlo a través de un periódico agujereado desde un banco del parque).
Escribir en la BIOS no es trivial. Existen varias capas de protección para impedir una manipulación del código de la BIOS. Básicamente las operaciones que intentan escribir en direcciones mapeadas a la BIOS están protegidas por ciertas "banderas" que son comprobadas por componentes encargados de verificar los privilegios de quienes inician estas acciones. Por supuesto, los trabajos comentados publicaban técnicas para evadir estas protecciones capa por capa.
Un ataque al que se le queda corto el adjetivo de sofisticado. Pero estaba esa pega del acceso físico, la necesidad de enchufar un cacharro que portaba un exploit en un puerto Thunderbolt, eso le quitaba elegancia al ataque.
Si se tiene cierto dominio del portugués, es fácil imaginar la exclamación de sorpresa que Pedro Vilança pudo haber soltado al descubrir algo que iba a cambiar la aproximación al ataque. Es posible manipular el firmware de un MacBook en remoto, sin necesidad de hardware adicional o acceso físico.
Vilanças se dio cuenta de que las protecciones contra escritura de la BIOS se encontraban desactivadas tras la vuelta del sistema desde el modo Sleep. Curiosamente y en concreto el sistema ha de estar algo más de 30 segundos para que tal evento ocurra.
Observemos un extracto del software empleado para leer la BIOS y su estado 'flashrom', antes del modo Sleep:
SPIBAR = 0xfed1c000 + 0x3800
0x04: 0xe008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1,
FLOCKDN=1
Warning: SPI Configuration Lockdown activated.
Reading OPCODES... done
Y esta otra cuando se toma tras volver del modo Sleep:
SPIBAR = 0xfed1c000 + 0x3800 0x04: 0x6008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1,
FLOCKDN=0
Programming OPCODES... done
Asombrosamente las protecciones están desactivadas (observemos la bandera FLOCKDN, flash lockdown) y esto no pasa desapercibido incluso para el propio software, cuando avisa del bloqueo en el primer registro:
Warning: SPI Configuration Lockdown activated.
La especificación ACPI define varios niveles o estados de consumo. El estado S3 hace referencia a la suspensión del sistema en RAM, es decir, todos los componentes son "apagados" a excepción de la RAM en la que el estado del sistema es mantenido hasta la transición hacia un estado operacional. Esa transición es controlada por un proceso perteneciente al EFI y según Vilanças es posible que contenga un bug que explicaría la vulnerabilidad.
Explica el propio Vilanças en su blog que no ha encontrado el mismo fallo en unidades posteriores a mediados o finales de 2014. Se pregunta si esto ha sido parcheado por Apple. Queda la duda abierta, puesto que aun no ha salido una corrección para los firmwares afectados.
Uniendo todas las piezas queda claro que, aunque es complejo, existe ventana para manipular la BIOS de un Macbook mediante la visita de una web, abriendo un archivo de video o un documento. Si los elementos se alinean del modo adecuado la fatalidad puede llegar a morder la manzana y envenenarla.
Cualquier servicio de inteligencia hubiera cubierto de oro a Vilanças por tener exclusividad, sin embargo ahí tenemos la información y es de agradecer que todos los usuarios de un Macbook sepan que cuando su portátil se deshaga del abrazo del sueño y vuelva a mundo de los vivos puede que no sea el mismo. Es más puede que ya no sea ni suyo.
Propuso Goya que el sueño de la razón produce monstruos. Ahora sabemos que el despertar instala rootkits.
Más información:
The Empire Strikes Back Apple – how your Mac firmware security is completely brokenhttps://reverse.put.as/2015/ 05/29/the-empire-strikes-back- apple-how-your-mac-firmware- security-is-completely-broken/
No hay comentarios:
Publicar un comentario