Archive

Kategorien

sshd rootkit (Exploit) im Umlauf

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:

  • Traffic auf TCP Port 53 zu IPs welche sich nicht in resolv.conf befinden
  • SSHD welcher Shared Memory benutzt (was eigentlich nie der Fall sein sollte)
  • Ungewöhnliche SSH Verbindungen
  • 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.

    4 comments to sshd rootkit (Exploit) im Umlauf

    • Tobi

      Scheinbar tauchen mittlerweile die ersten Versionen mit anderen Filenamen auf. So z.B. libkeyutils-1.2.so.2 bei CentOS 5

      • Tobi

        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

        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.

    • Tobi

      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

      1
      strings /lib/libkeyutils.so.1 | grep 'connect|socket|inet_ntoa|gethostbyname'

      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

    • Tobi

      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

      1
      ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo “System clean” || echo “System infected”

    Leave a Reply

    You can use these HTML tags

    <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">

      

      

      

    ten − 6 =

    This site uses Akismet to reduce spam. Learn how your comment data is processed.