Ein sshd Rootkit ist scheinbar im Umlauf

[jahlives]

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!
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: Traffic auf TCP Port 53 zu IPs welche sich nicht in resolv.conf befinden oder der SSHD welche Shared Memory benutzt (was eigentlich nie der Fall sein sollte). Ersteres kann man mit tcpdump auf dem Gateway prüfen, letzteres 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). Was auch ein Anzeichen sein kann ist wenn man den ssh traced (mit strace) und dieser beim connect auf unbekannte IPs verbindet resp Verbindungen von unbekannten IPs auftauchen. Um das ganze zu (s)tracen habe ich ein kleines Script geschrieben, das stell ich später mal noch hier rein.

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

 

[jahlives]

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

#!/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

#!/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.

./strace-process ssh[d]
CTRL+c
./syscallparse

danach

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.

Achtung: das ganz dürfte auf einer DS wohl so ned laufen. Auf den ersten Blick wegen ps aux. Der default ps der Firmware kennt diese Parameter nicht!

 

[jahlives]

hier noch ein Link zum letzten Statement von CPanel. zumindest bei CPanel scheint es, dass der Angriff via einen admin-PC erfolgte, der dann den Proxy-Server des Supports kompromittiert hat

http://www.webhostingtalk.com/showpost.php?p=8577480&postcount=1403
cPanel, Inc. Announces Additional Internal Security Enhancements

This is a follow up on the status of the security compromise that cPanel, Inc. experienced on Thursday, February 21, 2013.

As mentioned in our email sent to cPanel Server Administrators who’ve opened a ticket with us in the past 6 months, on February 21 we discovered that one of the proxy servers we utilize in the technical support department had been compromised. The cPanel Security Team’s investigation into this matter is ongoing.

We’d like to relay additional details about the intrusion that we have gathered with you, and we want to explain what preventative measures we’re putting in place that will introduce additional layers of security to our new and existing systems, already in place. How the server was accessed and compromised is not clear, but we know a few key facts that we’re sharing.

Here’s what we know:

* The proxy machine compromised in this incident was, at the time, utilized to access customer servers by some of our Technical Analysts. It's intent was to provide a layer of security between local & remote workstations and customer servers.

* This proxy machine was compromised by a malicious third-party by compromising a single workstation used by one of our Technical Analysts.

* Only a small group of our Technical Analysts uses this particular machine for logins.

* There is no evidence that any sensitive customer data was exposed and there is no evidence that the actual database was compromised.
Here’s what we’re doing about it:

Documentation is now provided at: http://go.cpanel.net/checkyourserver which we encourage system administrators to use to determine the status of their machine.

We have restructured the process used to access customer servers to significantly reduce the risk of this type of sophisticated attack in the future. We have also been working on implementing multiple changes to our internal support systems and procedures as outlined for your information below.

* Our system will now generate and provide you with a unique SSH key for each new support ticket submitted.

* We are providing tools to authorize and de-authorize SSH keys and instructions on how to use them whenever you submit a ticket.

* Our system will generate a single-use username and password credentials for accessing WebHost Manager that are only valid while our staff is logged into your server.

* Additional enhancements are also planned behind the scene that should be transparent to our customers.

With these new layers of security in place, it is now possible for our Technical Analysts to service your support requests without you providing your server’s password for nearly all requests involving machines running our cPanel & WHM product going forward. However, we will still offer the ability to provide your password for server migrations, or in the event you cannot use SSH keys.

cPanel’s Internal Development Team has been working on an automated solution with the end goal of eliminating the need for our Technical Analysts to view any passwords you provide during the ticket submission process. We are testing this solution right now, and hope to have it fully implemented in the next few days.

cPanel, Inc. understands your concerns expressed over the last few days, and we very much appreciate the cooperation and patience you have provided us during this time as we work through all of this.

Thank you.

 

[jahlives]

Ergänzung:
es scheint sich gemäss webhostingtalk.com abzuzeichnen, dass die Angriffe nicht direkt auf die Server erfolgen, sondern über Seitenangriffe durch infizierte Admin-PCs. Das deckt sich auch mit dem Statement von CPanel. Erfahrene Benutzer im genannten Forum behaupten klipp und klar, dass bei ihnen der initiale Angriff auf einen Windows Admin PC erfolgte und dieser dann als Sprungbrett für die Kompromittierung des Servers benutzt wurde. Es zeichnet sich zudem ab, dass hier eine Kombination von Exploits benutzt wird. Einerseits wird scheinbar auf den admin PC mehr oder weniger die komplette ssh-Lib ersetzt und andererseits auf den Servern nur ein neues File (libkeyutils) reingeworfen und mit ssh gelinkt. Erste Virenscanner (AVG für Linux) haben mittlerweile Signaturen für die gefakten libkeyutils Files. Wiederum gemäss den Leuten von webhostingtalk haben sie die Windowskomponente scheinbar mit dem Scanner von malwarebytes ermittelt

<ramnet> nenolod, how did you find that windows rootkit earlier? where was it's payload located?
<nenolod> ramnet, i just ran malware bytes anti malware, and it was a file in C:\Windows\System32 running as LOCAL_SERVICE permissions

Auch folgende Kommunikation zwischen den beiden Usern ist ziemlich erscheckend (so denn alles wirklich so zutrifft)

<nenolod> interesting
<nenolod> we found a rootkit on tortoiselabs office equipment
<nenolod> running windows 7
<nenolod> and our OVH creds were changed from that machine
<steven> oh noes the h4x
<nenolod> i wonder if it is related to SSHD thing
<steven> good question
<steven> get to work
<steven>
<nenolod> i have the binaries, i intend to look at them in a bit with idapro
<nenolod> btw
<nenolod> the rootkit
<nenolod> was sending keystrokes as DNS requests
<nenolod> to the same russian IP
<steven> which ip
<steven> what did you use to pickup the rootkit
<nenolod> the 78.x nameserver ip
<steven> gotcha
<nenolod> i used tcpdump while typing into the keyboard on the errant machine
<nenolod> i then disconnected it from the network $
<nenolod> rabbit:/home/nenolod# apk audit --system
<nenolod> M /lib/libkeyutils.so.1 -> /lib/libkeyutils.so.1.9
<nenolod> ? /lib/libkeyutils.so.1.9
<nenolod> well, that's concerning
<nenolod> and, /tmp contains a copy of openssh source
<steven> even the great neno has been h4x
<nenolod> this is new
<nenolod> and it is a honeypot
<nenolod> it's supposed to be h4x
<nenolod> the concerning part is that they seem to build the rootkit on the machine
<nenolod> observation: why would sshd link against libkeyutils.so?
<nenolod> ran apk fix
<steven> kernel key management
<ramnet> nenolod, did you access your honeypot from the workstation that had the keylogger on it?
<nenolod> as a matter of fact, yes!
<ramnet> so, you've pretty much confirmed that's what the cause of the hack is then
<steven> nenolod would you be willing to pass me the windows rootkit?
<nenolod> steven, yeah as soon as i have a chance to get the machine network-accessible again

wie gesagt das sind "nur" User, aber wenn das korrekt ist, dann ist dies ein wirklich gravierendes Problem und betrifft unterschiedlichste Plattformen.
nach aktuellem Stand sind folgende IPs als Steuer- und Kommunikationsserver bekannt

78.47.139.110
94.23.23.153
94.23.72.193
188.165.129.30
87.230.54.65
46.105.108.166
46.105.20.166
178.162.248.74

als erste Nothilfe sollte man jeglichen Traffic von oder zu diesen IPs an JEDER Firewall blocken. Interessant ist dabei auch, es hat eine IP darunter welche Hetzner gehört