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,
y Rafal Wojtczuk junto con Corey
Kallenberg,
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 broken
David García
