[HaBo]

Gulliver

Anzeige

Heute hab ich einen root Server in die finger bekommen mitglied von boesen buben (geworden ist :) )

Der root server steht bei hetzner:

$uname -pas
Linux suse***lamp 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux

Das System ist ueber YAST patchmaeszig auf dem neuesten Stand. Zumindest was die patches von SuSE angeht, so sagte man mir :)

Aktiv lief da nur ein sshd und apache:
OpenSSH_4.1p1, OpenSSL 0.9.7g 11 Apr 2005

Server version: Apache/2.0.54
Server built: Feb 1 2006 18:08:48


Dort lief in nem cronjob ein testsummencheck den die einfach auskommentiert hatten :)
Lokal lief auch noch regelmaessig rkhunter. Auch dort haben die einfach ein paar sektionen geaendert sodass die tests immer OK waren, scherzkekse.

rkhunter -c --createlogfile
...
Rootkit 'Suckit Rootkit'... [ OK ]
Rootkit 'Fuck`it Rootkit'... [ OK ]
...
weiter unten jedoch:
...
* Suspicious files and malware
Scanning for known rootkit strings [ BAD ]
..
komischerweise im Log:
...
[16:55:03] [Start string tests]
[16:55:03] /sbin/init clean (string: /dev/proc/fuckit)
[16:55:03] Warning: /sbin/init NOT clean (string: FUCK)
...

Wenns FuckIt ist, sollte es auch /dev/proc/fuckit geben.
SuckIt in seiner eigentlichen Form (code und doku in phack #59 artikel 07)
ists nicht.

sbin/init hatte tatsaechlich ne menge "FUCK" strings..
zb:

@^@FUCK: Failed to hide pid %d (%d)

@/dev/kmem^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@FUCK: Can't open %s for read/write (%d)

@Can't fork subshell, there is no way...
@/usr/lib/mem@/bin/sh@alias@Can't execve shell!
@@@@@@@@FUCK: Can't allocate raw socket (%d)
@FUCK: Can't fork child (%d)

Naja soweit ist die Sache klar.

Im /root dir lagen dann folgende Dateien: (die haben sich keine Muehe gemacht das zu vertsecken)

-rwxr-xr-x 1 root root 252661 Oct 26 2006 httpd
-rw-r--r-- 1 root root 594 Oct 29 2006 ebay.php
-rw-r--r-- 1 507 507 725 Jan 4 2006 ini.inc
-rw-r--r-- 1 507 507 44 Oct 23 2006 list.txt
-rw-r--r-- 1 root root 3847 May 29 12:27 mail.txt~
-rw-r--r-- 1 root root 2484 Nov 8 2006 text.txt

Keine Ahung wie der auf uid 507 kommt, die gibts nicht.

Die Dateien bestehen aus mass mailern und Listen fuer email adressen.
Da es nur 2 email adressen gab war der typ wohl noch nicht fertig bzw. noch am testen.

Der system MTA ist nen postfix. Und im /tmp lagen ueber 30000 nicht versandte Emails...also hat er wohl schon vorher mal ne welle losgetreten.
(ihr kennt die sicherlich, die kommen alle von ebay und bitten darum Userdaten zu verifizieren ;)

Bei befehlen wie netstat/lsof stuertzt die Maschine leider ab.


Ich dann bei Hetzner angerufen und mal nachgefragt:
"jaja, das kommt oefter mal vor.."

Bei einem offensichtlichen Spammer dachte ich da muss doch mal jmd ne abuse mail geschrieben haben- auch nix.

Ich weiss nicht so genau wie die jungs reingekommen sind. Passwort bruteforce ist zumindest ausgeschlossen. Also apache, ssh oder zb webmin (was da ja auch laeuft)..vielleicht hat ja jemand nen Tip.

Alles nur mal so..weils spass macht...jetzt muss ich nochmal die anderen programme zum laufen kriegen dann will ich nochmal sehen wo die kiste noch so dranhaengt.

(der hetzner hausmeister duerfte sich schon wundern warum er jede stunde nen reset bei der kiste machen soll :) )

SUID:root

Ist ja schon fast Futter für die Fun-Section.
Netter Report :-)

bitmuncher

Für den Admin, der sowas wieder gerade biegen muß, ist das alles andere als lustig. Möglicher Angriffspunkt könnte der Apache gewesen sein. Im mod_rewrite besteht in Verbindung mit einigen Rewrite-Regeln die Möglichkeit beliebigen Code auszuführen und so an eine Shell zu kommen. Bis zum root-Zugriff ist es ja dann bekanntermaßen nicht mehr weit, wenn lokale SUID-Programme existieren, die eine Lücke haben. Eine andere Möglichkeit zum Angriff besteht, wenn der Apache mit "SSLVerifyClient optional" und zusätzlich "SSLVerifyClient required" konfiguriert war. In diesem Fall kann man an sonst geschützte Ressourcen kommen indem man kein Client-Zertifikat überträgt. Mit etwas Knowhow könnte auch eine Lücke im MPM-Worker genutzt worden sein, allerdings wurde diese Lücke als schwer ausnutzbar berichtet und jemand müßte die Fähigkeit gehabt haben die dort bestehende Race-Condition auszunutzen. Und dann gibt es in dieser Version noch eine Overflow-Lücke in der im httpd enthaltenen PCRE.

__________________

Gulliver

@bitmuncher

mod_rewrite - keine Regeln definiert bzw. nicht genutzt
SSL - nicht genutzt
PCRE - imho nur local auszunutzen

Thx fuer die hints