Le point sur la détection d’empreintes JA3/S
- Détection sur TLS
- Empreinte client JA3
- Empreinte serveur JA3S
- Le couple JA3/S
- Cas d’utilisation
- Conclusion
Détection sur TLS
Quand il s’agit de détection par marqueurs, on pense de prime abord à de la détection basée sur les domaines, IP, empreintes de fichiers, mais également par certificat, notamment grâce à Certificate Transparency, … Mais cela repose sur des marqueurs volatils : un attaquant peut changer d’IP, modifier le nom de domaine qu’il utilise ou bien acheter un certificat valable.
Alors comment arriver à détecter correctement une attaque alors que tous ces paramètres changent ? C’est là qu’intervient JA3/S.
Le protocole JA3/S permet de faire de la détection de connexions malveillantes sous TLS. Il a été développé par trois personnes de Salesforce : John Althouse, Josh Atkins et Jeff Atkinson (d’où le nom JA3).
L’appellation JA3 concerne le côté client et l’appellation JA3S le côté serveur.
Nous allons d’abord voir son fonctionnement, puis son utilisation en application réelle pour déterminer si oui ou non ce protocole est viable dans notre cas.
Empreinte client JA3
Le protocole JA3 (côté serveur comme côté client) utilise différentes informations transmises lors du TLS Handshake entre un client et un serveur.
Pour rappel, le schéma du déroulement d’un TLS handshake :
Les informations collectées pour la formation de l’empreinte JA3/S se trouvent dans les phases (1) « client hello » et (2) « server hello ».
Les informations récupérées par JA3 sont les suivantes :
| SSLVersion | Versions de TLS supportées |
| Cipher | Algorithmes de chiffrement supportés par le client |
| SSLExtension | Liste d’extensions |
| EllipticCurve | Courbe elliptique utilisée |
| EllipticCurvePointFormat | Format de courbe elliptique |
On peut les voir ici :
On peut voir qu’il manque une information sur cette capture, nous verrons plus tard que cela n’est pas dérangeant.
Ces informations sont collectées sous forme d’octets puis converties en valeurs décimales. Chaque information est séparée par une virgule et si un champ comporte plusieurs valeurs, celles-ci sont séparées par un trait d’union, ce qui nous donne :
SSLVersion, Cipher1 – Cipher2 – Cipher3, SSLExtension1 – SSLExtension2 – SSLExtension3 – SSLExtension4, EllipticCurve, EllipticCurveFormat
Ce qui pourrait donner :
| 771 | 4865- 4867- 4866-… | 0-23-65281-10-… | 23-24-25 | 11 |
Ce sont ces informations concaténées comme tel qui seront utilisées pour générer l’empreinte JA3 (client donc). Si l’une de ces informations est manquante, le champ est simplement laissé vide. C’est pourquoi dans la capture montrée précédemment, il n’est pas dérangeant qu’une information soit absente (car non utilisée lors de l’échange TLS présenté).
Cette suite de chiffres est ensuite hashée avec l’algorithme MD5 pour devenir l’empreinte JA3 :
771,4865-4867-4866,0-23-65281-10,23-24-25,11 > 0e004afbef1dc7b6ca4f2b3d4f1e369e
Il peut arriver qu’un client légitime (une application interne par exemple) envoie les mêmes informations qu’un client non légitime (un malware).
Empreinte serveur JA3S
La construction de l’empreinte JA3S fonctionne de la même manière, mais avec moins d’informations côté serveur :
SSLVersion Versions de TLS supportées
Cipher Algorithmes de chiffrement supportés par le serveur
SSLExtension Liste d’extensions
On peut voir ces éléments ici :
Si l’on visualise le JA3S comme nous l’avons vu précédemment pour le JA3, cela nous donne :
| 771 | 4865 | 43-51 |
Et pour l’empreinte :
771,4865,43-51 -> f4febc55ea12b31ae17cfb7e614afda8
On voit bien dans l’exemple donné qu’il y a beaucoup moins d’informations que du côté client. Identifier uniquement un serveur peut mener à un nombre conséquent de faux positifs (FP) du fait qu’il n’est pas rare de trouver deux serveurs qui renvoient les mêmes informations. Et un seul serveur ne renvoie pas forcément les mêmes informations à deux clients.
Il n’est donc pas pertinent d’utiliser seulement des empreintes JA3S.
Le couple JA3/S
Comme dit plus haut, les empreintes client ou les empreintes serveur utilisées seules génèrent un nombre conséquent de faux positifs. Pour diminuer le nombre de faux positifs, il est recommandé d’utiliser conjointement les empreintes JA3 et JA3S, de cette façon, on peut s’assurer que le flux détecté correspond bien à la charge malveillante identifiée.
Attention cependant, être trop spécifique peut permettre à un attaquant de passer sous le radar en changeant par exemple la réponse de son serveur à son client.
Cas d’utilisation
Récemment, nous avons activé le calcul des empreintes JA3 en conditions réelles. Pour la détection, nous nous sommes basés sur la liste de sslbl.abuse.ch qui ne comporte que des JA3 mais a l’avantage d’être partagée et mise à jour. Il se trouve que certaines règles matchent avec des flux légitimes, ce qui génère un nombre trop conséquent de faux positifs pour être exploitable et fiable dans notre cas, d’où l’importance de coupler les JA3 avec les JA3S.
L’utilisation recommandée par les auteurs du protocole pour faire de la détection avec JA3/S est d’identifier les flux provenant de sources illégitimes, garder leurs empreintes JA3/S et les utiliser pour les détecter ensuite.
Il existe différentes sources pour obtenir une liste d’empreintes JA3 mais aucune ne contient les empreintes JA3S :
- abuse.ch : Source de JA3 provenant de différents bots, adwares, etc.
- com : Site des concepteurs de JA3, empreintes multiples (y compris légitimes)
- github.com/cisco/joy : Il y a une base de données d’échanges de diverses applications convertibles au format JA3 (voir github.com/Javierop20/joy2ja3)
Conclusion
JA3/S permet de faire de la détection sur SSL/TLS ce qui est non négligeable à l’heure actuelle.
Cependant, il peut devenir rapidement difficile à gérer et à utiliser en tant que moyen de détection primaire, dû au fait qu’il génère un nombre conséquent de faux positifs.
Tant qu’il n’existera pas de base ouverte où chacun peut renseigner les malwares qu’il a identifiés (bien qu’il y ait un bon début avec le travail de sslbl.abuse.ch) et récupérer la liste commune, il sera complexe d’en faire un usage avancé.
En revanche, il peut être très utile en complément d’un autre mode de détection.
Du point de vue d’une investigation, il permet de voir exactement par où l’attaquant est passé, s’il a changé d’IP ou de domaine, réitéré son attaque, s’il est toujours présent et s’il tente de revenir, peu importe qu’il passe par un autre domaine, une autre IP ou s’il utilise un autre certificat.
Pour l’utiliser au mieux, il faudrait faire la liste des couples JA3/S la plus complète possible, la comparer aux flux légitimes (certains flux légitimes ayant la même signature JA3/S que des flux d’origine malveillante) et en cas de conflits avec des signatures de flux légitimes, matcher avec un critère supplémentaire (règles Yara, éléments du certificat, …).