Fingerprints JA3 y JA4 en AWS WAF y más allá

Los fingerprints JA3 y JA4 (que se pronuncian "jei-tri" y "jei-for") son identificadores de cliente que calculan servicios como AWS WAF, y resultan muy útiles para identificar tipos de tráfico, sobre todo a la hora de mitigar ataques potenciales o en curso.

Un poco de historia

Quizá te sorprenda, pero JA3 y JA4 no tuvieron como antecesores a JA1 y JA2. El nombre "JA3" viene de los nombres de los tres desarrolladores "J.A." de la herramienta:

• John Althouse
• Josh Atkins
• Jeff Atkinson

(Fuente: una excelente presentación a cargo de los propios John Althouse y Jeff Atkinson: Profiling And Detecting All Things SSL With JA3 )

Su trabajo se construyó sobre los esfuerzos de análisis de cipher suites de TLS de Ivan Ristić y Lee Brotherston.

JA3 nació en Salesforce, y JA4 fue su sucesor directo, creado por FoxIO, una empresa cofundada por John Althouse y un cuarto (¡!) J.A., Josh Alexander.

Si bien ambos fingerprints son open-source, FoxIO también licencia una suite más amplia llamada JA4+, con términos de licenciamiento aparte. Por ahora, AWS no admite ninguna funcionalidad de JA4+, pero muchas otras herramientas de red y seguridad sí lo hacen.

Una explicación corta (y simplificada)

En una sola frase: los fingerprints JA3 y JA4 son una forma de identificar clientes (cualquier cosa que acceda a un servicio) a partir de la información del paquete Client Hello del handshake inicial de TLS que se envía a esos servicios, sin depender de la dirección IP, los puertos, la geolocalización ni otras variables habituales.

Flujo simplificado de un handshake TLS 1.2 | Fuente: Wikimedia Commons

Cómo se calculan los fingerprints JA3 y JA4

Los fingerprints JA3 se calculan (tal como se describe en el repositorio oficial open-source) usando los siguientes campos del paquete Client Hello:

• Versión de TLS
• Cifrados aceptados
• Lista de extensiones
• Curvas elípticas
• Formatos de puntos de curvas elípticas

Estos campos se enumeran, se ordenan en una sola cadena, y luego esa cadena se pasa por hash MD5 para obtener una cadena más corta.

Aquí va una captura de Wireshark de un handshake TLS 1.3 desde mi máquina. ¡Mira, muestra el fingerprint JA3!

Los fingerprints JA4 de cliente usan los siguientes detalles del Client Hello, según se detalla en el repositorio de JA4:

• Protocolo (TCP o QUIC)
• Versión de TLS
• ¿Se usa SNI? (sí="d" para dominio, no="i" para IP)
• Cipher suites (cuántas y cuáles)
• Extensiones (cuántas y cuáles)
• Valor de la extensión ALPN (Application-Layer Protocol Negotiation; algunos ejemplos incluyen códigos cortos para HTTP/2, HTTP/3, POP3, DNS-over-TLS, SPDY/3, y más)

Un buen desglose visual que muestra cómo se calcula cada parte de un fingerprint JA4 | Fuente: repositorio JA4 de FoxIO; bajo licencia BSD-3-Clause.

Estos detalles no se hashean con MD5; algunas partes de la firma ya vienen hasheadas y truncadas, así que la firma tiene solo 36 caracteres.

Una demo rápida

El sitio https://ja4db.com te muestra tu fingerprint JA4 actual: ¡pruébalo!

Caso de uso 1: Rate limiting

Tradicionalmente, las reglas de rate limiting en WAFs u otras capas de protección se han basado en la dirección IP, la ruta URI u otras partes de las solicitudes del cliente.

Limitar la tasa de solicitudes en función del fingerprint específico del cliente trae los siguientes beneficios:

• Evitar falsos positivos que pueden darse con límites por IP u otros métodos comunes
• Limitar a atacantes con el mismo fingerprint o herramienta sin importar la dirección IP

Tanto Google Cloud Armor como AWS WAF admiten esta funcionalidad.

AWS te permite usar fingerprints JA3 o JA4 como claves de agregación en una regla de rate-limit

Caso de uso 2: Listas de bloqueo

Si ya conoces uno o más fingerprints maliciosos, basta con sumarlos a una lista de bloqueo. Tanto Google Cloud Armor como AWS WAF también admiten esta funcionalidad.

Caso de uso 3: Threat hunting

El threat hunting es una práctica defensiva orientada a detectar amenazas en tu entorno de manera proactiva. Por ejemplo, si te llegan noticias sobre nuevas direcciones IP de algún servidor C2 detectadas en circulación, puedes revisar tus logs de red para detectar cualquier comunicación con esas IPs.

De forma similar, si puedes detectar fingerprints JA3/4 en tu red, puedes revisar los logs en busca de fingerprints de clientes maliciosos recién descubiertos. Estos fingerprints son una herramienta más en tu caja.

Fingerprints vs. direcciones IP

Como los fingerprints JA3 y JA4 rastrean detalles específicos de los clientes, hay casos en los que resultan muy útiles para la defensa, en lugar de rastrear o bloquear direcciones IP:

• Un atacante con un script de ataque personalizado seguramente tendrá un fingerprint único, según las librerías que use, el sistema operativo, etc.
• El tráfico de malware en varias laptops corporativas comprometidas suele tener el mismo fingerprint, o al menos un conjunto muy reducido.
• Los fingerprints de herramientas maliciosas conocidas pueden compartirse y bloquearse de forma automática antes de que se detecte tráfico de ese tipo en la red.

JA3 vs. JA4

Es preferible usar fingerprints JA4, pero los JA3 siguen siendo útiles si sabes lo que estás buscando. Aquí van algunas diferencias clave:

• Los fingerprints JA4 se basan en más información que los JA3.
• JA3 fue creado y patrocinado por Salesforce, pero ya no se mantiene de forma activa.
• Como con todo en el mundo de la ciberseguridad, la investigación y los métodos de evasión están en constante evolución. JA3 lleva más tiempo en circulación y cuenta con métodos más conocidos para esquivar la detección.
• Algunos clientes (incluidos Chrome y Firefox) ya admiten la opción de mezclar partes de su paquete Client Hello. Eso cambia el fingerprint JA3, pero el método JA4 utiliza ordenamiento para mantener los fingerprints consistentes.
• Ambos tipos de fingerprint cuentan con bases de datos gestionadas por la comunidad. La base de datos pública de JA3 más grande que pude encontrar tiene poco más de 128.000 entradas según mi conteo. También conté unas 105.000 entradas en la base de datos JA4+ al momento de escribir esto.
• JA3 tiene un legado más largo, pero el soporte para JA4 está activo y en crecimiento. Mientras redactaba este artículo, por ejemplo, AWS anunció que su servicio Network Firewall ya admite filtrado JA4.

Otras consideraciones

Falsos positivos Aplicar reglas agresivas de rate-limiting con el valor del fingerprint como clave puede generar muchos falsos positivos, sobre todo cuando tienes muchos clientes parecidos. Sumar datos adicionales del cliente, como el orden de los headers que se detalla en este post del blog de AWS, ayuda a minimizar los bloqueos a usuarios legítimos.

Las bases de datos siguen creciendo Las bases de datos públicas de JA3 y JA4 las mantiene la comunidad, así que depender solo de ellas puede no ser ideal si necesitas detección de amenazas de vanguardia. Lo más probable es que los proveedores de cloud y los servicios gestionados de seguridad mantengan bases privadas de fingerprints maliciosos, así que vale la pena considerar el uso de reglas gestionadas como el grupo de reglas Bot Control de AWS.

La astucia del atacante varía En DoiT hemos ayudado a clientes a analizar ataques que parecían muy simples —un único fingerprint en varias IPs que sugería el uso de una herramienta básica de DoS— y también ataques que no podían atribuirse a un fingerprint JA3/4 consistente. Las capacidades, los recursos y la paciencia de cada atacante varían.

Oye, ¿y qué pasa con Azure? ¡Azure también merece un poco de atención! Sus herramientas todavía no admiten funcionalidades personalizadas relacionadas con JA3 y JA4 de la misma forma directa que AWS y Google Cloud, pero un par de sus herramientas de seguridad sí incluyen capacidades de fingerprinting:

• El sistema de Detección y Prevención de Intrusiones (IDPS) de Azure Firewall menciona que usa fingerprinting JA3 en sus reglas de firmas. Azure tiene un buen post de blog al respecto aquí.
• La herramienta SIEM de Azure, Sentinel, incluye detalles de JA3 y JA3S (fingerprinting de servidor) en los datos de objetos de amenaza (usando STIX). Más en su documentación aquí.

El logging y las reglas basadas en fingerprints JA3 y JA4 están bien soportados en AWS, así que en la siguiente sección me voy a centrar en las funciones de AWS.

Logging de solicitudes

¡El primer paso es poder loguear los fingerprints JA3 y JA4! Los siguientes tipos de recursos de AWS admiten campos de fingerprint JA3 y JA4 en sus logs:

• Logs de WAF (solo para logs relacionados con recursos de CloudFront y Application Load Balancer)
• Logs de Network Firewall (solo en algunos casos: AWS tiene un ejemplo aquí)

Logs de ejemplo de AWS WAF mostrando los valores de mis fingerprints JA3 y JA4. ¡No me bloqueen!

Bloqueo y rate-limiting según el valor del fingerprint

Ya hablé sobre esta funcionalidad en las secciones anteriores, pero aquí va una lista práctica con la documentación referenciada:

• Bloqueo en AWS WAF
• Rate-limiting en AWS WAF
• Bloqueo en Google Cloud Armor
• Rate-limiting en Google Cloud Armor

Análisis de logs

A continuación van algunas consultas de CloudWatch Log Insights que he usado para investigar fingerprints JA3 y JA4 en el tráfico de WAF.

Conteo de los principales fingerprints JA3

fields ja3Fingerprint
| stats count(*) as requestCount by ja3Fingerprint
| sort requestCount desc

¿1.097? ¿Será demasiado?

Conteo de los principales fingerprints JA4, divididos por ruta URL y user agent

parse @message /\{\"name\":\"[Uu]ser\-[Aa]gent\",\"value\"\:\"(?<useragent>[^"\}]*)/
| stats count(*) as requestCount by ja4Fingerprint, httpRequest.uri, useragent
| sort requestCount desc

¡Sumar más información hace mucho más fácil ver lo que está pasando!

Fingerprints de solicitudes bloqueadas por reglas basadas en tasa

Ten en cuenta que esto revisa cualquier regla basada en tasa. Es útil si tienes reglas basadas en IP y quieres ver si hay fingerprints en común.

fields @timestamp, httpRequest.clientIp as ClientIP, terminatingRuleId as rule, httpRequest.country as Country, ja4Fingerprint
| filter action = "BLOCK"
| filter terminatingRuleType = "RATE_BASED"
| stats count(*) as count by ja4Fingerprint, ClientIP, rule, Country | sort by count desc

Distintos clientes pueden compartir IP pero tener fingerprints diferentes

AWS tiene más ejemplos en este post de blog y en este artículo de re:Post. Tendrás que ajustarlos para incluir fingerprints JA3/4, pero es un excelente punto de partida para ver qué te puede servir según tu caso.

A continuación va una lista con algunas de las fuentes y herramientas más útiles que he encontrado sobre fingerprinting JA3 y JA4.

Fuentes oficiales

• Repositorio JA3 en GitHub
• Repositorio JA4+ en GitHub
• TLS Fingerprinting with JA3 and JA3S (blog de Salesforce)
• JA4+ Network Fingerprinting (blog de FoxIO)

Herramientas

• ja3.me: la base de datos abierta de fingerprints JA3 más grande que pude encontrar
• JA3.ZONE: otra base de datos, no open-source
• La base de datos de fingerprints JA4+

Posts de blog

• Post original de Ivan Ristić sobre fingerprinting de TLS
• Trabajo original de Lee Brotherston sobre fingerprinting de TLS, con enlaces a presentaciones de conferencias
• Análisis de Cloudflare sobre fingerprints JA3 y JA4, con detalles sobre cómo se parsean
• Unveiling Hidden Connections: JA4 Client Fingerprinting on VirusTotal

Presentaciones

• Profiling And Detecting All Things SSL With JA3 (YouTube; John Althouse y Jeff Atkinson)
• JA4+ Intro (YouTube; John Althouse)
• BSides DC 2019: Using JA3. Asking for a friend? (YouTube; Justin Warner y Ed Miles)