El estado de las huellas digitales en TLS: ventajas, desventajas y perspectivas de futuro

Resumen previo

Las huellas digitales en TLS se han convertido en la herramienta del momento para que los responsables de seguridad puedan identificar qué clientes se comunican con su infraestructura de servidores. La idea nace de una investigación de Lee Brotherston de 2015 que derivó en un artículo de blog y, a su vez, en una charla en Derbycon, y se basa en que existen suficientes diferencias entre cómo los clientes individuales (y los servidores) manejan las negociaciones de TLS como para poder distinguirlos. Desde entonces, han surgido varios métodos y adaptaciones del protocolo a esa idea. 

En este artículo, repasaremos tres métodos de reconocimiento de huellas digitales, así como la información que aportan y las dificultades que acarrean.

El pionero: JA3

En 2017, tres investigadores de Salesforce (John Althouse, Jeff Atkinson y Josh Atkins) publicaron un método pasivo de reconocimiento de huellas digitales en TLS llamado JA3. JA3 se utiliza para identificar a un cliente de TLS mediante su huella digital, y JA3S es su homólogo para servidores. La popularidad de este método radica en la identificación tanto de servidores y clientes portadores de malware como de navegadores y clientes de API web.

Para calcular la huella digital de JA3, podemos recibir u observar un paquete Client Hello de TLS y extraer la versión de TLS, los cifrados aceptados, la lista de extensiones, los grupos admitidos y los formatos de curva elíptica. El proceso de extracción es muy sencillo: tomamos los valores decimales de los bytes de esos campos y los juntamos, concatenados, siguiendo las instrucciones del método.

Hash y huella digital de JA3 de ejemplo

La huella digital también puede llamarse cadena de JA3. Las implementaciones de JA3 calcularán un hash MD5 de esta huella digital. Así, se podrá compartir fácilmente y será más compacta a la hora de buscarla en bases de datos.

JA3S realiza un proceso parecido: en vez del Client Hello, utiliza el paquete Server Hello para extraer los cifrados, las extensiones y la versión de TLS. Es importante señalar que el Server Hello varía según el Client Hello; por tanto, no aporta una huella digital única equivalente a la del cliente, pero aun así resulta útil si se combina con el hash de cliente de JA3.

En cierto modo, JA3 tiene propiedades parecidas a las del agente de usuario de un navegador. Como menciona el artículo del blog del equipo de JA3, pueden surgir falsos positivos si el cliente se comporta de tal manera que resulta tener el mismo hash, o bien por un engaño deliberado. Los atacantes y los desarrolladores de bots saben de la existencia de las huellas digitales, y pueden tratar de imitar la negociación de TLS de un cliente inocuo con el fin de burlar la detección. De todas formas, engañar controles que usen JA3 aumenta los costes para los atacantes.

Bases de datos de JA3 públicas: comodidad con riesgos

Poder compartir una huella digital estándar entre equipos o dentro de organizaciones resulta muy útil en los campos de ingeniería de detección e investigación de amenazas, y es que, hoy en día, muchas plataformas y servicios ya ofrecen compatibilidad con JA3. Sin ir más lejos, un servicio y base de datos que suele salir a colación es ja3er.com.

De todas formas, estas bases de datos no son perfectas. En octubre de 2021, el equipo del Security Operations Center (SOC) de Fastly detectó una incongruencia entre ja3er y una implementación interna desarrollada para calcular huellas de JA3. Tras investigarla a conciencia, resultó provenir de la gestión de la extensión Application-Layer Protocol Settings de TLS, que aún no está registrada en la agencia IANA, pero se incluye en la implementación BoringSSL de Google. El servicio ja3er se deshace del valor de esta extensión, de modo que el sistema calcula una huella no válida.

La incoherencia en el cálculo de las huellas digitales entre distintos conjuntos de herramientas hace que compartir huellas entre organizaciones deje de aportar valor. Para entender lo extendido que podía estar este problema, creamos un experimento para detectar si otros parámetros también pueden causar incongruencias. Implementamos un cliente a medida mediante uTLS que nos permitió controlar exactamente los parámetros que se enviaban durante la negociación del TLS. A continuación dirigimos el cliente a ja3er y a nuestro servidor para comparar los resultados, y ahí vimos que los hashes tampoco coincidían.

Usamos Wireshark para confirmar que la salida correspondiera con la nuestra y que el valor de cada campo fuera el correcto. Cuando comparamos la huella digital de JA3 de nuestro sistema con la salida de ja3er, observamos que había una curva elíptica concreta, x448, que era la que causaba la incoherencia. En el registro de IANA, este campo se representa con el valor decimal 30 pero, por motivos que desconocemos, ja3er arroja un valor decimal de 1035 para el mismo campo.

Salida del script diff de JA3

Tras descubrir esto, fuimos al repositorio oficial de JA3 de Github y vimos que, el pasado octubre, otro usuario había descubierto incoherencias. Ya había notificado el problema y se había puesto en contacto con el autor por varias vías, sin al parecer recibir respuesta.

Podemos confirmar que, al escribir estas líneas, este problema sigue existiendo, por lo que recomendamos encarecidamente evitar confiar en los resultados de la base de datos o el servicio de ja3er.

Por desgracia, no hay alternativas reales: Abuse.ch cuenta con una base de datos de huellas digitales de JA3, pero se centra mucho en clientes de malware, mientras que el repositorio de JA3 original incluye referencias a listas pero no se han actualizado en años y tampoco son exhaustivas. Sin poder recurrir a un repositorio de terceros, lo mejor puede ser crear uno para tu caso de uso.

Un paso adelante en la creación de huellas digitales del servidor: JARM

En noviembre de 2020, John Althouse, junto con Andrew Smart, RJ Nunnally y Mike Brady, publicó otro método de creación de huellas digitales de TLS del servidor llamado JARM. JARM se usa para examinar y reconocer servidores y genera mayor especificidad que JA3S, que se limitaba a realizar una observación pasiva. En cambio, este nuevo método examina de forma activa y solicita información a los servidores. JARM crea 10 paquetes específicos del Client Hello de TLS y los envía, para luego realizar un hash sobre ciertos atributos de las respuestas. Dado que este método implica examinar contenido, es posible crear una huella digital de JARM de gran parte de internet de forma proactiva. Por su capacidad para buscar y rebuscar la huella digital, este método goza de gran popularidad y es compatible con muchos servicios y herramientas.

Ejemplo de huella digital de JARM

Igual que con JA3/JA3S, para defenderte no deberías recurrir solamente a un hash de JARM. Para ilustrarlo, ten en cuenta que la huella digital de JARM de Cobalt Strike es, en realidad, la de Java, de modo que, si un equipo usara la huella digital de una instalación maliciosa de Cobalt Strike para bloquear conexiones, podría terminar bloqueando otras conexiones inocuas de Java. Raphael Mudge escribió un artículo excelente sobre este tema. Si buscas servidores de Cobalt Strike en particular, tendrás que investigar más para confirmar o, cuanto menos, tener mucha seguridad de que se trata de un servidor malicioso.

Lo último: CYU

Dos años después de que se anunciara JA3, el protocolo QUIC seguía en auge, por lo que había la necesidad de poder comprobar las huellas digitales de esas conexiones de forma pasiva. Durante sus prácticas en Salesforce, Caleb Yu propuso una solución llamada hash CYU. Actualmente, las implementaciones de CYU no están tan extendidas como las de JA3, pero se pueden ver en herramientas populares como Zeek y Suricata. Ahora que HTTP/3 se ha convertido en norma oficial, creemos que irán ganando presencia CYU u otro método parecido.

El trabajo que publicaron Yu y Althouse incluye un ejemplo de una sola herramienta de ataque mediante QUIC: Merlin C2. No obstante, viendo cómo muchos clientes web habituales ya tienen compatibilidad con QUIC (curl y navegadores web incluidos), prevemos que ese número vaya creciendo.

Con vistas al futuro

Los últimos años, John Althouse y su equipo se han erigido en los motores que han impulsado las huellas digitales en canales encriptados, con un trabajo excelente digno de elogio. A partir de ahora, creemos que toda la comunidad tiene que involucrarse más para resolver los desafíos que plantean estas soluciones. No hace falta ponerse a crear toda una serie de normas, pero bastaría con tener especificaciones por escrito y conjuntos de pruebas comunes para contribuir a que las diferentes implementaciones arrojen los resultados correctos ante diversas entradas.

Animamos a los equipos de seguridad a ver y adoptar las huellas digitales como una herramienta más de su arsenal para identificar y seguir la pista de servidores y clientes maliciosos. Además, si se comparten estas huellas digitales entre equipos, mejorará la capacidad de detección de todo el mundo que se defiende de los atacantes en internet. Es importante confirmar que todos los integrantes del grupo hayan validado la huella digital de su herramienta o, cuanto menos, usan herramientas comunes para generar las huellas digitales. Si el resultado de la huella digital no inspira confianza, no obtendremos los resultados que buscamos.

Si quieres ponerte manos a la obra con los hashes de JA3 en la plataforma de Fastly, acude a las bibliotecas de Computey VCL.