Pleins feux sur les menaces : attaques sur Log4Vulgences Shell

Le complexe de vulnérabilités Log4Shell du logiciel Log4J est connu du public depuis plus de deux mois. Les chercheurs de Barracuda ont analysé les attaques et les charges détectées par nos systèmes depuis le 10 décembre 2021 et ont constaté que le volume d'attaques tentant d'exploiter ces vulnérabilités est resté relativement constant avec quelques chutes et pics au cours des deux derniers mois. Compte tenu de la popularité du logiciel, de l'exploitabilité de la vulnérabilité et de son aspect lucratif en cas de réussite de l'attaque, nous nous attendons à ce que ce modèle d'attaque continue, au moins pour le court terme.

Alors que le volume des attaques sur ces vulnérabilités reste stable, notre chercheur a découvert des informations intéressantes sur l'origine de ces attaques. La majorité des attaques provenaient d'adresses IP situées aux États-Unis, et la moitié de ces adresses IP étaient associées à AWS, Azure et d'autres centres de données. Des attaques ont également été lancées depuis le Japon, l'Allemagne, les Pays-Bas et la Russie. À noter que ce sont les IP qui ont effectué des scans et tenté des intrusions. Les charges réelles auraient été lancées à partir d'autres sites Web ou hôtes VPS compromis si l'attaque avait réussi. Ces adresses IP portant les charges sont généralement masquées au moyen de l'encodage base64 présenté dans les exemples ci-dessous.

Menaces particulièrement importantes

Vulnérabilités Log4Shell — Log4j est une bibliothèque de journalisation basée sur Java éditée par la fondation Apache. Apache Log4j <=2.14.1 Les fonctionnalités JNDI utilisées pour la configuration, les messages du journal et les paramètres ne vous protègent pas contre les appels LDAP contrôlés par les pirates et d'autres points de terminaison JNDI. Ainsi, lorsque la substitution de recherche de message est activée, le pirate peut exécuter un code arbitraire chargé à partir des serveurs LDAP en contrôlant les messages du journal ou les paramètres des messages du journal. Cette vulnérabilité touche les configurations par défaut de plusieurs frameworks Apache, notamment Apache Struts2, Apache Solr, Apache Druid et Apache Flink, qui sont utilisés par de nombreuses grandes entreprises, dont Apple, Amazon, Cloudflare, Twitter, Steam, etc.

La vulnérabilité est déclenchée par l'envoi d'une chaîne spécifique au logiciel Log4j, ce qui signifie qu'elle est simple à exploiter, mais l'omniprésence de Log4j signifie en plus de cela qu'il existe de nombreux vecteurs d'attaque.

Les détails

Voyons quelques exemples de charges qui ont tenté d'exploiter ces vulnérabilités au cours des derniers mois.

La première est une charge relativement bénigne (ou, selon votre point de vue, très agaçante) :



Après quelques recherches, nous avons trouvé cette charge Java :

Comme prévu, la vidéo YouTube de cette charge utile entraine la lecture de la chanson de « Never Gonna Give You Up » de Rick Astley. Je me demande si quelqu'un a réellement été « rickrollé » par cette charge. Comme indiqué précédemment, c'est une charge bénigne selon moi, mais que vous allez à coup sûr vouloir corriger très vite !

Charges de cryptominage

Le second exemple est quelque chose que nous avons beaucoup vu dans les premiers jours suivant la découverte de ces vulnérabilités : une charge mineure Monero. Elle est apparue en provenance de plusieurs adresses IP différentes, généralement avec des commandes masquées en base64 :

Le décodage de la chaîne de base64 nous a donné :

La charge réelle sur cette URL était ce script qui installait le mineur :

Ciblage des installations VMware

Au fil du temps, des rapports ont indiqué que le groupe de ransomware Conti cherchait à compromettre les installations VMware en utilisant les vulnérabilités Log4Shell. À notre connaissance, il s'agit principalement de mouvements latéraux au sein d'un réseau. Nous n'avons pas vu de nombreux exemples d'attaques de ransomware contre des installations VMware et cela semble être plutôt une menace interne. Cependant, tout en parcourant nos journaux, nous avons constaté d'autres tentatives d'infection de ces installations. En voici un exemple :

Le décodage a donné :

La charge a été retirée depuis que nous avons découvert le trafic ; cependant, URLhaus l'identifie comme étant un type de malware du botnet Mirai DDoS. Une autre version de ce téléchargement malveillant est toujours active et est diffusée de la même manière sur les installations VMware.

Malware DDoS

Pour notre dernier exemple, nous allons nous intéresser à un autre type de malware DDoS :

Le décodage a donné :

Il s'agit d'une variante du malware BillGates. Initialement, ce malware apparu vers 2016 ne ciblait que les systèmes Linux. Cet exemple particulier est hors ligne depuis un certain temps.

Outre ces charges, nous avons également constaté de nombreuses autres tentatives : les journaux contenaient beaucoup de Kinsing, XMRig et des variantes de Mirai et Mushtik d'après l'analyse des commandes codées en base64 figurant dans les chaînes de connexion JNDI et en supposant que les serveurs LDAP auxquels elles étaient connectées renvoyaient des charges malveillantes qui implémentaient ces commandes codées en base64. La charge la plus courante était Mirai, sous diverses formes et provenant de sources variées. La prévalence de malwares botnet DDoS semble indiquer que les pirates travaillent à la création d'un grand botnet pour une utilisation future et qu'il faut s'attendre à des attaques DDoS importantes dans un avenir proche.

Se protéger contre ces types de charges

La meilleure façon de se protéger contre Log4Shell spécifiquement est d'installer la dernière version de Log4j. Tenir ses logiciels et bibliothèques à jour permet de s'assurer que les vulnérabilités sont rapidement corrigées.

Compte tenu du nombre croissant de vulnérabilités découvertes dans les applications web, il devient de plus en plus complexe de se protéger contre les attaques. Cependant, des solutions tout-en-un existent désormais pour protéger vos applications Web contre toute exploitation hostile causée par ces vulnérabilités. Les solutions de type WAF/WAF-as-a-Service, aussi appelées services de protection des API et des applications Web (Web Application and API Protection, ou WAAP), peuvent contribuer à la protection de vos applications Web en fournissant les dernières solutions de sécurité disponibles sous forme d'un produit unique et facile à utiliser.

Rapport :La sécurité des applications : état des lieux en 2021