In den letzten Tagen häufen sich die Meldungen über kompromittierte Server, welche mit einem sshd rootkit infiziert sind. Bis heute ist nicht klar wie genau das rootkit überhaupt auf den Server kommt. Da gehen die Vermutungen von CPanel und Plesk, über exim oder ssh direkt bis hin zu race conditions im Kernel. Es ist also alles andere als klar!
Es wird auch die Möglichkeit von verseuchten Admin-PCs angeschaut. Wenn dem so wäre, dann hätten wir als Angriffsvektoren noch die üblichen Verdächtigen: Flash, Java, PDF und natürlich die Browser an sich. Zur Zeit werden verseuchte Admin-PC als ziemlich plausibel angeschaut. Das hätte immerhin den «Vorteil», dass man die Server nicht frontal angreifen könnte. Aber mit dem gewaltigen Nachteil, dass damit auch ssh-keys der Admins geklaut werden könnten, was vom Server aus nicht möglich wäre.
Ziemlich klar ist jedoch die «Aufgabe» des rootkits: Passworte von ssh Logins stehlen und via TCP Port 53 an Steuerserver schicken. Zudem kann das rootkit scheinbar remote Kommandos entgegennehmen.
Der Hersteller von CPanel hat alle seine User, die in den letzten 6 Monaten ein Ticket eröffnet haben, informiert und aufgefordert sofort alle Passworte und Schlüssel zu wechseln. Scheinbar war einer der Server welche vom CPanel-Support verwendet wurden, kompromittiert worden.
Anfangs war nur von RedHat basierten Systemen die Rede, heute ist aber klar, dass auch andere z.B. auch Debian betroffen zu sein scheint. Jeder Admin eines RedHat oder Debian Systems resp jedes System welches mit CPanel läuft sollte unbedingt die Server Libraries prüfen. Scheinbar wird bis jetzt die libkeyutils missbraucht. Ganz verdächtig wären /lib64/libkeyutils.so.1.9 oder /lib/libkeyutils.so.1.9 (64bit-32bit)
Man kann diese Libs mittels den Paketverwaltungen und Hashes verifizieren, NUR wenn das System bereits das rootkit drauf hat wäre es möglich dass dieses den Hash on-the-fly verändern könnte.
Weitere Anzeichen für eine Infektion:
Ersteres und letzeres kann man mit tcpdump auf dem Gateway prüfen, das zweite leider nur direkt auf dem Server mittels ipcs -mp (da wäre aber wieder das Problem, dass ein bereits infiziertes System diesen Systemaufruf manipulieren könnte).
Ich empfehle wirklich jedem Admin eines Servers sich zum Thema schlau zu machen und auch auf dem Laufenden zu bleiben bezüglich neuer Erkenntnisse (v.a. bezüglich des ersten Angriffs). Infos kann man z.B. hier (http://www.webhostingtalk.com/showthread.php?t=1235797) finden oder auch hier http://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229
Hier noch das Trace Script. Besteht aus zwei Files. Als Grundlage habe ich diesen Thread im CPanel Forum genommen: https://forums.cpanel.net/f185/sshd-rootkit-323962.html#post1324162
strace-process
1 2 3 4 5 6 7 8 9 10 11 12 | #!/bin/bash STRACE='' if [[ "x$*" != 'x' ]] then STRACE=`ps aux | grep "$*" | grep -v grep | grep -v $$ | grep -v strace | awk '{print "-p " $2}'` [ "x$STRACE" = 'x' ] && echo "Error" && exit 1 strace -o out -f -s 5000 $STRACE else echo "Error" exit 1 fi |
und syscallparse
1 2 3 4 5 6 7 8 | #!/bin/bash cd /root/trace DATE=$(date +'%d.%m.%y-%H:%M:%S') mkdir ./syscalls/$DATE >/dev/null 2>&1 for x in `awk '{print $2}' ./out | grep [a-z] | sed s/\(.*//g | sort | uniq` ; do grep -n "^[[:digit:]]\+[[:space:]]\+$x(" ./out >> ./syscalls/$DATE/$x done |
die Scripte erwarten ein Unterverzeichnis im aktuellen Arbeitsverzeichnis Namens syscalls. Bei ersten Script gibt man als Parameter den Prozess an den man tracen will. Das erstellt im aktuellen Verzeichnis ein File out welches dann vom zweiten Script abgearbeitet wird. Nachdem das zweite Script fertig ist hat man in syscalls/DATUM-UHRZEIT die verschiedenen Syscalls als Files z.B.
1 2 3 | ./strace-process ssh[d] CTRL+c ./syscallparse |
danach
1 2 3 4 5 6 7 8 9 | ls -al syscalls/27.02.13-11\:47\:40/ total 28 drwxr-xr-x 2 root root 4096 Feb 27 11:47 . drwx------ 10 root root 4096 Feb 27 11:47 .. -rw-r--r-- 1 root root 90 Feb 27 11:47 ioctl -rw-r--r-- 1 root root 303 Feb 27 11:47 read -rw-r--r-- 1 root root 428 Feb 27 11:47 rt_sigprocmask -rw-r--r-- 1 root root 299 Feb 27 11:47 select -rw-r--r-- 1 root root 421 Feb 27 11:47 write |
die einzelnen Syscall-Files kann man sich dann angucken und schauen was bei dem entsprechenden Call abgegangen ist.
Scheinbar tauchen mittlerweile die ersten Versionen mit anderen Filenamen auf. So z.B. libkeyutils-1.2.so.2 bei CentOS 5
Der Hersteller von CPanel hat auf seiner Webseite eine sehr ausführliche Beschreibung des aktuellen Stands. http://docs.cpanel.net/twiki/bin/view/AllDocumentation/CompSystem
Scheinbar ist bei CPanel neben dem libkeyutils auch der komplette ssh betroffen. Da dies scheinbar via manipulierte RPM Pakete geschehen ist muss man bei allen RedHat basierten Systeme auch SSH prüfen.
Hier noch das Statement von CPanel
Was Diskstation User machen können/sollten:
Unter der Voraussetzung, dass man dem Firmware Image trauen kann sollten Diskstation User mindestens das libkeyutils1.so File prüfen und einen Hash mit dem Original von Synology vergleichen.
Prüfen sollte man folgendes: es darf nicht sein, dass dieses File die folgenden Strings beinhaltet d.h. folgendes Kommando darf nichts zurückgeben
Allerings ist es fraglich ob dies nicht manipuliert werden könnte, wenn das System bereits kompromittiert worden ist. Wer ganz sicher sein will baut die Platte(n) aus und in einen PC ein. Dann mittels einer Linux LiveCD/DVD das obige Kommando auf das File der Firmware loslassen. Ein allfälliges root-Kit wäre hier nicht aktiv und hätte daher bei einem Live System wenig Chancen die Rückgabe von strings zu manipulieren.
Für den Hash gibt es leider ein weiteres Problem bei der Diskstation. Per default ist kein md5sum installiert. Das müsste man erst via ipkg installieren. Bei einem verseuchten System hätte man aber wieder dasselbe grundsätzliche Problem wie beim strings direkt auf der DS. Auch hier wäre es besser das mit einem Live System zu machen. Allerdings muss man dazu auch das passende Firmware Image von Synology haben. Dort müsste man das libkeysutils File erst extrahieren und dann auf dem LiveSystem gegen den md5 des Files auf der DS prüfen
Wie es scheint könnte das damals noch unbekannte Rootkit Ebury Rootkit der Grund für die Infektionen bei CPanel gewesen sein.
Zur Feststellung einer Infektion empfiehlt Eset