Feb 27, 2014, updated at 23:38:24 (UTC)

7223

BSI-Warnung: Zahlreiche deutsche Server mit Ebury-Rootkit infiziert

Alle Linux/Unix Admins sollten jetzt ihre Server auf das Ebury-Rootkit testen. Das BSI hat eine entsprechende Warnung herausgegeben. Die Meldung ist zwar schon über eine Woche alt, aber auch ich kam leider jetzt erst dazu die Server zu testen.

Hier die Schnellanleitung für den Test. Eine genaue Anleitung, um den Rootkit zu erkennen findet ihr auf dieser BSI Seite.

1) Als Root folgenden Befehl in der Shell ausführen:

ipcs -m

2) Ausgabe prüfen:

Erscheint folgende Ausgabe (oder ähnlich):

------ Shared Memory Segments --------
Schlüssel       shmid       Besitzer   Rechte     Bytes      nattch Status
0x000006e0      65538       root        666       3283128    0

Dann sieht es nicht gut aus und ihr seid wahrscheinlich infiziert. Ebury legt ein paar Segmente mit mindestens 3 MByte mit vollen Rechten (666) an.

Erscheint diese Ausgabe:

------ Gemeinsamer Speicher: Segmente --------
Schlüssel shmid      Besitzer   Rechte     Bytes      nattch     Status

seit ihr höchstwahrscheinlich nicht betroffen.

Hier die Ebury FAQ Seite vom BSI:
https://www.cert-bund.de/ebury-faq

Viel Glück.

Please also mark the comments that contributed to the solution of the article

Content-Key: 231245

Url: https://administrator.de/contentid/231245

Printed on: April 23, 2024 at 20:04 o'clock

16 Comments

Latest comment

Hallo Frank,

Danke für die Glückwünsche. Mir ist erstmal das Herz in die.. gerutscht, als es positiv ausfiel. Der zweite Blick hat das allerdings etwas relativiert. Bräuchte dazu aber unabhängiges Feedback/Zweitmeinungen.

Der "infizierte" Server ist Web und u.a auch OTRS Server, ausgabe war positiv. OTRS User, nachdem ich das OTRS Verzeichnis umbenannt habe -> wie "clean".

Zweitmeinung: Ist jeder OTRS "infiziert" oder nutzt OTRS nur "legitim" die Shared Memory Funktion, auf die hier getestet wird?

Werde nebenbei auch mal einen zweiten OTRS testweise aufsetzen und schauen, was sich da tut.

Schöne Grüße und danke für kurzes Feedback.

Chri.s

Hi Chris,

schau mal unter der FAQ der BSI Seite: How can I verify my system is infected with Ebury? Da ist es noch detaillierter beschrieben. Schau Dir die Rechte im Shared Memory genau an: 666 sollte da in der Regeln nicht stehen.

Eine weitere Möglichkeit, wie man Ebury erkennen kann (als Verifikation) findest du unter dem Punkt I have a lot of additional machines on my Network. Is there a way to identify systems infected with Ebury by inspecting the network traffic? auf der BSI Seite.

Beispiel:

Mit

tcpdump  -p

kannst du Ebury auch in deinem Netzwerkverkehr finden: Such mal im Datenverkehr nach angeblichen DNS-Anfragen in Form von: 5742e5e76c1ab8c01b1defa5.[IP Adresse].

Auch kannst du mit Snort ein Script starten das einen Alarm auslöst, wenn Ebury gefunden wird. Dazu must du aber erst snort installieren.

alert udp $HOME_NET any -> $EXTERNAL_NET 53 \
(msg:"Ebury SSH Rootkit data exfiltration";\ 
content:"|12 0b 01 00 00 01|"; depth:6;\ 
pcre:"/^\x12\x0b\x01\x00\x00\x01[\x00]{6}.[a-f0-9]{6,}\ 
(([\x01|\x02|\x03]\d{1,3}){4}|\x03::1)\x00\x00\x01/Bs";\ 
reference:url,https://www.cert-bund.de/ebury-faq;\
classtype:trojan-activity; sid:9000001; rev:1;)

Wie auch immer, wenn Ebury gefunden wurde, sollte man das System laut BSI komplett neu installieren.

Gruß
Frank

Das kommt mir entgegen, wollte das System sowieso mit Nginx neu aufsetzen.

Da das nun aber so ist schul ich noch meine Erkennungskenntnisse. Die Rule pack ich nur unter /etc/snort/rules/ebury.rules, und wie bekomme ich die Alerts (die Dumps und Snort sind bisher eher unauffällig).

Gruß,

Chri.s

Danke für den Tipp, hab gerade alle meine Server gecheckt (rund 200) - alle Clean.
Hab aber dennoch die Snort Rules übernommen!

lG,
Stefan

Hallo,

Auch kannst du mit Snort ein Script starten das einen Alarm auslöst,
wenn Ebury gefunden wird. Dazu must du aber erst snort installieren.

Danke dafür.

Man kann auch die SMS Servertools installieren und dann via Modem
auf sein Handy eine Alarmmeldung (SMS) von Snort erhalten.

Gruß ♪
Dobby♬

Wenn die Segmente kleiner als 3MB sind, kann man dann Entwarnung geben?
Hier ein Beispiel:

Gemeinsamer Speicher: Segmente --------
Schlüssel shmid Besitzer Rechte Bytes nattch Status
0x016ea258 9699328 root 600 1167812 12
0x796ea6cc 8519681 root 666 404 0

oder der hier:

Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x0004e7b0 0 root 666 20564 0
0x015540f3 196609 root 600 1167812 12

Muss ich mir da Sorgen machen??

VG

Hallo Nus,

ich würde es auf jeden Fall beobachten. In meinem Fall (siehe oben) konnte ich die Nutzung auf OTRS eingrenzen und eliminieren, in dem ich die Verzeichnisse verschoben habe - außerdem scheint OTRS auch "so" das Modul zu nutzen, wie das bei dir ist ist fraglich.

Um eine genaue Analyse wirst du nicht herum kommen.

Hmm, wüsste nichts von OTRS auf dem betreffenden Server...
Werde dann wohl mal weiter schauen...

Danke!

Zitat von @nussystems:

Hmm, wüsste nichts von OTRS auf dem betreffenden Server...
Werde dann wohl mal weiter schauen...

Danke!

War nur ein Beispiel. Es soll auch Programme geben, die die Funktion ordentlich nutzen.

Weiss jemand etwas von einer IP Liste, die betroffene Ausweisst? Kann man das irgendwo gegenprüfen?

Zitat von @chri.s:

> Zitat von @nussystems:
>
> Hmm, wüsste nichts von OTRS auf dem betreffenden Server...
> Werde dann wohl mal weiter schauen...
>
> Danke!

War nur ein Beispiel. Es soll auch Programme geben, die die Funktion ordentlich nutzen.

Weiss jemand etwas von einer IP Liste, die betroffene Ausweisst? Kann man das irgendwo gegenprüfen?

Update:

root@debian:/opt/otrs/bin# ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x0052e2c1 557056     postgres   600        32342016   4
0x02a622c6 589825     root       777        32768      0

Bei einer komplett neuen Installation. Entweder sind die OTRS Pakete kompromitiert, oder das war ein false positive. Hat hier jemand einen OTRS im Einsatz? Ggf. anderes System als Debian 7?

Die Ausgabe von icps -m

------ Gemeinsamer Speicher: Segmente --------
Schlüssel shmid      Besitzer   Rechte     Bytes      nattch     Status      
0x00000000 262144     alex2      600        393216     2          zerstört       
0x3c81b7f5 163841     alex2      666        4096       0                       
0x00000000 884738     alex2      600        393216     2          zerstört       
0x00000000 40009731   alex2      600        1048576    2          zerstört       
0x00000000 2326532    alex2      600        393216     2          zerstört       
0x00000000 35258373   alex2      600        8388608    2          zerstört       
0x00000000 31162374   alex2      600        527220     2          zerstört       
0x00000000 2555911    alex2      600        393216     2          zerstört       
0x00000000 18448392   alex2      600        4074680    2          zerstört       
0x00000000 2981897    alex2      600        1048576    2          zerstört       
0x00000000 16449546   alex2      600        393216     2          zerstört       
0x00000000 39682059   alex2      600        1048576    2          zerstört       
0x00000000 45088780   alex2      600        524288     2          zerstört       
0x00000000 5963789    alex2      777        1163520    2          zerstört       
0x00000000 53149710   alex2      600        524288     2          zerstört       
0x00000000 33128463   alex2      600        2097152    2          zerstört       
0x00000000 6848528    alex2      600        393216     2          zerstört       
0x00000000 45449233   alex2      600        4194304    2          zerstört       
0x00000000 42237970   alex2      777        6330240    2          zerstört       
0x00000000 6946835    alex2      600        524288     2          zerstört       
0x00000000 40206356   alex2      777        875520     2          zerstört       
0x00000000 41484309   alex2      600        393216     2          zerstört       
0x00000000 51937302   alex2      600        393216     2          zerstört       
0x00000000 50397207   alex2      600        8388608    2          zerstört       
0x00000000 50987032   alex2      600        393216     2          zerstört       
0x00000000 41680921   alex2      600        2097152    2          zerstört       
0x00000000 41713690   alex2      600        393216     2          zerstört       
0x00000000 52035611   alex2      600        524288     2          zerstört       
0x00000000 51052572   alex2      600        26576      2          zerstört       
0x00000000 23560221   alex2      600        393216     2          zerstört       
0x00000000 52068382   alex2      600        393216     2          zerstört       
0x00000000 52101151   root       600        393216     2          zerstört       
0x00000000 52363296   root       600        393216     2          zerstört       
0x00000000 52297761   root       600        2097152    2          zerstört       
0x00000000 52330530   root       600        393216     2          zerstört       
0x00000000 53215268   root       600        1048576    2          zerstört       
0x00000000 52592677   root       600        393216     2          zerstört 

Ausgabe von find /lib* -type f -name libkeyutils.so* -exec ls -la {} \;

-rw-r--r-- 1 root root 13620 Apr 28  2013 /lib/i386-linux-gnu/libkeyutils.so.1.4

Scheint OK.

Ausgabe von chkrootkit

Searching for suspicious files and dirs, it may take a while... The following suspicious files and directories were found:  
/usr/lib/jvm/.java-1.7.0-openjdk-i386.jinfo /usr/lib/pymodules/python2.7/.path

Searching for Suckit rootkit...            Warning: /sbin/init INFECTED

Suckit ist false-positive aber die python-libary gefällt mir nicht.

tcpdump -p hab ich jetzt mal nicht angehängt, sieht aber sauber aus.

Was meint ihr dazu?

Hallo Anon0815,

Was meint ihr dazu?

Auf Debian 6 bekomme ich:

 /usr/lib/pymodules/python2.6/.path

und unter Ubuntu 12.04 LTS

 /usr/lib/pymodules/python2.6/.path /usr/lib/pymodules/python2.7/.path

Bei beiden Distris gibt es keine shared memory segments.

Unter CentOS 6.5 hatte ich auch den Suckit false-positiv, habe mit rkhunter gegen geprüft und es war alles ok.
Das scheint ein bug im chkrootkit zu sein (Quelle: http://askubuntu.com/questions/25176/chkrootkit-says-sbin-init-is-infec ..)

grüße vom it-frosch

Hallo zusammen,
ich habe hierfür einen Check_MK local check gebaut:

http://pastebin.com/Nt387sZ5

Viel Spaß damit!

Beste Grüße.

Benedikt

P.S.: Es funktioniert auch standalone ;)

Hallo Benedikt,

ich habe hierfür einen Check_MK local check gebaut:

ja schade das du den Quellcode nicht hier hinzugefügt hast. Wir haben dafür extra unsere <code>Quellcode</code> Tags.

Gruß
Frank

Das lässt sich ja nachholen:

#!/bin/bash
#=======================================================================
# Filename		: check_ebury.sh
# Author		: Benedikt Frenzel
# Licence		: 
# Input values	: none
# Purpose		: This script will check if your system is may be 
# 				  infected by the ebruy rootkit for more information
#				  check: https:{{comment_single_line_double_slash:0}}
# Disclaimer	: I can and will NOT  guarantee that this script will 
#				  find the ebruy rootkit. This script will not remove 
#				  the rootkit. 
#                 The output format is check_mk local check compliante. 
#=======================================================================

# ----------------------------------------------------------------------
# Independent variables
# ----------------------------------------------------------------------

# ----------------------------------------------------------------------
# Dependent variables
# Nothing to change below this line.
# ----------------------------------------------------------------------

CHECKCOMAND="ipcs -m"  
CHECKPERMS="666"  
CHECKMEM="3283128"  

myPERMSRESULT=$(ipcs -m | grep ${CHECKPERMS} | wc -l)
if [ ${myPERMSRESULT} -gt 0 ]; then
	myMEMRESULT=$(ipcs -m | grep ${CHECKMEM} | wc -l)
	if [ ${myMEMRESULT} -gt 0 ]; then
		exitSTATUS=2
		exitSTRING="check_ebury - CRITICAL This system may be infected"  
	else
		exitSTATUS=0
		exitSTRING="check_ebury - OK This system is clean"  
	fi
else
		exitSTATUS=0
		exitSTRING="check_ebury - OK This system is clean"  
fi
echo "${exitSTATUS} ${exitSTRING}"  

EDIT: Habe die falsche Version hochgeldaden ;) Ist nun die Richtige und funktioniert.

EDIT2: Das Script befindet sich nun auch auf github

https://github.com/befrenzeNET/monitoring-scripts/tree/master/check_mk_l ...

Wichtiges Update:

Das Ebury-Rootkit ist nur ein Teil eines großen Bot-Netzwerks: Das Windigo Botnet. Hier findet ihr genauere Tests und weitere Informationen dazu:
Ist mein Linux Server mit dem Windigo Botnet infiziert?

Ihr solltet auf jeden Fall Eure Linux-Server prüfen!

Gruß
Frank

German Information Detection, blocking Security