El día en que murió Stuxnet

Muy en lo profundo de uno de los bloques de configuración de Stuxnet, una variable de 8 bytes contiene un número que, si se lee como una fecha, señala el 24 de junio de 2012, la fecha en que las subrutinas de replicación del LNK de Stuxnet dejan de funcionar y el gusano deja de infectar los dispositivos de memoria USB.

La variable específica que guarda “la hora de la muerte” puede verse en la captura de pantalla anterior: “00 c0 45 4c 9c 51 cd 01” se traduce como 24 de junio de 2012 en el formato estándar de tiempo de Windows 64 bits.

Existen actualmente tres variantes conocidas de Stuxnet, todas propagadas en oleadas en diferentes fechas. La primera variante conocida se propagó el 23 de junio de 2009, a las 4:40 am GMT. La siguiente oleada se realizó el 28 de junio y después el 7 de julio.
Entonces, el 24 de junio de 2012 nos encontramos a casi tres años de la propagación inicial del gusano que se escurrió a través de organizaciones iraníes cuidadosamente seleccionadas.

Curiosamente, el 24 de junio tiene al menos otro significado en la historia de Stuxnet / Duqu.
En la actualidad, existen tres generaciones conocidas de controladores de Duqu. Datan del 3 de noviembre de 2011, del 17 de octubre de 2011, y la más reciente, del 23 de febrero de 2012. El controlador de Duqu del 3 de noviembre de 2011 es el que nos interesa en esta historia. En el offset 5190h (en la imagen debajo) aparece un bloque codificado de configuración.

El bloque de configuración está codificado con un sencillo codificador de flujo. He aquí cómo aparece el código de codificación:

Una vez descifrado, se puede leer el Duqu config:

En la imagen anterior, observamos el valor 0xAE240682 (rectángulo en rojo) junto a la llave de registro que contiene la ruta al principal cuerpo de Duqu, así como el nombre del dispositivo controlador que se usa para las comunicaciones entre procesos.
El valor 0xAE240682 puede segmentarse en cuatro partes. 0xAE es una constante mágica que se usa a través del cuerpo de Duqu y Stuxnet. Su significado es aún desconocido, pero parece que los desarrolladores lo prefieren. El resto puede leerse como 24.06.82. Esto es, en realidad, exactamente 30 años antes de la fecha de la “muerte” de Stuxnet.

La misma fecha 24 de junio de 1982 también resulta interesante. Se trata de la historia del Vuelo 9 de British Airways, también conocido como el Speedbird 9 o el Incidente de Jakarta. El 24 de junio de 1982, el City of Edinburgh, un aparato Boeing 747-236B, volaba dentro de una nube de cenizas volcánicas, producto de la erupción del Monte Galunggung.

A las 13:42 UTC, el motor número 4 tuvo problemas y comenzó a arder. Poco después falló también el motor número 2, y los motores 1 y 3 ardieron y se apagaron, dejando a la aeronave “muerta en el aire”. A más de 11.000 metros de altitud, la tripulación calculó que podrían planear unos 23 minutos, que no eran suficientes para llegar y aterrizar sanos y salvos en el aeropuerto. Ante esta situación, el capitán Eric Moody hizo un rápido e histórico anuncio a través de los altavoces:
“Damas y caballeros, les habla su capitán. Tenemos un pequeño problema. Los cuatro motores han dejado de funcionar. Estamos haciendo lo imposible para hacerlos funcionar. Confío en que no se preocupen demasiado”.
Se puede consultar la historia completa del BA009 aquí.
Por supuesto, nadie ajeno al proyecto puede afirmar por qué Stuxnet dejó de propagarse exactamente 30 años después de este incidente, o por qué esta fecha está también hard-coded en la subrutina de codificación de Duqu. Además del 24 de junio, el exploit Stuxnet MS10-061 dejó de funcionar el 1 de junio de 2011. Asimismo, el exploit MS08-067 revisa fechas antes de enero de 2030.

Sin embargo, todas estas revisiones probablemente señalan que los atacantes estaban pensando tenerlo actualizado hasta el 1 de junio de 2011, y retirarlo o remplazarlo antes del 24 de junio de 2012.
Con el descubrimiento y revelación de Flame en mayo de 2012, nos cabe esperar que más ciberarmas estén en camino, o que ya estén desplegadas.