Botnet

Botnet

Diesen Beitrag schrieb ich 12 Jahre und 4 Wochen zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.

Geschätzte Lesezeit: 3 Minuten

Mich traf fast der Schlag, als ich von meinem Provider eine E-Mail erhielt: ich solle Stellung nehmen zu dem Angriff, der von meinem Server aus am Vortag erfolgte.

Direction OUT
Internal a.b.c.d
Threshold PacketsDiff 10.000 packets/s, Diff: 106.526 packets/s
Sum 31.958.000 packets/300s (106.526 packets/s), 5 flows/300s (0 flows/s),
2,322 GByte/300s (63 MBit/s)
External z.y.x.w, 31.958.000 packets/300s (106.526 packets/s), 5 flows/300s (0 flows/s),
2,322 GByte/300s (63 MBit/s)

Uff! Und mein munin-Graph bestätigte es – eine halbe Stunde lang hatte die Maschine mit voller Bandbreite ihr Ziel angegriffen. Doch wie? Wie konnte das sein? Ich begann die Maschine zu durchforsten… Als erstes überprüfte ich – Ehrensache – die eingeloggten User. Doch außer mir ist niemand in Sicht. Dann prüfe ich mit lastlog, wer sich überhaupt so auf dem System rumtummelt, das erzeugt eine Ausgabe wie diese hier:

...
ftp                                        **Never logged in**
ntpd                                       **Never logged in**
localwurst      pts/0    p4fc33251.dip.t- Fri Mar  1 11:32:58 +0100 2012
...

So erhielt ich die Bestätigung dafür, dass sich außer den erlaubten Usern nie jemand auf dem System eingeloggt hatte, und auch last bestätigte mir das. Ich durchforstete die Logfiles, konnte jedoch nichts Auffälliges feststellen. Ich überlegte, was sich geändert haben könnte, doch mir fiel nichts ein. Ich suchte nach Auffälligkeiten, doch ich fand nichts, und fast hätte ich – unter anderem aufgrund der fortgeschrittenen Uhrzeit und nöligem Rumpelstilzchen – aufgegeben. Doch nachdem ich das Rumpelstilzchen erfolgreich ins Bett verfrachtet hatte, kam mir die Idee. So schaute ich mir genauer an, was sich so an ssh-Prozessen auf dem Sytsem befand (der Übersichtlichkeit halber hab ich mal die unnötigen Angaben entfernt):

root@ux:/root# ps auxf|grep ssh
root      2267    Mar01   0:00 /usr/sbin/sshd -D
root     24294    11:32   0:00  \_ sshd: spiller [priv]
spiller  24320    11:32   0:00      \_ sshd: spiller@pts/0
root     29753    12:15   0:00                      \_ grep ssh
www-data 24156    Feb19   0:00 sshd:

Ein ssh-Prozess, von User www-data initiiert? Das kam mir nun doch verdächtig vor. Also schaute ich mir den mit lsof (list open files und dann ein grep auf die Prozess-ID dieses sshd:-Prozesses) genauer an (auch hier entferne ich mal die an dieser Stelle nicht so relevanten Angaben wie TYPE und DEVICE):

root@ux:/var/log# lsof | grep 24156
24156 ?        00:00:00 sshd:
sshd:     24156   www-data  cwd      /var/www/EinOrdner/.m
sshd:     24156   www-data  rtd      /
sshd:     24156   www-data  txt      /var/www/EinOrdner/.m/sshd:
sshd:     24156   www-data  mem      /lib32/libresolv-2.13.so
sshd:     24156   www-data  mem      /lib32/libnss_dns-2.13.so
sshd:     24156   www-data  mem      /lib32/libc-2.13.so
sshd:     24156   www-data  mem      /lib32/libnss_files-2.13.so
sshd:     24156   www-data  mem      /lib/i386-linux-gnu/ld-2.13.so
sshd:     24156   www-data    0u     TCP ux:36458->quakenet.xs4all.nl:ircd (ESTABLISHED)
sshd:     24156   www-data    3u     UDP *:34001

Es war also in /var/www/EinOrdner ein Unterordner namens .m angelegt worden – und in diesem steckte der Scheiß! Der sshd:-Prozess war in Wirklichkeit ein Stück IRC, das sich mit dem Quakenet verbunden hatte und auf Kommandos wartete. Verdammt! In dem Ordner fand sich unter anderem auch eine Datei namens cron.d, und die machte genau das, was man von ihr erwartete:

* * * * * /var/www/EinOrdner/.m/update >/dev/null 2>&1

Es wurde also ständig überprüft, ob der Prozess noch lief und, wenn nicht, wurde er klammheimlich neu gestartet. Einmal erkannt war es natürlich nicht so schwer, die Daten aus dem System zu werfen, den Cron-Job zu löschen – doch die bange Frage blieb doch: wie war der Dreck aufs System gelangt? Und auch das klärte sich mit Sichtung der diversen Logfiles:

PHP Warning: Unterminated comment starting line 3 in
/var/www/phpldapadmin-1.2.0.5/lib/functions.php(1060) : runtime-created
function on line 3

Ein zu alter PHPLdapAdmin diente als Einfallstor – zu bemerken ist, dass der User www-data am System herumfummelte, doch als Nerver logged in. geführt wurde. Er versuchte auch, sich zu root zu machen, was jedoch nicht gelang:

pam_unix(su:auth): authentication failure; logname= uid=33
euid=0 tty=/dev/pts/0 ruser=www-data rhost=  user=root
FAILED su for root by www-data
- /dev/pts/0 www-data:root

Doch in anderen Fällen gelingt auch das – und dann werden ganz dreist neue Systemuser mit eigenen Homes angelegt, und aus diesen Homes heraus die Clients gestartet! Vorsicht ist also geboten bei Prozessen, die hohe Ports belegen – wenn man nicht weiß, worum es sich dabei handelt, sollte man es eingehend überprüfen. Interessant ist in diesem Zusammenhang übrigens noch, dass weder chkrootkit noch rkhunter angeschlagen haben – was sie meines Erachtens zumindest im Sinne von suspicious files ruhig hätten tun können ;-) Aber nunja. Wieder was dazugelernt.

Was also kann man tun? Ich für meinen Teil habe damit begonnen, die Möglichkeiten von fail2ban besser auszuschöpfen. Mit cron.allow bzw. cron.deny kann man verhindern, dass obskure User Cronjobs aufsetzen. Natürlich sollte jegliche Software auf dem neuesten Stand sein – WordPress, Webmailer… und natürlich jegliche Art von PHP-Admin-Panels. Und, so das Rumpelstilzchen mir Zeit dazu lässt, wieder öfter mal Logfiles lesen, einfach nur so – dabei entdecke ich immer wieder was Interessantes.

Update: wie ich inzwischen gelesen habe, können auch korrupte Wordpress-Plugins diese Dinge heraufbeschwören; neben regelmäßigem Update des WordPress-Kerns sollte man sich also gut überlegen, welche Plugins wirklich benötigt sind – ich hab jetzt erstmal eine ganze Reihe rausgeschmissen. Der Inhalt des .m-Ordners gestaltet sich übrigens wie folgt:

-rwx--x--x  1 user  group     174 Feb 27 02:00 1
-rwxr-xr-x  1 user  group     323 Jan 13  2011 autorun
-rw-r--r--  1 user  group    1198 Feb 27 02:50 cat.seen
-rw-r--r--  1 user  group     137 Feb 26 18:17 cron.d
-rw-r--r--  1 user  group     104 Feb 26 18:17 mech.dir
-rw-r--r--  1 user  group    1064 Feb 27 02:00 mech.levels
-rw-------  1 user  group       6 Feb 26 18:17 mech.pid
-rw-r--r--  1 user  group     320 Feb 27 02:00 mech.session
-rwx--x--x  1 user  group     531 Jan 12  2011 mech.set
-rwxr-xr-x  1 user  group      27 Jan 12  2011 run
-rwx--x--x  1 user  group  152108 Jan 12  2011 sshd:
-rwxr-xr-x  1 user  group      17 Nov  5  2008 start
-rwx--x--x  1 user  group   15195 Sep  2  2004 std
-rwxr--r--  1 user  group     445 Feb 26 18:17 update
Alle Bilder dieser Seite: © Marianne Spiller – Alle Rechte vorbehalten
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten

Eure Gedanken zu „Botnet“

Ich freue mich über jeden Kommentar, es sei denn, er ist blöd. Deshalb behalte ich mir auch vor, die richtig blöden kurzerhand wieder zu löschen. Die Kommentarfunktion ist über GitHub realisiert, weshalb ihr euch zunächst dort einloggen und „utterances“ bestätigen müsst. Die Kommentare selbst werden im Issue-Tracker und mit dem Label „✨💬✨ comment“ erfasst – jeder Blogartikel ist ein eigenes Issue. Über GitHub könnt ihr eure Kommentare somit jederzeit bearbeiten oder löschen.