¡Ja! Fingerprinting de cifrado, ¿no?

Una parte muy importante (mejor, fundamental) de la inteligencia de amenazas es la adquisición de firmas que ayuden a identificar componentes de la infraestructura de una campaña. Son "puntos fijos" que nos ayudan a poder identificar y coordinar las acciones defensivas. Sin ellos, tendríamos harto difícil poner bajo la mira un objetivo que se mueve con sigilo y rapidez. Son los denominados IOC (Indicadores de compromiso).

Si encuentras un IOC en tus sistemas (habitualmente, mediante el disparo de una o varias reglas) toca examinar para descartar el falso positivo, la intrusión o su intento. Sin ellos solo nos quedaría afianzar toda la apuesta a la detección por comportamiento y las nuevas tecnologías que no dejan de ser una heurística aunque vengan con el sello de la inteligencia artificial. Necesitamos a los IOCs, al menos en el corto y medio plazo.

Un IOC de forma aislada no nos dice mucho, pero si tiramos del hilo y realizamos un ejercicio de correlación y "pintamos" el grafo dirigido nos saldrá un cuadro completo. Pasamos de tener un dato aislado a información. Con ésta última vamos a poder trazar mejor nuestros planes y si nos basamos en los "éxitos" anteriores (la inteligencia) sabremos a qué y cómo enfrentarnos de la mejor manera posible.

Conocemos varios, los clásicos: IP, dominio, hashes, e incluso los mutex que emplea el malware para, entre otras cosas, no duplicar su ejecución-infección en un sistema. Sin embargo, otros nuevos son de relativa nueva cocción, como el JA3 y JA3S o JARM.

JA3, una firma para identificar la huella de canales cifrados

Tal cual se lee en el enunciado. La idea e implementación (originaria de tres ingenieros de Salesforce (que por curiosidad, los acrónimos de los nombres de los tres son J.A.)) se basa en el hash de una cadena que es la concatenación de varios campos procedentes del intercambio (handshake) o negociación entre cliente y servidor para establecer una conexión cifrada.

Tomemos algo de aire para explicar con mayor concreción lo que acabamos de leer.

Una conexión cifrada es negociada entre las dos partes para ponerse de acuerdo en qué cifrado y que configuración van a utilizar. Si todo va bien, intercambiarán claves (Diffie-Hellman, por ejemplo) y se cifrará el payload de esa conversación.

Bien, pues antes de que se comience a cifrar hay una serie de handshakes en los que ambas partes informan de los posibles cifrados y configuración que soportan. La idea es que como muchos clientes y servidores poseen una presentación de esa configuración "fija", podemos extraer los campos que no varían y producir un hash con ellos.

Y listo, si ese hash aparece ya sabemos de qué cliente o servidor (JA3 o JA3S) se trata. Una imagen de los campos empleados para el cálculo:

Fuente.

A partir de esa información se extrae una cadena con los valores que pueden ser inspeccionados y se forma una cadena de texto que pasamos a "hashear". De hecho, la función hash empleada es la clásica MD5 (sí, es considerada insegura, pero para la misión de JA3 carece de implicaciones negativas de impacto). En JA3S (la parte de identificación del servidor) varían algunos campos pero el resultado es idéntico.

Un uso práctico de JA3

Vale, ¿pero cómo usamos esto?

Es fácil y simple. Supongamos que tenemos una regla que detecta cierto troyano con un hash, por ejemplo, un TrickBot. Pero ahora, los creadores de ese malware lanzan una nueva versión que cambia mínimamente la configuración. Ese pequeño cambio origina que la regla ya no sea válida para detectar las nuevas versiones.

Sin embargo, como los creadores siguen usando las mismas librerías criptográficas, aunque el hash haya cambiado la negociación TLS seguirá siendo la misma y seguiremos identificando a dicho troyano a menos que hagan un cambio en las librerías que empleen para cifrar las comunicaciones.

Observemos un JA3 determinado sobre la familia "TrickBot" (8916410db85077a5460817142dcbc8de):

Fuente: Captura propia.

Consultando dicho hash en la base de datos de ABUSE vemos que identifica cerca de 60.000 samples de dicha familia.

Y ahora la pregunta que muchos os estaréis haciendo: ¿No colisiona ese hash con software que use esa misma librería de esa forma en particular?

Sí, es posible. Por ello, JA3 no es una bala de plata sino un buen punto de partida para asociar familias (si se cruza con SSDEEP, por ejemplo) y da más peso a una detección por otros factores. Es decir, un "handle with care" pero que nos aporta una muy buena arista en el grafo de relaciones.

Los problemas con JA3 crecen

A pesar de su relativa corta rodadura (JA3 salió del nido en 2017), desde su implantación a hoy día se le han encontrado ciertas limitaciones importantes. En un post del equipo de ingeniería de CloudFlare las señalan y enumeran:

• Los navegadores han comenzado a emitir en orden aleatorio las extensiones TLS de las conexiones. Esto ya de por sí, destroza las firmas acumuladas cuando se trata de identificar navegadores (clientes) más actuales.
• Existen diferencias notables entre el ecosistema de herramientas y utilidades que calculan los hashes JA3. Esto hace que existan varios hashes para un mismo stack TLS. Es decir, podemos tener una regla de detección de un cierto hash JA3 mientras que el componente de detección calcula otro hash completamente distinto para el mismo objeto.
• Finalmente, critican (con razón) que JA3 se centra solo en ciertos campos de la negociación TLS, el "ClientHello"; no aprovecha el resto de campos que nos pueden ayudar a "clavar" mejor la identificación.

Pero JA3, a pesar de esas limitaciones acaecidas por el uso y la experiencia sigue siendo una idea muy buena. Así, en 2023 se presentó una nueva iteración o vuelta de tuerca para solucionar parte de las carencias ya comentadas.

JA4, la próxima generación

JA4 fue presentada por ingenieros de FoxIO en septiembre de 2023. Lo primero que llama la atención es que ya no solo son dos tipos de firma: JA3 y JA3S sino una suite completa de firmas específicas de cada capa que usa cifrado y aplicaciones o protocolos concretos:

Fuente.

Como vemos, JA4 es una familia completa de hashes orientados a extraer información típica y diferenciada de cada protocolo. Además, si leemos un hash JA4 podemos hacer una lectura del mismo, puesto que porta información hasta cierto punto interpretable a simple vista por un humano. Observemos el caso de un JA4 que sería el equivalente a un JA3:

Fuente.

Si observamos, vemos el primer fragmento del hash el cual es interpretable en una lectura. A continuación, vemos dos fragmentos que son partes del hash SHA256 de los conjuntos de cifrado soportados y las extensiones publicitadas... pero en vez de calcularlas en el orden que aparecen lo hacen ordenándolas antes de aplicarle el hash (lo que permite evadir la aleatoriedad de la que hablábamos antes).

Ya tenemos solucionada gran parte de las carencias de JA3 con ese ordenamiento de extensiones y cifrados y el "upgrade" de MD5 a SHA256 para evitar colisiones.

Además, es una suerte de hash difuso ya que, aunque solo cambie una extensión o una suite de cifrado podemos seguir haciendo una agrupación por los fragmentos que no han cambiado.

Ahora veremos un animal completamente distinto. En vez de enfocarnos a conexiones TLS lo haremos con el protocolo HTTP:

Fuente.

El JA4H está especializado en extraer firmas de una conexión HTTPS cliente. Como vemos, está organizado en cuatro fragmentos (a, b, c, d).

El primero de ellos posee información legible, que podemos entender en una lectura. Los tres siguientes sí son partes de tres hashes SHA256. Cada uno de estos tres hashes son calculados a partir del orden de aparición de las cabeceras HTTP, el hash de las cookies pero ordenadas alfabéticamente y el tercero es igual que el segundo pero con los valores de las cookies.

El hash completo no es único en sus partes. Por ejemplo, en dos conexiones podemos obtener idénticos tres primeros fragmentos y que solo varíe el cuarto, el que porta los valores de las cookies que potencialmente pueden cambiar en cada conexión a cliente. De este modo, tenemos un hash que sale del contexto de los campos de ClientHello de TLS y se aplica al del protocolo HTTP.

Conclusiones

Como decíamos al principio, la información lo es todo, pero si con ella podemos crear inteligencia entonces lo es todo y más.

Y como los ingredientes de la información son los datos, cuanto mejor sean estos mejor cocinado saldrá el plato.

Con JA3 se ha recorrido una senda que da buenos resultados, pero con la familia de hashes JA4 ahora tenemos una carretera bien asfaltada. Es cuestión de tiempo que termine siendo adoptada y veamos más bases de datos de hashes JA4 sobre los que podremos bucear para enriquecer nuestra información.

⚠️ Para recibir alertas de nuestros expertos en Ciberseguridad, suscríbete a nuestro canal en Telegram: https://t.me/cybersecuritypulse

Imagen: 8photo / Freepik.