Fingerprint JA3 e JA4 in AWS WAF e oltre

I fingerprint JA3 e JA4 (pronunciati "jah-three" e "jah-four") sono identificatori dei client calcolati da servizi come AWS WAF e si rivelano molto utili per identificare le tipologie di traffico, in particolare per mitigare attacchi potenziali o in corso.

Un po' di storia

Per quanto possa sorprendere, JA3 e JA4 non sono stati preceduti da JA1 e JA2. Il nome "JA3" deriva dalle iniziali dei tre sviluppatori "J.A." del tool:

• John Althouse
• Josh Atkins
• Jeff Atkinson

(Fonte: un'eccellente presentazione tenuta dagli stessi John Althouse e Jeff Atkinson: Profiling And Detecting All Things SSL With JA3 )

Il loro lavoro si è basato sulle ricerche relative all'analisi delle cipher suite TLS condotte da Ivan Ristić e da Lee Brotherston.

JA3 nasce in Salesforce, mentre JA4 ne è il diretto successore, sviluppato da FoxIO: azienda co-fondata da John Althouse e da un quarto (!) J.A., Josh Alexander.

Sebbene entrambi i fingerprint siano open-source, FoxIO concede in licenza anche una suite più ampia di fingerprint chiamata JA4+, soggetta a termini di licenza distinti. Al momento AWS non supporta nessuna funzionalità JA4+, mentre molti altri strumenti di rete e sicurezza sì.

Una spiegazione breve (e semplificata)

In una frase: i fingerprint JA3 e JA4 sono un metodo per identificare i client (qualunque cosa acceda a un servizio) sulla base delle informazioni contenute nel pacchetto Client Hello dell'handshake TLS iniziale inviato a quei servizi, indipendentemente da indirizzo IP, porte, geolocalizzazione o altre variabili comuni.

Flusso semplificato dell'handshake TLS 1.2 | Fonte: Wikimedia Commons

Calcolo dei fingerprint JA3 e JA4

I fingerprint JA3 vengono calcolati (come descritto nel repository ufficiale open-source) a partire dai seguenti campi del pacchetto Client Hello:

• Versione TLS
• Cipher accettati
• Elenco delle estensioni
• Curve ellittiche
• Formati dei punti delle curve ellittiche

Questi campi vengono enumerati e ordinati in un'unica stringa, che viene poi sottoposta ad hashing MD5 per ottenere una stringa più breve.

Ecco una cattura Wireshark di un handshake TLS 1.3 dalla mia macchina. Guarda un po', mostra il fingerprint JA3!

I fingerprint client JA4 sfruttano i seguenti dettagli del Client Hello, come illustrato nel repository JA4:

• Protocollo (TCP o QUIC)
• Versione TLS
• Viene utilizzato SNI? (sì="d" per dominio, no="i" per IP)
• Cipher suite (quante e quali)
• Estensioni (quante e quali)
• Valore dell'estensione ALPN (Application-Layer Protocol Negotiation; tra gli esempi rientrano i codici brevi per HTTP/2, HTTP/3, POP3, DNS-over-TLS, SPDY/3, e altri ancora)

Una chiara scomposizione visiva di come viene calcolata ogni parte di un fingerprint JA4 | Fonte: repository JA4 di FoxIO; con licenza BSD-3-Clause.

Questi dettagli non vengono sottoposti ad hashing MD5; alcune parti della firma sono già hashate e troncate, quindi la firma è lunga appena 36 caratteri.

Una rapida demo

Il sito https://ja4db.com mostra il suo attuale fingerprint JA4: lo provi!

Caso d'uso 1: rate limiting

Tradizionalmente, le regole di rate limiting sui WAF o su altri layer di protezione si basano sull'indirizzo IP, sul percorso URI o su altre componenti delle richieste del client.

Limitare la frequenza delle richieste in base allo specifico fingerprint del client offre i seguenti vantaggi:

• Riduce i falsi positivi che possono derivare dai limiti basati su IP o da altri criteri comuni
• Consente di limitare gli attaccanti che usano lo stesso fingerprint/tool a prescindere dall'indirizzo IP

Sia Google Cloud Armor sia AWS WAF supportano questa funzionalità.

AWS consente di utilizzare i fingerprint JA3 o JA4 come chiavi di aggregazione per una regola di rate limiting

Caso d'uso 2: blocklisting

Se conosce già uno o più fingerprint malevoli, le basta aggiungerli a una blocklist. Anche Google Cloud Armor e AWS WAF supportano questa funzionalità.

Caso d'uso 3: threat hunting

Il threat hunting è una pratica difensiva pensata per individuare in modo proattivo le minacce nel proprio ambiente. Per esempio, se viene a conoscenza di nuovi indirizzi IP di server C2 scoperti in circolazione, potrebbe controllare i log di rete per verificare se ci sono state comunicazioni con quegli IP.

Allo stesso modo, se è in grado di rilevare i fingerprint JA3/4 nel suo ambiente di rete, può analizzare i log di rete alla ricerca dei fingerprint di client malevoli appena scoperti. Questi fingerprint sono semplicemente un ulteriore strumento nella sua cassetta degli attrezzi.

Fingerprint vs. indirizzi IP

Poiché i fingerprint JA3 e JA4 tracciano dettagli specifici dei client, ci sono casi in cui risultano estremamente utili per la difesa, in alternativa al tracciamento o al blocco degli indirizzi IP:

• Un attaccante che utilizza uno script di attacco personalizzato avrà con tutta probabilità un fingerprint univoco, dipendente dalle librerie, dal sistema operativo, ecc.
• Il traffico generato da malware presente su più laptop aziendali compromessi avrà probabilmente lo stesso fingerprint, o comunque un insieme molto ristretto di fingerprint.
• I fingerprint di tool malevoli noti possono essere condivisi e bloccati automaticamente prima ancora che il relativo traffico venga rilevato sulla rete.

JA3 vs. JA4

L'uso dei fingerprint JA4 è da preferire, ma anche i fingerprint JA3 restano utili se si sa cosa cercare. Di seguito alcune differenze chiave:

• I fingerprint JA4 si basano su un numero maggiore di informazioni rispetto ai JA3.
• JA3 è stato creato e sponsorizzato da Salesforce, ma non è più attivamente mantenuto.
• Come tutto ciò che riguarda la cybersecurity, anche le tecniche e i metodi di evasione del rilevamento sono in continua evoluzione. JA3 esiste da più tempo e presenta modalità di bypass del rilevamento più note.
• Alcuni client (tra cui Chrome e Firefox) supportano ora l'opzione di mescolare alcune parti del proprio pacchetto Client Hello. Questo modifica il fingerprint JA3, mentre il metodo JA4 ricorre all'ordinamento per mantenere coerenti i fingerprint.
• Entrambi i tipi di fingerprint dispongono di database gestiti dalla community. Il più grande database JA3 pubblicamente disponibile che sono riuscito a trovare conta poco più di 128.000 voci, secondo i miei calcoli. Al momento della stesura di questo articolo ho contato anche circa 105.000 voci nel database JA4+.
• JA3 ha alle spalle una storia più lunga, ma il supporto a JA4 è attivo e in crescita. Per esempio, mentre stavo scrivendo questo articolo, AWS ha annunciato che il suo servizio Network Firewall ora supporta il filtraggio JA4!

Altre considerazioni

Falsi positivi Applicare regole di rate limiting aggressive basate sul valore del fingerprint può generare numerosi falsi positivi, soprattutto quando si hanno molti client simili tra loro. L'utilizzo di dati aggiuntivi sul client, come l'ordine degli header descritto in questo blog post di AWS, può aiutare a ridurre al minimo i blocchi sugli utenti legittimi.

I database sono ancora in crescita I database pubblici JA3 e JA4 sono mantenuti dalla community, quindi affidarsi esclusivamente a essi potrebbe non essere ideale se le serve un rilevamento delle minacce all'avanguardia. I cloud provider e i servizi di sicurezza gestiti mantengono con tutta probabilità database privati di fingerprint malevoli, quindi vale la pena valutare l'utilizzo di regole gestite come il Bot Control rule group di AWS.

L'astuzia degli attaccanti varia In DoiT abbiamo aiutato i clienti ad analizzare attacchi che apparivano molto semplici — un singolo fingerprint distribuito su più IP, indizio dell'utilizzo di un tool DoS basilare — così come attacchi che davvero non potevano essere ricondotti a un fingerprint JA3/4 coerente. Capacità, risorse e pazienza variano da attaccante ad attaccante.

E Azure? Anche Azure merita spazio in questa discussione! Gli strumenti di Azure non supportano funzionalità personalizzate legate a JA3 e JA4 con la stessa immediatezza di AWS e Google Cloud (almeno per ora), ma un paio dei suoi tool di sicurezza includono comunque capacità di fingerprinting:

• L'Intrusion Detection & Prevention System (IDPS) di Azure Firewall specifica che utilizza il fingerprinting JA3 nelle proprie regole di firma. Azure ha pubblicato un interessante blog post a riguardo.
• Il SIEM di Azure, Sentinel, include i dettagli JA3 e JA3S (fingerprinting del server) nei dati degli oggetti di minaccia (tramite STIX). Maggiori informazioni nella relativa documentazione.

Il logging e le regole basate sui fingerprint JA3 e JA4 sono ben supportati in AWS, e nella sezione che segue mi concentrerò proprio sulle funzionalità AWS.

Logging delle richieste

Il primo passo è poter registrare i fingerprint JA3 e JA4! Le seguenti tipologie di risorse AWS supportano i campi dei fingerprint JA3 e JA4 nei rispettivi log:

• Log WAF (solo per i log relativi alle risorse CloudFront e Application Load Balancer)
• Log di Network Firewall (solo in alcuni casi: AWS riporta un esempio qui)

Esempio di log AWS WAF con i miei valori di fingerprint JA3 e JA4. Non bloccatemi!

Blocco e rate limiting basati sui valori dei fingerprint

Ne ho già parlato nelle sezioni precedenti, ma ecco un comodo elenco della documentazione di riferimento:

• Blocco in AWS WAF
• Rate limiting in AWS WAF
• Blocco in Google Cloud Armor
• Rate limiting in Google Cloud Armor

Analisi dei log

Di seguito alcune query di CloudWatch Log Insights che ho usato in passato per analizzare i fingerprint JA3 e JA4 nel traffico WAF.

Conteggio dei principali fingerprint JA3

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

1.097? Saranno troppi?

Conteggio dei principali fingerprint JA4, suddivisi per percorso URL e user agent

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

Aggiungere informazioni rende più facile capire cosa sta succedendo!

Fingerprint delle richieste bloccate da regole rate-based

Si noti che questa query controlla qualsiasi regola rate-based. È utile se ha già regole rate-based basate su IP e vuole verificare se ci sono fingerprint ricorrenti.

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

Client diversi possono avere lo stesso IP ma fingerprint differenti

AWS riporta ulteriori esempi in questo blog post e in questo articolo re:Post. Dovrà personalizzarli per includere i fingerprint JA3/4, ma sono un ottimo punto di partenza per capire cosa può tornarle utile nel suo scenario.

Di seguito un elenco delle fonti e degli strumenti più utili che ho trovato sul fingerprinting JA3 e JA4.

Fonti ufficiali

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

Strumenti

• ja3.me — il più grande database aperto di fingerprint JA3 che ho trovato
• JA3.ZONE — un altro database, non open-source
• Il database dei fingerprint JA4+

Blog post

• Il blog post originale di Ivan Ristić sul fingerprinting TLS
• Il lavoro originale di Lee Brotherston sul fingerprinting TLS, con link alle presentazioni in conferenza
• L'analisi di Cloudflare sui fingerprint JA3 e JA4, con dettagli sul loro parsing
• Unveiling Hidden Connections: JA4 Client Fingerprinting on VirusTotal

Presentazioni

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