frank
Goto Top

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.

Content-ID: 231245

Url: https://administrator.de/knowledge/bsi-warnung-zahlreiche-deutsche-server-mit-ebury-rootkit-infiziert-231245.html

Ausgedruckt am: 23.12.2024 um 05:12 Uhr

chri.s
chri.s 28.02.2014 um 00:54:09 Uhr
Goto Top
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? face-smile

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
Frank
Frank 28.02.2014 aktualisiert um 01:15:03 Uhr
Goto Top
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
chri.s
chri.s 28.02.2014 um 01:40:24 Uhr
Goto Top
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
Epixc0re
Epixc0re 28.02.2014 um 10:04:57 Uhr
Goto Top
Danke für den Tipp, hab gerade alle meine Server gecheckt (rund 200) - alle Clean.
Hab aber dennoch die Snort Rules übernommen!


lG,
Stefan
108012
108012 28.02.2014 um 11:13:32 Uhr
Goto Top
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♬
nussystems
nussystems 28.02.2014 um 16:38:24 Uhr
Goto Top
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
chri.s
chri.s 28.02.2014 um 17:25:03 Uhr
Goto Top
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.
nussystems
nussystems 28.02.2014 um 17:29:44 Uhr
Goto Top
Hmm, wüsste nichts von OTRS auf dem betreffenden Server...
Werde dann wohl mal weiter schauen...

Danke!
chri.s
chri.s 28.02.2014 um 18:33:04 Uhr
Goto Top
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?
chri.s
chri.s 01.03.2014 um 00:44:36 Uhr
Goto Top
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?
Anon0815
Anon0815 01.03.2014 aktualisiert um 15:33:20 Uhr
Goto Top
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?
it-frosch
it-frosch 04.03.2014 aktualisiert um 11:25:59 Uhr
Goto Top
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
b.frenzel
b.frenzel 06.03.2014 um 13:37:30 Uhr
Goto Top
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 ;)
Frank
Frank 07.03.2014 aktualisiert um 17:45:16 Uhr
Goto Top
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
b.frenzel
b.frenzel 07.03.2014, aktualisiert am 14.03.2014 um 16:12:13 Uhr
Goto Top
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 face-smile https://github.com/befrenzeNET/monitoring-scripts/tree/master/check_mk_l ...
Frank
Frank 21.03.2014 um 00:52:46 Uhr
Goto Top
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