Open Source im professionellen Einsatz

Linux/Cdorked.A: Die Apache-Backdoor

Zahlreiche Installationen des Apache-Webservers sind derzeit von einer neuen Backdoor namens Linux/Cdorked.A betroffen. Anfällig sind hierbei Systeme, die die das Hosting-Control-Panel Cpanel verwenden.

Die Backdoor selbst hinterlässt keinerlei Spuren auf der Festplatte außer der modifizierten Apache-Binärdatei "httpd". Das Binary wird zudem mit dem Immutable-Flag versehen, was das Überspielen durch ein Update verhindert. Der Administrator muss also vorher mit "chattr -ai" das Flag löschen.

Alle ihre Konfigurations- und Statusinformationen hält die Backdoor in einem circa 6 MByte großen Shared-Memory-Bereich des Hauptspeichers. Die Backdoor lässt sich nicht einfach anhand der Binärdatei entdecken, da alle verdächtigen Code-Teile und Strings darin aufgrund einer statischen XOR-Verschlüsselung nicht direkt lesbar sind. Hierbei kommt der folgende statische XOR-Schlüssel zum Einsatz:

27A4E2DADAF183B51E3DA7F6C9E6239CDFC8A2E50A60E05F

Insgesamt sind in Linux/Cdorked.A 70 Strings damit verschlüsselt.

Die Backdoor stellt zudem sicher, dass nicht nur Apache-Prozesse, sondern auch andere Prozesse auf den Shared-Memory-Bereich zugreifen können, was dann für den Zugriff auf die Backdoor benutzt wird.

Zur Kontrolle über den befallenen Rechner ist in die Backdoor eine Reverse-Shell integriert, die sich über spezielle HTTP-GET-Anfragen an den Apache-Server starten lässt. Die GET-Anfrage wird dabei an einen bestimmten Pfad gerichtet, mit einen Query-String in einer speziellen Form, der auch den Hostnamen und Port für die Reverse-Shell enthält. Solange der Angreifer dann diese Shell verwendet, hängt die HTTP-Verbindung, da die Backdoor hier kein Prozess-Forking verwendet. Damit lassen sich etwaige Shell-Sessions auf einem kompromittierten System durch lang-laufende HTTP-Verbindungen entdecken. Allerdings erscheinen die speziellen HTTP-Anfragen zum Aufbau der Reverse-Shell aufgrund ihrer Struktur nicht in Apaches Log-Dateien.

Neben diesem Reverse-Shell-Feature kann ein Angreifer via HTTP-POST auch direkt Befehle an die Backdoor senden. Insgesamt versteht die Backdoor 23 verschiedene Befehle die sich via POST an eine spezielle URL ausführen lassen. Die Befehle werden enthalten auch einen Cookie-Header, der mit "SECID= "beginnt und optionale Parameter für die Befehle enthält. Die Backdoor liefert Daten über ihren Status im ETag-HTTP-Header Eintrag zurück.

Da die Backdoor einen bestimmten Speicherbereich in Beschlag nimmt, lässt sie sich anhand dessen auch identifizieren. Folgendes Programm liest den Speicher
der Backdoor aus:

// This program dumps the content of a shared memory block
// used by Linux/Cdorked.A into a file named httpd_cdorked_config.bin
// when the machine is infected.
//
// Some of the data is encrypted. If your server is infected and you
// would like to help, please send the httpd_cdorked_config.bin
// and your httpd executable to our lab for analysis. Thanks!
//
// Build with gcc -o dump_cdorked_config dump_cdorked_config.c
//
// Marc-Etienne M.Léveillé <leveille@eset.com>
//

#include <stdio.h>
#include <sys/shm.h>

#define CDORKED_SHM_SIZE (6118512)
#define CDORKED_OUTFILE "httpd_cdorked_config.bin"

int main (int argc, char *argv[]) {
    int maxkey, id, shmid, infected = 0;
    struct shm_info shm_info;
    struct shmid_ds shmds;
    void * cdorked_data;
    FILE * outfile;

    maxkey = shmctl(0, SHM_INFO, (void *) &shm_info);
    for(id = 0; id <= maxkey; id++) {
        shmid = shmctl(id, SHM_STAT, &shmds);
        if (shmid < 0)
            continue;

        if(shmds.shm_segsz == CDORKED_SHM_SIZE) {
            // We have a matching Cdorked memory segment
            infected++;
            printf("A shared memory matching Cdorked signature was found.\n");
            printf("You should check your HTTP server's executable file integrity.\n");

            cdorked_data = shmat(shmid, NULL, 0666);
            if(cdorked_data != NULL) {
                outfile = fopen(CDORKED_OUTFILE, "wb");
                if(outfile == NULL) {
                    printf("Could not open file %s for writing.", CDORKED_OUTFILE);
                }
                else {
                    fwrite(cdorked_data, CDORKED_SHM_SIZE, 1, outfile);
                    fclose(outfile);

                    printf("The Cdorked configuration was dumped in the %s file.\n\n", CDORKED_OUTFILE);
                }
            }
        }
    }
    if(infected == 0) {
        printf("No shared memory matching Cdorked signature was found.\n");
        printf("To further verify your server, run \"ipcs -m -p\" and look");
        printf(" for a memory segments created by your http server.\n");
    }
    else {
        printf("If you would like to help us in our research on Cdorked, ");
        printf("please send the httpd_cdorked_config.bin and your httpd executable file ");
        printf("to our lab for analysis at leveille@eset.com. Thanks!\n");
    }
    return infected;
}

Unklar ist derzeit nich, wie die Webserver von der Backdoor infiziert werden konnten. Die Security-Firma Sucuri äüßert die Vermutung, dass es sich dabei hauptsächlich um Sshd-Brute-Force-Attacken handeln könnte. Eine detaillierte Analyse der Backdoor findet sich im Blog des Antivirus-Unternehmens ESET.

comments powered by Disqus

Ausgabe 05/2014

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook