Utiliser ModSecurity pour appliquer un correctif virtuel à la vulnérabilité CVE-2017-5638 d’Apache Struts

Faisal MemonIngénieur logiciel

[Éditeur – Le module NGINX ModSecurity WAF pour NGINX Plus n’est officiellement plus commercialisé depuis le 1er avril 2022 et arrivera en fin de vie le 31 mars 2024. Pour plus de détails, consultez l’article F5 NGINX ModSecurity WAF arrive en fin de vie<.htmla> sur notre blog.]

De nombreuses vulnérabilités de sécurité sont découvertes dans les bibliothèques utilisées par le code des applications. Lorsqu’il n’est pas possible de déployer rapidement un correctif dans le code d’une bibliothèque, vous pouvez utiliser ModSecurity pour bloquer une tentative d’exploitation et appliquer ainsi un « correctif virtuel » au code concerné jusqu’à ce que vous puissiez mettre à niveau les bibliothèques affectées.

La vulnérabilité de la bibliothèque applicative Apache Struts (CVE-2017-5638), qui a entraîné la compromission de 143 millions de comptes chez Equifax, est un exemple d’exploitation pouvant faire l’objet d’un correctif virtuel. La signature de cette vulnérabilité est la présence des chaînes #cmd= ou #cmds= dans les en-têtes HTTP Content-Type, Content-Disposition ou Content-Length. (Pour plus de détails, voir ci-dessous.)

Avec ModSecurity, nous pouvons créer un correctif virtuel à l’aide d’une règle simple qui recherche les chaînes malveillantes dans les en-têtes HTTP concernés :

SecRule REQUEST_HEADERS:Content-Type|REQUEST_HEADERS:Content-Length|REQUEST_HEADERS:Content-Disposition "@rx #cmds?=" "id:5638,auditlog,log,deny,status:403"

Nous définissons la règle avec « SecRule », en fournissant trois paramètres :

1. Les en-têtes de requête dans lesquels effectuer la recherche, sous la forme de trois variables « REQUEST_HEADERS » reliées par l’opérateur OR
2. L’expression régulière compatible PERL (PCRE), telle que spécifiée par « @rx », qui recherche dans les en-têtes de requête spécifiés les chaînes contenant « #cmd= » ou « #cmds=
3. L’action à entreprendre

Si ModSecurity est configuré en « mode de blocage actif », il rejette tout trafic correspondant à l’expression régulière compatible Perl (PCRE), ce qui déclenche la règle.

Découvrez comment commencer à utiliser NGINX et ModSecurity ensemble grâce à notre e-book : ModSecurity 3.0 et NGINX : guide de démarrage rapide

Pourquoi utiliser un correctif virtuel ?

Dans de nombreux cas, il est plus rapide de déployer une règle dans ModSecurity que de corriger le code concerné, de le tester à nouveau, puis de le déployer en production.

Prenons l’exemple de la vulnérabilité d’Apache Struts : Struts étant une bibliothèque applicative et non un paquet du système d’exploitation, sa mise à jour dans un environnement de production d’entreprise peut prendre un certain temps. Lors du passage à une nouvelle version de Struts, chaque application qui en dépend doit être recompilée et testée avec la dernière version de la bibliothèque Struts. Une grande organisation peut compter des centaines d’applications, chacune utilisant sa propre version de la bibliothèque applicative Struts, et rester ainsi vulnérable tant que toutes les applications n’ont pas été mises à jour.

Une fois la règle personnalisée ModSecurity mise en place, vous pouvez appliquer les correctifs aux logiciels de production avec précaution et selon un calendrier raisonnable, sans subir la pression liée à leur vulnérabilité. Une fois tous les logiciels concernés mis à jour, la règle personnalisée peut être désactivée.

Fonctionnement de l’exploitation de la vulnérabilité CVE-2017-5638

Apache Struts CVE-2017-5638 est une vulnérabilité d’exécution de commandes à distance (RCE). Ce type de vulnérabilité permet à l’attaquant d’exécuter des commandes arbitraires, telles que « /bin/bash » ou « cmd.exe », sur les systèmes ciblés. L’attaquant peut alors rechercher des données sensibles dans le système de fichiers et sur le réseau, avec le même niveau d’accès que le serveur d’applications Java. Par exemple, si le serveur d’applications Java s’exécute en tant que « root », l’attaquant dispose alors des privilèges « root » sur le système ciblé.

Selon la CVE officielle, la vulnérabilité se produit lorsqu’un attaquant envoie un en-tête HTTP Content-Type malformé, Content-Disposition ou Content-Length. Apache Struts lève une exception lorsque ces en-têtes HTTP ne correspondent à aucune des valeurs attendues. Le problème vient du fait que le code de gestion des exceptions tente d’afficher l’en-tête non échappé et non valide. (Dans ce contexte, « non échappé » signifie que les commandes suspectes ne sont pas précédées de caractères empêchant leur exécution – les caractères d’échappement – comme c’est normalement le cas lors de l’affichage de code.)

L’attaquant peut insérer une expression de l’Object Graph Navigation Library (OGNL) dans l’en-tête Content-Type. OGNL permet d’exécuter des commandes système. Lorsque l’en-tête non échappé et non valide est affiché, l’expression OGNL est évaluée et toutes les commandes système qu’elle contient sont exécutées.

Les exploits sont généralement une variante de la commande « curl » ci-dessous.

curl -H "Content-Type:%{(#_='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='ls -ltr').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}" www.example.com

La syntaxe essentielle se trouve dans la seconde moitié de la commande : une occurrence de chacune des chaînes « #cmd= » et « #cmds= » (mises en évidence ci-dessus). Chacune de ces chaînes est suivie de la commande système à exécuter.

Résumé

La solution à privilégier consiste toujours à corriger immédiatement les logiciels vulnérables. Cependant, l’application de correctifs aux logiciels en production peut prendre du temps, et déployer des mises à jour dans la précipitation peut s’avérer risqué. La création d’un correctif virtuel avec ModSecurity pour les logiciels vulnérables permet de gagner du temps.

Avec l’application de correctifs virtuels, vous créez une règle ModSecurity personnalisée afin de bloquer le trafic susceptible d’exploiter une vulnérabilité de sécurité, telle que CVE-2017-5638. Vous protégez ainsi votre site contre cette attaque. Vous pouvez ensuite appliquer soigneusement les correctifs aux serveurs de production, selon un calendrier raisonnable, sans craindre d’être victime de l’attaque entre-temps.

Si vous souhaitez en savoir plus sur ModSecurity et le WAF NGINX ModSecurity, téléchargez notre livre numérique, « ModSecurity 3.0 et NGINX : guide de démarrage rapide ».

Ressources

• CVE-2017-5638 – L’avis officiel de la CVE
• CVE-2017-5638 : anatomie de la vulnérabilité Apache Struts – Une présentation détaillée de la vulnérabilité
• Bulletin de sécurité Apache Struts S2‑045 – Page d’Apache Struts consacrée à la vulnérabilité de sécurité, avec une solution de contournement
• Commentaire d’un utilisateur sur le forum ArsTechnica – Explication des raisons pour lesquelles l’application de correctifs à Apache Struts n’est pas simple

[Le module WAF NGINX ModSecurity pour NGINX Plus a officiellement cessé d’être commercialisé le 1er avril 2022 et arrivera en fin de vie le 31 mars 2024. Pour plus de détails, consultez l’article F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]

À propos de l’auteur

Faisal MemonIngénieur logiciel

Autres articles de Faisal Memon