La NSA necesita tus actualizaciones

Aunque la noticia tiene poco más de 12 horas (apareció ayer en algunos medios chinos), no ha tardado mucho en propagarse por los medios especializados norteamericanos. Entre otros, ArsTechnica, Bruce Schenier, Wired o Dan Kaminsky tienen breves comentarios sobre las especulaciones realizadas por los investigadores chinos Lian Li y Huan Chen, de la Peking University, a partir de una investigación realizada recientemente.

Al parecer, todo surgió por casualidad a finales de 2013, mientras Li y Chen realizaban el análisis forense de tres equipos que habían sido comprometidos. Al analizar diferentes paquetes de actualización de Adobe almacenados en el equipo (que se sospechaba que podía haber servido como vector de ataque para la infección), se detectó que todos ellos presentaban una estructura similar: la propia actualización y un bloque de datos cifrado C1 que podía variar de 65536 bytes a varios MBs.

Eso no llamó la atención, pero sí lo hizo descubrir que al descifrar uno de los paquetes cifrados (medios estadounidenses apuntan a la utilización de recursos gubernamentales chinos en la investigación, lo que explicaría el alcance y profundidad de la investigación y disponer de la potencia de cálculo necesaria para el descifrado), éste contenía un segundo bloque de datos cifrado C2 y un ejecutable. El análisis del ejecutable reveló la presencia de direcciones IP no relacionadas con los direccionamientos asignados al fabricante y extractos parciales de comentarios que hacían referencias continuas al servicio de correo postal estadounidense (¿?).

Lo más curioso del caso es que este mismo patrón se repetía no sólo en diferentes equipos que no habían sido comprometidos, sino también en paquetes de actualización de otros fabricantes. Es decir, un bloque de datos cifrado C1 que contiene un bloque cifrado C2 acompañado de un ejecutable (se hallaron tres versiones de éste que variaban ligeramente la asignación de recursos) con el mismo direccionamiento.

Una vez recibido, el sistema cargaba el ejecutable en memoria “dentro” del proceso inactivo del sistema y comenzaba lo que parecía ser un proceso de descifrado del bloque de datos C2. De este modo, la presencia del proceso para el usuario no era transparente, sino invisible.

A la vista de dicho comportamiento, los investigadores dispusieron un total de doce equipos con diferentes configuraciones y se creó una infraestructura que simulaba un entorno real, pero que en realidad cuando solicitaba actualizaciones éstos eran proporcionados por falsos servidores de actualización. A partir de esto, se pudo determinar el siguiente modo de funcionamiento:

1. En un determinado momento T1, el equipo realiza dos comunicaciones hacia el exterior, aparentemente relacionadas con la actualización de un software:
   • La primera petición va al fabricante de la actualización y su contenido parece ser normal.
   • La segunda petición consiste en un stream de paquetes UDP que siguen un patrón temporal repetitivo y muy definido, que es distribuido entre varias IP (entre tres y siete) de un direccionamiento de clase C, distinto del direccionamiento del fabricante (¿servicio postal de EEUU?).
2. En un momento T2 el equipo recibe las actualizaciones, a las que acompaña el bloque cifrado C1. Éste incluye el segundo bloque cifrado C2 y el ejecutable. A continuación el sistema descifra el bloque cifrado C1, carga el programa oculto en memoria y comienza el descifrado del bloque cifrado C2. Llama la atención que el funcionamiento del protocolo de descifrado distribuido parece adaptarse a la potencia de cálculo del dispositivo y su frecuencia estimada de actualización, de modo que el usuario no perciba impacto.
3. En un momento T3 (normalmente cercano a T1), se produce una segunda comunicación, que de nuevo contiene dos comunicaciones:
   • La primera petición va al fabricante de la actualización y su contenido es un bloque de datos cifrado C3. Sorprendentemente, el sistema muestra dicha transmisión como una descarga de datos, no como una subida.
     Se observa que el tamaño de C3 está directamente relacionado con el tamaño de C2.
   • La segunda petición vuelve a ser un stream de paquetes UDP con un patrón temporal diferente, remitido de nuevo a varias IP del mismo direccionamiento de clase C (diferentes IP).

Hasta aquí, había indicios que hacían sospechar, pero los investigadores estaban interesados en la relación entre C2 y C3. Para ello, redujeron artificialmente la potencia de cálculo de uno de los equipos al mínimo, con lo que se consiguió reducir el bloque de datos cifrado C2 a un tamaño mínimo (65536 bytes). Les costó algún tiempo establecer una relación entre los paquetes cifrados.

Y aquí es donde viene lo más interesante del asunto:

• La clave de cifrado (A) del bloque C3 y del bloque C1 es la misma, lo que apunta a que el paquete C1 y C3 tienen un destino y origen común.
• Aunque hay varias claves “A”, un equipo concreto siempre trabaja con la misma.
• El tipo de cifrado de C2 es diferente a la de C1 y C3 y muy variable entre actualizaciones y equipos.
• El contenido descifrado de C2 y C3 es exactamente el mismo.
• El contenido descifrado es aleatorio y no guarda relación entre sí. Tampoco muestra ningún interés: imágenes, texto plano, páginas web, streams de vídeo, etc.

Según los investigadores, el proceso es el siguiente:

1. Un equipo recibe, junto con una actualización de software, un paquete de datos cifrado C1. Se notifica de la recepción de este paquete a una tercera parte.
2. C1 es descifrado con una clave conocida por el sistema, y se extrae C2.
3. El equipo comienza el descifrado del paquete de datos C2.
4. Una vez descifrado C2, es cifrado de nuevo con la clave de C1 lo que da como resultado C3.
5. El paquete de datos C3 es enviado al fabricante en el siguiente proceso de actualización. Se notifica de ello a una tercera parte.

Supongo que el esquema les suena ligeramente, ya que es muy parecido al de SETI. Entrando en el terreno de la especulación y la conspiración, se especula que con la connivencia de grandes fabricantes de software, organismos gubernamentales estadounidenses (en realidad todo el mundo mira a la NSA) estarían aprovechando el poder de computación no utilizado de millones de equipos en todo el mundo para el descifrado distribuido de paquetes, lo que, dicen algunos, explicaría el ingente poder de descifrado que siempre se le ha atribuido a la NSA.

No han trascendido datos concretos de la investigación (y no se espera que lo hagan en el corto plazo), aunque hasta ahora se apunta a Google, Microsoft, Fundación Mozilla, Oracle, Adobe y Apple, algunos medios apuntan que sería necesaria la colaboración de los fabricantes de hardware para ocultar parte del funcionamiento de este esquema. Se ignora si este comportamiento se encuentra también presente en dispositivos móviles.

Según Wired, algunos de los fabricantes implicados han negado informalmente los hallazgos de la investigación, y argumentan la existencia de dichos paquetes de cifrado como medida de seguridad para evitar la infección de equipos mediante actualizaciones fraudulentas. El resto ha declinado hacer declaraciones. Es previsible que en unas horas se emitan comunicaciones oficiales.

Como es de esperar, ni el Pentágono ni la NSA se han manifestado, aunque sí se sabe que Xi Jinping mantuvo hace dos días conversaciones con Barack Obama, cuyo contenido no ha trascendido.

Fuentes:

• Arstechnica: Is NSA cheating on US?
• Bruce Schneier: NSA: paranoia or reality?
• Wired: NSA, we got ya!
• Dan Kaminsky: An in-deep analysis of Li and Chen conclusions and foundings.

(Mientras escribo esto, me viene a la memoria la película Los tres días del Cóndor y un sudor frío me recorre la espalda)