ph0lk3r/anti-jndiLustige Dinge gegen den Missbrauch der kürzlich bekannt gewordenen CVE-2021-44228 (Log4Shell)-Sicherheitslücke mithilfe gängiger Webserver.
Lustige Dinge gegen den Missbrauch der kürzlich aufgetauchten Schwachstelle CVE-2021-44228 (Log4Shell) mithilfe gängiger Webserver.
Basierend auf dem Beitrag von @shipilev (https://gist.github.com/shipilev/92e709a868f3d328b6636e1bfc21cf09) habe ich sein Beispiel auf Apache2 portiert. Ein Kollege hat es für Lighttpd getan. Ich habe beschlossen, unsere Beispiele der Einfachheit halber öffentlich zu machen.
Es gibt nur wenige Gründe, den String "jndi:" in Request-Headern, User-Agents oder anderswo zu platzieren. Derzeit kenne ich nur einen einzigen Grund, das zu tun: die Ausnutzung von CVE-2021-44228. Während die Welt hoffentlich damit beschäftigt ist, jede Implementierung verwundbarer Log4j-Versionen zu patchen, könnte es sinnvoll sein, Angreifer so weit wie möglich auszubremsen. Wie wäre es also, ihnen ein paar Gigabyte Unsinn zu servieren, während sie versuchen, deine Dienste auszunutzen?
Die folgenden Codeausschnitte schützen deine Geräte und Dienste nicht vor dem Log4Shell-0-Day! Bitte aktualisiere verwundbare Software, verwende log4j2.formatMsgNoLookups=true, um jndi-Lookups zu deaktivieren, oder nimm sie offline, bis ein Patch verfügbar ist! Verwende dies nur auf Servern ohne Log4j-fähige Dienste! Weitere Informationen zur Eindämmung von CVE-2021-44228: https://research.hisolutions.com/log4shell
Dies deckt auch keine verschleierten Aufrufe wie ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}.} oder alles andere ab, das versucht, den "jndi:"-Teil zu verstecken. Da es dafür keine einfache Lösung gibt, werde ich derzeit keine fortgeschritteneren Erkennungstechniken behandeln. Ich glaube trotzdem, dass die Mehrheit der Angriffe diese nicht nutzen wird, sodass wir die meisten Script-Kiddies weiterhin ärgern können. :)
Erstelle unter Linux eine Datei mit einer zufälligen HTML-Nachricht. Bitte nicht das LOL aus dem folgenden Beispiel verwenden, da es dem Angreifer erleichtert, einen generischen Filter zu implementieren, um uns zu umgehen. Wir verwenden das pv-Dienstprogramm, um den Fortschritt der Dateierstellung anzuzeigen; du musst es möglicherweise über deinen bevorzugten Paketmanager installieren oder einfach weglassen.
$ 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
Angenommen, dein Webserver läuft als www-data, erstellen wir ein Verzeichnis, das www-data gehört, damit wir keine Kopie in jedes Webroot hochladen müssen, das der Webserver möglicherweise bedient:
mkdir /bombs
mv 10G.boomgz /bombs
chown -R www-data:www-data /bombs
Jetzt zum lustigen Teil...
Siehe https://gist.github.com/shipilev/92e709a868f3d328b6636e1bfc21cf09
Alle Credits gehen an @shipilev
Aktiviere die erforderlichen Module
a2enmod rewrite headers ratelimit
Navigiere zu /etc/apache2/sites-enabled. Öffne jede Host-Konfigurationsdatei mit deinem bevorzugten Editor und füge den folgenden Codeausschnitt direkt über jeder Zeile ein, die enthält (es könnte mehr als eine geben):
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>
Du fragst dich vielleicht, warum es so viel mehr Variablen gibt als im ursprünglichen Beispiel von @shipilev. Ich habe beschlossen, so viele Stellen wie möglich abzufangen. Dies könnte in einigen sehr seltenen Fällen Dienste unterbrechen. Wenn du also den ursprünglichen Satz von Prüfungen verwenden möchtest, kommentiere einfach die ersten 7 Zeilen nach der RewriteEngine On-Anweisung aus oder lösche sie und entferne die |\${\${-Teile der übrigen Zeilen.
Du kannst den Code auch in eine neue Datei legen, z. B. /etc/apache2/conf-available/anti-jndi.conf, und sie wie folgt einbinden:
Include /etc/apache2/conf-available/anti-jndi.conf
Speichere nun die Datei(en) und lade die Apache2-Konfiguration neu:
systemctl reload apache2
Wenn alles gut gelaufen ist, solltest du keine Fehlermeldung erhalten.
Demnächst
Du kannst überprüfen, ob du erfolgreich warst, indem du dich per curl mit deiner veränderten Website verbindest (vergiss nicht, your-hostname durch den echten Hostnamen eines der Dienste zu ersetzen, die du gerade bearbeitet hast:
curl -s -L your-hostname -A "\${jndi:testing}" | pv > /dev/null
Du solltest einen Fortschrittsbalken sehen, der eine Downloadgeschwindigkeit von etwa 100 kb/s anzeigt. Wenn du den Vorgang nicht abbrichst, sollte er nach einigen Minuten abgeschlossen sein, je nachdem, was du als String in der ursprünglichen HTML-Datei verwendet hast. Bei mir dauerte es etwa 5 Minuten. Überprüfe nun, was auf der Client-Seite passiert:
curl -s --compressed -L your-hostname -A "\${jndi:testing}" | pv > /dev/null
Siehst du, wie es nicht mehr 100 kb/s sind? Die Komprimierung tut ihre Magie, es sind einige Gigabyte auf der Client-Seite. Nachdem der Angreifer also einige Minuten lang einen Haufen Unsinn heruntergeladen hat, hat er einige Gigabyte herumliegen, sofern die Daten zur Analyse gespeichert werden. Wer weiß? :)