Archiv verlassen und diese Seite im Standarddesign anzeigen : Server exploit gesucht
Auf einem SuSE 7.1 Server mit apache, proftpd, sshd und weiteren Diensten wurde eingebrochen.
In /tmp/ liegen folgende Dateien:
-rw-r--r-- 1 wwwrun nogroup 14138 Jan 5 05:32 a.tgz
-rw-r--r-- 1 wwwrun nogroup 463868 Dec 25 02:01 mf.tgz
Wie die dahin gekommen sind weiss ich noch nicht, entpackt sehen sie so aus:
bei a.tgz:
-rwxr-xr-x 1 wwwrun nogroup 18847 Feb 4 02:00 e
-rwxr-xr-x 1 wwwrun nogroup 23280 Jan 5 01:22 ee
-rwxr-xr-x 1 wwwrun nogroup 113 Jun 23 2001 heh
bei mf.tgz:
-rw-r--r-- 1 1227 1053 430885 Jan 14 2002 bin.tgz
-rw-r--r-- 1 1227 1053 492 Jan 14 2002 conf.tgz
-rw-r--r-- 1 1227 1053 28999 Jan 12 2001 lib.tgz
-rwxr-xr-x 1 1227 1053 12002 Dec 25 02:00 setup
Das Scipt Setup hab ich mal angehängt... zum durchlesen. Dass es ein rootkit ist war klar, wurde aber nicht eingesetzt :o
Im Programm "e" sieht man mit dem Editor Worte wie
/usr/bin/passwd^@fork: victim^@ptrace: PTRACE_ATTACH^@ptrace: PTRACE_CONT^@ptrace: PTRACE_GETREGS^@ptrace: PTRACE_POKETEX^@Greetings from the [ODM] team =)
^@http://www.evil-mind.net.
Im Programm "ee" sieht man das hier:
traceroute-exploit - By Carl Livitt (carl@learningshophull.co.uk)
Exploits traceroute-nanog 6.0 -> 6.1.1 and others on SuSE 7.x/8.0
Usage:
./traceroute-exploit < -d | -e > [ options ]
Options:
-d Run in daemon mode (stage 1)
-e Run in exploit mode (stage 2)
-h Display this help
-H host Traceroute to 'host' [www.yahoo.com]
-s server Specify host running exploit daemon [localhost]
-S service Name of service port on exploit daemon host [ap]
ap = port 47806/tcp (see /etc/services)
-t filename Full path to traceroute binary [/usr/sbin/traceroute]
-b bufsize Size of shellcode buffer [64128]
-v Be verbose
Example (works on SuSE 7.x/8.0):
./traceroute-exploit -d
./traceroute-exploit -e
Example 2 (uses mysql port(3306)):
./traceroute-exploit -d -S mysql
./traceroute-exploit -e -S mysql
Das Script "heh" ist nur kurz:
cat /usr/lib/* > ptrace&
sleep 5
kill -9 `ps -ax | grep cat | grep -v grep | awk '{print $1}'`
rm -rf ptrace
./e
Genialerweise merkte der Besitzer dass der Prozess "ee" dreimal lief, von wem er gestartet wurde und wann keine Spur. Den logdateien kann man eh nichtmehr vertrauen, auffällige Spuren sind keine drin.
Welche Möglichkeiten waren vorhanden 1. die Dateien in /tmp/ zu deponieren und 2. den Prozess "ee" zu starten?
Und warum hat er das rootkit nicht eingesetzt? Was tut genau das Programm "ee" ?
Fragen über Fragen.. die Festplatte ist zur Zeit zum Untersuchen mit einem "trusted" Rechner gemountet. Aufgesetzt wird sie natürlich auch neu und der Besitzer weiss jetzt auch was man tun muss um solche "Script Kiddies" fernzuhalten..
Grüsse, Stefan
Ich gehe davon asu, dass das System kein Security update erfahren hat. Damit waren alle 3 von dir genannten Programme anfällig (apache, sshd und proftpd). Bei proftpd bin ich mir jetzt allerdings nicht 100% sicher.
1). evtl. hat er sie sich selbst mittels ftp hochgeladen (oder mit ftp heruntergeladen). Eigentlich gibts ziemlich viele Möglichkeiten wie er sie auf den Rechner gebracht haben könnte.
2) ee nutzt anscheinend eine Schwachstelle in Traceroute um root zu werden.
HTH
Original geschrieben von geronet
Und warum hat er das rootkit nicht eingesetzt?
Zumindest vorstellbar wäre, daß es auf ein Kommando für eine DDoS Attacke gewartet hat. Könnte eine Erklärung sein.
MfG
moin moin
hab eben mal ein wenig gegoogelt. dabei bin ich auf folgendes gestoßen => http://groups.google.de/groups?q=traceroute-nanog+6.0&hl=de&lr=&ie=UTF-8&selm=as86l1%242d1a%241%40FreeBSD.csie.NCTU.edu.tw&rnum=3
ich hab mir das noch nicht so genau angesehen, das dauert bei meinem englisch immer etwas länger :)
Gruß HL
Ja das ist es.
Ist in Bug Traq drin und auch auf der Securityfocus Page zu bekommen:
http://online.securityfocus.com/archive/1/301650/2002-12-01/2002-12-07/2
Da steht aber "local root hole" deswegen denke ich das der Angreifer einen Prozess exploitet hat der als User lief und sich mit Hilfe des traceroute Exploits root Rechte holen wollte.
mfg
cane
EDIT
Ich hatte warscheinlich Recht!
Carl Livitt selber sagt:
Of course, if an attacker could control the server that traceroute uses to
lookup DNS admin contact names, then it would be possible to exploit this
flaw remotely. However, the default server used by traceroute is 'localhost'
which makes this almost impossible to exploit in any other way except locally
on an unpatched system.
Obwohl ich in Bug Traq und SecurityFocus gesucht hab fand ich nichts dergleichen.
Aber dankeschön genau das scheint es zu sein :D
abend :)
ich hab mir mal die setup.txt etwas naeher angeschaut:
1. http://www.google.de/search?q=%22+shkit-v4-internal+release+2002%22&ie=ISO-8859-1&hl=de&meta=
seh an, ein hit.
2. http://beatbox.suidzer0.org/files.php?currentgrp=32
vergleichen wir mal die erste zeile der setup.txt mit der liste von beatbox.suidzero.org ... -> "shv4.tar.gz - shkit-v4-internal release 2002, a SSHD backdoor". die datei enthält auch die von dir geschriebenen files.
wie es aussieht hast du dir ein allerwelts scriptkiddie gefangen :D
wobei ich immer noch nicht ganz gerafft habe, wie er nun ins system reingekommen ist.
um die ssh backdoor zu installieren, muss er ja erstmal ins system gelangen, oder?.
die schwachstelle in Traceroute-nanog kann anscheinend auch nur ein lokaler angreifer ausnutzen => http://cert.uni-stuttgart.de/archive/win-sec-ssc/2002/11/msg00033.html
Gruß HL
Wenn er dafür nur eine User-Shell braucht: Wie viele User sind auf dem System eingerichtet und haben ein einfach zu erratenes Passwort?
Gruss, Andy
Naja, reingekommen ist er wohl durch einen der laufenden Daemons (wuerde mal spontan auf Apache tippen, wegen des Eigentuemers der Dateien in /tmp), hat versucht mit dem Exploit root zu erlangen, was nicht geklappt hat, also noch'n Versuch, und noch einer (darum "ee" dreimal in der Prozessliste), und dann hat er wohl entnervt aufgegeben, oder Mami hat ihn zum Essen gerufen.. ;)
Und weil er kein root hatte, konnte er auch das Rootkit mangels Schreibrechten nicht installieren.
@geronet: schade, wegen des Betreffs hatte ich schon geglaubt, dass sich ein Script Kiddie hierher verirrt hat, wollte mir schon ne richtig schoene Antwort ausdenken ;)
Gruss, cytrox
@cytrox
wenn ich mein geld als detektiv verdienen müßte, würde ich wohl verhungern :D. klingt einleuchtend mit dem apachen.
Gruß HL
meine kanidaten waeren:
1) telnet
2) sshd
3) vielleicht .. hm... das rpc dingens?
Achso, das klingt logisch. Jetzt steht nur noch die Frage offen, welche Lücke er am Apachen ausgenutzt hat. War der Indianer schon lange nicht mehr auf dem neusten Stand? Oder hat es irgendwelche Scripts, die eine entsprechende Angriffmöglichkeit bieten?
Gruss, Andy
Original geschrieben von AirWulf
meine kanidaten waeren:
1) telnet
2) sshd
3) vielleicht .. hm... das rpc dingens?
Von was redest du? Von Telnet steht oben nichts. Und der RPC-Portmapper wurde auch nie erwähnt.
Gruss, Andy
airwulf kann nicht lesen. sorry.
moin
@geronet
Den logdateien kann man eh nichtmehr vertrauen, auffällige Spuren sind keine drin.
so wie es aussieht, ist es dem angreifer ja nicht gelungen root-rechte zu erlangen. somit dürfte es ihm ja auch nicht möglich gewesen sein, die log's zu manipulieren.
vielleicht kannst du ja nochmal einen blick in die log's werfen, auch in die vom apachen.
was mich auch nochmal interessieren würde => gab es auf dem angegriffenen system überhaupt das programm traceroute-nanog ?
Gruß HL
Moment mal, ganz langsam...
Also auf jeden Fall war meine Firewall mit iptables dicht, die hatte nur die wirklich benötigten Dienste durchgelassen. Telnet und rpc -> keine Chance.
Es muss eigentlich der apache gewesen da die Dateieigentümer vom apachen stammen.
Lustigerweise war aber "RootLogin" auf yes beim sshd und der hatte ein "leichtes" Passwort.
Apache Version 1.3.14 ist das, nähreres kann ich jetzt nicht sagen da die Maschine woanders steht ;)
>gab es auf dem angegriffenen system überhaupt das programm traceroute-nanog
wie meinst du das?
Er hat dieses Programm nur in "ee" umbenannt..
hi
auf jedenfall ein interessantes thema. :) ich hab eben nochmal gegoogelt, da bei bin ich auf folgenden exploid für den apachen 1.3.14 gestoßen => http://packetstormsecurity.nl/0209-exploits/apache-linux.txt
If successfully it will spawn a shell on port 30464 and then connect to it.
* Then use another exploit to get r00t
*
* btw,/tmp/.bugtraq.c is blackhole.c,rename /tmp/.bugtraq.c and
* for this to work,and dont forget to set it on port 30464
kommt natürlich auf deine firewall-regeln an. aber möglich ist es wohl, das er auf diesem wege ins system gekommen ist. zumal er mit diesem exploid keine root-rechte erlangen konnte und deshalb wohl noch das traceroute exploid versucht hat.
hast du schonmal mit last nachgesehen, ob du was verdächtiges findest?
wie meinst du das? Er hat dieses Programm nur in "ee" umbenannt..
meiner meinung nach ist diese "ee", was den buffer overflow in traceroute-nanog auslöst und wodurch der angreifer dann root-rechte erlangt. wenn traceroute-nanog aber gar nicht auf dem system installiert war, kann er damit auch nichts anfangen.
Gruß HL
In "last" hab ich als erstes nachgeschaut.
Ich schau nächstes mal nach.. aber ich bin mir sicher dass bei dem Port nichts hereingekommen sein kann.
Sucht euch doch einen aus: http://www.apacheweek.com/features/security-13
:D
@Jinto
doch so viele :D
@geronet
naja du kennst ja deine firewall-regeln am besten und wenn von innen nicht alles erlaubt ist, fällt dieser exploid wohl aus.
Gruß HL
Wieso von "innen"?
Es gibt kein "innen", der Server war kein Router, hatte nur eine Netzwerkkarte mit öffentlicher IP und FORWARD war gesperrt.
Edit: Das Programm traceroute-nanog ist nicht auffindbar.
hm, ist traceroute-nanog nicht ein traceroute replacement?
(http://cert.uni-stuttgart.de/archive/bugtraq/2002/12/msg00016.html)
Wenn ich das richtig las (in deinem ee Auszug), heisst das Programm unter SuSE nur traceroute und nicht traceroute-nanog. Du musst also dir die Version von traceroute anschauen.
Hier nochmals die Bestätigung: http://www.suse.de/de/security/2002_043_traceroute_nanog_nkitb.html
Ok, ja, traceroute selber ist natürlich installiert.
Trotzdem hat er es warscheinlich nicht geschafft root zu werden da die ee Prozesse noch liefen.
Leider kann der normale User ja seine .bash-history Datei löschen, sonst wüssten wir sofort was er genau gemacht hat.
Jetzt werden erstmal die Logdateien gecheckt ob da was auffällt.. muss es wohl auch.
Grüsse, Stefan
gerade daruaf hin, dass er root war, weil die Prozesse noch liefen ?
Er konnte nur nicht die "Daemon" Prozesse killen.
1. -d um sich mit traceroute zu verbinden
2. -e um ein root-Shell zu bekommen
Ich wuerde mir mal die cgi-Scripte naeher anschauen, wenn welche da sind.
Ich musste erst gestern ein User aussperren, der mit einem Script WebServerLoecher gesucht hat.
Bestimmt uber 100 Eintraege in der error.log pro Minute.
T;o)Mes
Ja sonst hätte er doch sofort das rootkit in /tmp/ installiert.. oder nich.
Hab mir das Ding erst jetzt mal richtig angesehen :rolleyes:
Er/sie/es bekommt ja dadurch keine root-Shell( Mein Fehler, man bekommt ja nur eine User-Shell durch diese *prog*), man kann nur Code einschleusen. Allerdings wiess ich jetzt nicht, in wie weit dieses *ee* was in dem Stack macht.
Wahrscheinlich wurde er/sie/es gestoert. Aber drei Prozesse sind vielleicht nicht wenig. ;)
T;o)Mes
Läuft da eigentlich noch ein sshd, der V1 erlaubt?
...Ich glaub schon...
weiss ich aber nicht sicher.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.