anti-jndi

Trucs amusants contre l'abus de la récente vulnérabilité CVE-2021-44228 (Log4Shell) en utilisant des serveurs web courants.

Basé sur le post de @shipilev (https://gist.github.com/shipilev/92e709a868f3d328b6636e1bfc21cf09), j'ai porté son exemple vers Apache2. Un collègue l'a fait pour Lighttpd. J'ai décidé de rendre nos exemples publics pour plus de commodité.

Idée

Il n'y a que peu de raisons de mettre la chaîne "jndi:" dans les en-têtes de requêtes, les User Agents ou ailleurs. Actuellement, je ne connais qu'une seule raison de le faire : l'exploitation de CVE-2021-44228. Pendant que le monde est, espérons-le, occupé à corriger chaque implémentation des versions vulnérables de Log4j, il pourrait être raisonnable de ralentir les attaquants autant que possible. Alors, pourquoi ne pas leur servir quelques gigaoctets de bêtises pendant qu'ils essaient d'exploiter vos services ?

Avertissement

Les extraits de code suivants ne protègent pas vos appareils et services contre le 0-Day Log4Shell ! Veuillez mettre à jour les logiciels vulnérables, utiliser log4j2.formatMsgNoLookups=true pour désactiver les jndi-Lookups ou les mettre hors ligne jusqu'à ce qu'un correctif soit disponible ! N'utilisez ceci que sur des serveurs sans services utilisant Log4j ! Plus d'informations sur la façon d'atténuer CVE-2021-44228 : https://research.hisolutions.com/log4shell Cela ne couvrira pas non plus les appels obfusqués comme ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}.} ou tout autre chose essayant de cacher la partie "jndi:". Comme il n'y a pas de solution simple à cela, je ne couvrirai pas de techniques de détection plus avancées pour le moment. Je crois toujours que la majorité des attaques n'utiliseront pas ces techniques, donc nous pouvons toujours ennuyer la plupart des script kiddies. :)

Préparation (adopté de @shipilev)

Sous Linux, créez un fichier avec un message HTML aléatoire. Merci de ne pas utiliser le LOL de l'exemple ci-dessous, car cela facilite la tâche à l'attaquant pour implémenter un filtre générique afin de nous contourner. Nous utilisons l'utilitaire pv pour afficher la progression de la création du fichier ; vous devrez peut-être l'installer via votre gestionnaire de paquets préféré ou simplement l'omettre.

$ awk 'BEGIN { for(c=0;c<10000000;c++) printf "<p>LOL</p>" }' > 100M.html
$ (for I in `seq 1 100`; do cat 100M.html; done) | pv | gzip -9 > 10G.boomgz
$ rm 100M.html

En supposant que votre serveur web tourne sous www-data, créons un répertoire appartenant à www-data afin de ne pas avoir à téléverser une copie dans chaque racine web que le serveur est susceptible de servir :

mkdir /bombs
mv 10G.boomgz /bombs
chown -R www-data:www-data /bombs

Maintenant, passons à la partie amusante...

Nginx

Voir https://gist.github.com/shipilev/92e709a868f3d328b6636e1bfc21cf09

Tout le crédit revient à @shipilev

Apache2

Activez les modules requis

a2enmod rewrite headers ratelimit

Rendez-vous dans /etc/apache2/sites-enabled.

Ouvrez chaque fichier de configuration d'hôte avec votre éditeur préféré et insérez l'extrait de code suivant juste au-dessus de chaque ligne contenant (il peut y en avoir plus d'un) :

RewriteEngine On

RewriteCond %{THE_REQUEST} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{QUERY_STRING} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{REQUEST_URI} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{HTTP_COOKIE} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{HTTP_HOST} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{REMOTE_HOST} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{REMOTE_USER} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{HTTP_USER_AGENT} "^.*(\${jndi|\${\${).*$" [OR]
RewriteCond %{HTTP_REFERER} "^.*(\${jndi|\${\${).*$"
RewriteRule . /bombs/10G_lol.boomgz [L]

<Files ~ "\.boomgz$">
Header Set Expires "Sat, 1 Jan 2000 00:00:00 GMT"
Header Set Content-Encoding "gzip"
Header Set Content-Type "text/html"
SetOutputFilter RATE_LIMIT
SetEnv rate-limit 100
</Files>

<Directory /bombs>
allow from allow
Require all granted
</Directory>

Vous vous demandez peut-être pourquoi il y a beaucoup plus de variables que dans l'exemple initial de @shipilev. J'ai décidé d'essayer de couvrir autant d'emplacements que possible. Cela pourrait interrompre des services dans des cas très rares ; si vous souhaitez utiliser l'ensemble de vérifications d'origine, il suffit de commenter ou de supprimer les 7 premières lignes après l'instruction RewriteEngine On et de retirer les parties |\${\${ des lignes restantes.

Vous pouvez également placer le code dans un nouveau fichier, par exemple /etc/apache2/conf-available/anti-jndi.conf, et l'inclure de cette manière :

Include /etc/apache2/conf-available/anti-jndi.conf

Maintenant, enregistrez le(s) fichier(s) et rechargez la configuration Apache2 :

systemctl reload apache2

Si tout s'est bien passé, vous ne devriez pas obtenir de message d'erreur.

Lighttpd

Bientôt disponible

Tester si tout fonctionne

Vous pouvez vérifier si vous avez réussi en vous connectant à votre site modifié via curl (n'oubliez pas de remplacer your-hostname par le vrai nom d'hôte de l'un des services que vous venez de modifier :

curl -s -L your-hostname -A "\${jndi:testing}" | pv > /dev/null

Vous devriez voir une barre de progression indiquant une vitesse de téléchargement d'environ 100 kb/s. Si vous ne l'annulez pas, cela devrait être terminé après quelques minutes, selon ce que vous avez utilisé comme chaîne dans le fichier HTML initial. Pour moi, cela a pris environ 5 minutes. Maintenant, vérifiez ce qui se passe côté client :

curl -s --compressed -L your-hostname -A "\${jndi:testing}" | pv > /dev/null

Vous voyez que ce n'est plus 100 kb/s ? La compression fait son effet, c'est plusieurs gigaoctets côté client. Donc, après avoir téléchargé un tas de bêtises pendant quelques minutes, l'attaquant se retrouve avec plusieurs gigaoctets sur les bras, si les données sont stockées pour analyse. Qui sait ? :)