JA3- und JA4-Fingerprints in AWS WAF und darüber hinaus

JA3- und JA4-Fingerprints (ausgesprochen "dscha-drei" und "dscha-vier") sind Client-Identifikatoren, die von Diensten wie AWS WAF berechnet werden. Sie sind sehr nützlich, um Traffic-Typen zu erkennen – insbesondere, um potenzielle oder laufende Angriffe abzuwehren.

Eine kurze Geschichte

Was vielleicht überrascht: JA3 und JA4 hatten keine Vorgänger namens JA1 oder JA2. Der Name "JA3" stammt von den Initialen der drei "J.A."-Entwickler des Tools:

• John Althouse
• Josh Atkins
• Jeff Atkinson

(Quelle: ein hervorragender Vortrag von John Althouse und Jeff Atkinson selbst: Profiling And Detecting All Things SSL With JA3 )

Ihre Arbeit baute auf den Analysen von TLS-Cipher-Suites von Ivan Ristić sowie Lee Brotherston auf.

JA3 entstand bei Salesforce, JA4 ist der direkte Nachfolger und stammt von FoxIO – einem Unternehmen, das von John Althouse und einem vierten(!) J.A. mitgegründet wurde: Josh Alexander.

Beide Fingerprint-Verfahren sind Open Source. FoxIO lizenziert darüber hinaus eine erweiterte Suite namens JA4+ mit eigenen Lizenzbedingungen. AWS unterstützt aktuell keine JA4+-Funktionen, viele andere Netzwerk- und Security-Tools jedoch schon.

Eine kurze (und stark vereinfachte) Erklärung

In einem Satz: JA3- und JA4-Fingerprints sind eine Methode, Clients (alles, was auf einen Dienst zugreift) anhand von Informationen aus dem Client-Hello-Paket des initialen TLS-Handshakes zu identifizieren – unabhängig von IP-Adresse, Ports, Geolocation oder anderen üblichen Variablen.

Vereinfachter Ablauf eines TLS-1.2-Handshakes | Quelle: Wikimedia Commons

Berechnung von JA3- und JA4-Fingerprints

JA3-Fingerprints werden (wie im offiziellen Open-Source-Repository beschrieben) anhand der folgenden Felder im Client-Hello-Paket berechnet:

• TLS-Version
• Akzeptierte Cipher
• Liste der Extensions
• Elliptische Kurven
• Punktformate elliptischer Kurven

Diese Felder werden aufgezählt, in einen einzigen String sortiert und anschließend per MD5 zu einem kürzeren String gehasht.

Hier ein Wireshark-Mitschnitt eines TLS-1.3-Handshakes von meinem Rechner. Und siehe da – der JA3-Fingerprint wird angezeigt!

JA4-Client-Fingerprints nutzen die folgenden Details aus dem Client Hello, wie im JA4-Repository beschrieben:

• Protokoll (TCP oder QUIC)
• TLS-Version
• Wird SNI verwendet? (ja="d" für Domain, nein="i" für IP)
• Cipher-Suites (Anzahl und welche)
• Extensions (Anzahl und welche)
• ALPN-Extension-Wert (Application-Layer Protocol Negotiation; Beispiele sind Kurzcodes für HTTP/2, HTTP/3, POP3, DNS-over-TLS, SPDY/3 und mehr)

Eine schöne visuelle Aufschlüsselung, wie jeder Teil eines JA4-Fingerprints berechnet wird | Quelle: FoxIOs JA4-Repository; BSD-3-Clause-Lizenz.

Diese Details werden nicht per MD5 gehasht; einige Teile der Signatur sind bereits gehasht und gekürzt, sodass die Signatur nur 36 Zeichen lang ist.

Eine kurze Demo

Die Website https://ja4db.com zeigt Ihren aktuellen JA4-Fingerprint – probieren Sie es aus!

Anwendungsfall 1: Rate Limiting

Klassische Rate-Limiting-Regeln in WAFs und anderen Schutzschichten basieren in der Regel auf IP-Adressen, URI-Pfaden oder anderen Bestandteilen der Client-Anfragen.

Eine Begrenzung der Request-Rate auf Basis des spezifischen Client-Fingerprints bringt folgende Vorteile:

• Weniger False Positives, die bei IP-basierten Limits oder anderen gängigen Methoden auftreten können
• Begrenzung von Angreifern mit demselben Fingerprint bzw. Tool – unabhängig von der IP-Adresse

Sowohl Google Cloud Armor als auch AWS WAF unterstützen dieses Feature.

AWS erlaubt JA3- oder JA4-Fingerprints als Aggregation Keys für Rate-Limit-Regeln

Anwendungsfall 2: Blocklisting

Wenn Sie bereits einen oder mehrere bösartige Fingerprints kennen, setzen Sie diese einfach auf eine Blocklist. Auch hier unterstützen sowohl Google Cloud Armor als auch AWS WAF dieses Feature.

Anwendungsfall 3: Threat Hunting

Threat Hunting ist eine defensive Disziplin, mit der Bedrohungen in Ihrer Umgebung proaktiv aufgespürt werden. Werden zum Beispiel neue C2-Server-IPs öffentlich, können Sie Ihre Netzwerk-Logs auf Kommunikation mit diesen IPs prüfen.

Genauso können Sie, sofern Sie JA3-/4-Fingerprints in Ihrer Netzwerkumgebung erfassen, die Logs nach Fingerprints neu entdeckter bösartiger Clients durchsuchen. Diese Fingerprints sind schlicht ein weiteres Werkzeug in Ihrem Werkzeugkasten.

Fingerprints vs. IP-Adressen

Da JA3- und JA4-Fingerprints spezifische Details über Clients erfassen, gibt es Fälle, in denen sie für die Verteidigung deutlich nützlicher sind als das Aufspüren oder Sperren von IP-Adressen:

• Ein Angreifer mit einem eigens entwickelten Angriffsskript hat in der Regel einen einzigartigen Fingerprint, abhängig von verwendeten Bibliotheken, Betriebssystem usw.
• Traffic von Malware auf mehreren kompromittierten Firmen-Laptops weist meist denselben oder zumindest eine sehr kleine Menge an Fingerprints auf.
• Fingerprints bekannter Schadtools können geteilt und automatisch blockiert werden, noch bevor entsprechender Traffic im Netzwerk auftaucht.

JA3 vs. JA4

JA4-Fingerprints sind zu bevorzugen, JA3-Fingerprints bleiben aber nützlich, wenn Sie wissen, wonach Sie suchen. Hier einige zentrale Unterschiede:

• JA4-Fingerprints basieren auf mehr Informationen als JA3-Fingerprints.
• JA3 wurde von Salesforce entwickelt und gesponsert, wird aber nicht mehr aktiv gepflegt.
• Wie alles in der Cybersecurity entwickeln sich auch Methoden zur Erkennungsumgehung weiter. JA3 gibt es länger, und es sind mehr Wege zur Umgehung der Erkennung bekannt.
• Manche Clients (darunter Chrome und Firefox) unterstützen inzwischen die Option, Teile ihres Client-Hello-Pakets zu mischen. Das verändert den JA3-Fingerprint, während die JA4-Methode durch Sortierung konsistente Fingerprints liefert.
• Beide Fingerprint-Typen verfügen über community-gepflegte Datenbanken. Die größte öffentlich verfügbare JA3-Datenbank, die ich finden konnte, hat nach meiner Zählung etwas über 128.000 Einträge. In der JA4+-Datenbank habe ich zum Zeitpunkt dieses Artikels rund 105.000 Einträge gezählt.
• JA3 hat den längeren Stammbaum, der Support für JA4 wächst aber stetig. Während ich an diesem Artikel schrieb, hat AWS beispielsweise angekündigt, dass der Network-Firewall-Service nun JA4-Filtering unterstützt!

Weitere Aspekte

False Positives Aggressive Rate-Limiting-Regeln auf Basis von Fingerprint-Werten können viele False Positives nach sich ziehen, vor allem dann, wenn Sie viele ähnliche Clients haben. Zusätzliche Client-Daten – etwa die Header-Reihenfolge, wie in diesem AWS-Blogpost beschrieben – können dabei helfen, Sperrungen legitimer Nutzer zu minimieren.

Datenbanken wachsen noch Öffentliche JA3- und JA4-Datenbanken werden von der Community gepflegt. Sich allein darauf zu verlassen, ist daher nicht ideal, wenn Sie hochaktuelle Bedrohungserkennung benötigen. Cloud-Anbieter und Managed-Security-Services pflegen vermutlich eigene private Datenbanken bösartiger Fingerprints – Managed Rules wie die Bot-Control-Rule-Group von AWS sind also durchaus eine Überlegung wert.

Angreifer agieren unterschiedlich raffiniert Bei DoiT haben wir Kunden geholfen, sowohl sehr einfache Angriffe zu analysieren – ein einzelner Fingerprint über mehrere IPs hinweg, der auf ein simples DoS-Tool hindeutet – als auch Angriffe, die sich keinem konsistenten JA3-/4-Fingerprint zuordnen ließen. Fähigkeiten, Ressourcen und Geduld eines Angreifers können stark variieren.

Hey, was ist mit Azure? Azure verdient hier ebenfalls etwas Aufmerksamkeit! Die Azure-Tools unterstützen benutzerdefinierte JA3- und JA4-Funktionen (noch) nicht so direkt wie AWS und Google Cloud, einige Security-Tools verfügen aber bereits über Fingerprinting-Fähigkeiten:

• Das Intrusion Detection & Prevention System (IDPS) der Azure Firewall nutzt JA3-Fingerprinting in seinen Signaturregeln. Azure hat dazu einen lesenswerten Blogpost veröffentlicht.
• Azures SIEM-Tool Sentinel enthält JA3- und JA3S-Details (Server-Fingerprinting) in den Threat-Object-Daten (über STIX). Mehr dazu in der Dokumentation.

Logging und Regeln auf Basis von JA3- und JA4-Fingerprints werden in AWS gut unterstützt – im folgenden Abschnitt konzentriere ich mich auf die AWS-Funktionen.

Logging von Requests

Der erste Schritt: JA3- und JA4-Fingerprints überhaupt loggen können! Folgende AWS-Ressourcentypen unterstützen JA3- und JA4-Fingerprint-Felder in ihren Logs:

• WAF-Logs (nur für Logs zu CloudFront- und Application-Load-Balancer-Ressourcen)
• Network-Firewall-Logs (nur in bestimmten Fällen – AWS hat dazu ein Beispiel hier)

Beispielhafte AWS-WAF-Logs mit meinen JA3- und JA4-Fingerprint-Werten. Bitte nicht blockieren!

Blocken und Rate-Limiting auf Basis von Fingerprint-Werten

Dieses Feature habe ich oben bereits angesprochen – hier eine praktische Liste der referenzierten Dokumentation:

• Blocken in AWS WAF
• Rate-Limiting in AWS WAF
• Blocken in Google Cloud Armor
• Rate-Limiting in Google Cloud Armor

Logs analysieren

Hier einige CloudWatch Log Insights-Queries, die ich in der Vergangenheit zur Untersuchung von JA3- und JA4-Fingerprints im WAF-Traffic genutzt habe.

Anzahl der häufigsten JA3-Fingerprints

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

1.097? Ist das zu viel?

Anzahl der häufigsten JA4-Fingerprints, aufgeschlüsselt nach URL-Pfad und User Agent

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

Mehr Kontext macht es deutlich einfacher zu erkennen, was vor sich geht!

Fingerprints von Requests, die durch Rate-Based-Regeln blockiert wurden

Hinweis: Diese Query prüft beliebige Rate-Based-Regeln. Hilfreich, wenn Sie IP-basierte Rate-Based-Regeln im Einsatz haben und sehen möchten, ob es gemeinsame Fingerprints gibt.

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

Verschiedene Clients können dieselbe IP, aber unterschiedliche Fingerprints haben

Weitere Beispiele finden Sie in diesem AWS-Blogpost sowie in diesem re:Post-Artikel. Sie müssen sie an JA3-/4-Fingerprints anpassen, aber als Einstieg sind sie hervorragend geeignet, um zu sehen, was für Ihren Anwendungsfall sinnvoll ist.

Im Folgenden eine Liste der nützlichsten Quellen und Tools, die ich rund um JA3- und JA4-Fingerprinting gefunden habe.

Offizielle Quellen

• JA3 GitHub-Repo
• JA4+ GitHub-Repo
• TLS Fingerprinting with JA3 and JA3S (Salesforce-Blog)
• JA4+ Network Fingerprinting (FoxIO-Blog)

Tools

• ja3.me – die größte offene JA3-Fingerprint-Datenbank, die ich finden konnte
• JA3.ZONE – eine weitere Datenbank, nicht Open Source
• Die JA4+-Fingerprint-DB

Blogposts

• Ivan Ristićs ursprünglicher Blogpost zum TLS-Fingerprinting
• Lee Brotherstons ursprüngliche Arbeit zum TLS-Fingerprinting, inklusive Links zu Konferenzvorträgen
• Cloudflares Diskussion zu JA3- und JA4-Fingerprints mit Details zur Auswertung
• Unveiling Hidden Connections: JA4 Client Fingerprinting on VirusTotal

Vorträge

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