Wir haben uns aus aktuellem Anlass dem Ebury Rootkit etwas ausführlicher gewidmet und eine kleine Anleitung für Sie geschrieben mit Hilfe welcher Sie eine Komprimierung mit dem
Ebury Rootkit feststellen und weitestgehend beheben können.

Was infiziert das Ebury Rootkit bei Linux Serversystemen

Grundsätzlich infiziert das Rootkit in fast allen Fällen die libkeyutils und sendet bei jedem Login die aktuellen Zugangsdaten zu einem entfernten Server. Diese Logindaten werden dann von Hackern abgerufen um schadhafte Software auf dem Server zu platzieren.

 

 

Feststellen, ob mein Server infiziert ist und dagegen vorgehen

 

 

Die Infizierung können Sie auf mehreren Wegen feststellen.

 

 

1. Weg

 

Stellen Sie fest welche libkeyutils aktuell geladen ist, wie groß diese ist und ob es mehrere Versionen dieser gibt.
Unser Beispiel bezieht sich hierbei auf einen Debian 6.0 Squeeze Server

 

ls -l /lib/libkey*
lrwxrwxrwx 1 root root 20 3. Apr 2010 libkeyutils.so.1 -> libkeyutils.so.1.3.0
-rw-r--r-- 1 root root 32760 3. Apr 2010 libkeyutils.so.1.3.0
-rw-r--r-- 1 root root 8528 3. Apr 2010 libkeyutils.so.1.3

 

Diese Ausgabe ist wie folgt zu werten:
– es gibt mehrere Versionen der .so Lib, mit verschiedenen Namen – es sollte nur eine geben
– das geladene Binary (libkeyutils.so.1.3.0) ist größer als 10000Bytes
– das System ist wahrscheinlich komprimiert

 

Auf einem nicht komprimiertem System sollte die Ausgabe ungefähr wie folgt aussehen:

 

ls -l /lib/libkey*
lrwxrwxrwx 1 root root 20 3. Apr 2010 libkeyutils.so.1 -> libkeyutils.so.1.3
-rw-r--r-- 1 root root 8528 3. Apr 2010 libkeyutils.so.1.3

Zur Entfernung des Rootkits ändern Sie zunächst den Symlink auf die Original libkeyutils.so.x.x aus dem Paket Ihrer Distribution und rebooten dann den Server.

 

In unserem Beispiel wäre es:

rm /lib/libkeyutils.so.1
ln -s /lib/libkeyutils.so.1.3 /lib/libkeyutils.so.1
reboot

 

 

 

2. Weg

 

Das Rootkit funkt natürlich auch nach Hause um die Zugangsdaten bei dem Angreifer abzuliefern. Die Pakete werden über Port 53 gesendet sodass wir die Pakete mitlesen können.
Über Port 53 werden normalerweise DNS Server Anfragen gestellt, somit werden Sie auch valide Pakete Ihrer eingestellten Resolver sehen.

 

– Installieren Sie tcpdump auf Ihrem Server, bei Debian:

 

apt-get install tcpdump

 

– starten Sie das Mitschneiden der Pakete mit:

 

tcpdump -Annvvs 1500 -i any udp and dst port 53

 

– loggen Sie sich dann mit einer weiteren SSH-Session am Server ein während der Mitschnitt läuft. In der Ausgabe werden Sie valide DNS Server Pakete sehen. Sollte Ihr System komprimitiert sein werden zwei Pakete an einen Server gesendet der nicht einem der DNS Server aus der /etc/resolv.conf entspricht.

 

 

84.200.xx.xx.35773 > 188.138.xx.xx.53: [bad udp cksum bd56!] 4619+ A?
7741e5e70c18aea2775ab8fa6e5eb2b0.94.249.151.198. (65)
E..]).@.@...T..u..(E...5.IMg............
7741e5e70c18aea2775ab8xxxxx.94.249.xx.xx.....
09:37:36.497413 IP (tos 0x0, ttl 64, id 10656, offset 0, flags [DF], proto UDP
(17), length 105)
84.200.xx.xx.37201 > 188.138.xx.xx.53: [bad udp cksum 9ee0!] 4619+ A?
6214f8fc6a5ab0a1371c83a5211ff8e73747e1xxx.94.249.xx.xx. (77)
E..i).@.@...T..u..(E.Q.5.UMs............,6214f8fc6a5ab0a1371c83a5211ff8e73747xxxxx.94.249.xx.xx....

Wir haben die letzten 2 Blöcke der IPs und die Daten für User und Passwort mit xx verfremdet.

 

Zu sehen sind folgende IPs:

 

84.200.xx.xx -> unsere Ip des Servers
188.138.xx.xx -> IP des Angreifers, dahin werden die Zugangsdaten gesendet
94.249.xx.xx -> IP dessen der sich probiert hat einzuloggen um den Log zu erstellen

 

Bereinigen Sie Ihr System wie im  Weg 1 beschrieben und prüfen Sie erneut per tcpdump ob noch etwas an den zuvor gelisteten Server des Angreifers gesendet wird.

 

 

Neben diesen beiden Wegen gibt es noch eine Reihe weiterer Möglichkeiten auf welche wir allerdings hier nicht eingehen werden, weil diese nicht zu einer Lösung in allen uns vorliegenden Fällen behilflich waren.

 

 

 

Arbeiten nach der Bereinigung

 

Wichtig ist es nach abschließender Entfernung des Rootkits, dass alle Kennwörter des Servers geändert werden, da nicht ausgeschlossen werden kann, dass der Hacker nicht erneut auf das System versucht zuzugreifen. Auch sollte geprüft werden, ob bereits durch den Hacker Prozesse auf dem Server gestartet wurden, die möglicherweise SPAM E-Mails oder andere schädliche Software versenden.

 

Sollte es sich bei dem Server nicht um ein hoch produktives System handeln, sollte man trotz Bereinigung eine Neuinstallation in Betracht ziehen um 100 % ausschließen zu können, dass weiterhin schadhafte Software auf dem Server gestartet ist.

 

Gerne stehen wir unseren Kunden hier mit Rat und Tat zur Seite.