Dipl.-Inform. Carsten Eilers

Die Websense Security Labs berichten über ein möglicherweise neues Exploit-Kit, dass über Schwachstellen in Wordpress 3.2.1 verbreitet wird, für die öffentliche Exploits verfügbar sind.

Die Schwachstellen befinden sich tatsächlich nicht in Wordpress selbst, sondern in zwei Plugins. Zumindest sind die im Websense-Bericht verlinkten Exploits für das WP-SpamFree Plugin (das vom Hersteller laut Website nicht mehr unterstützt wird) und das UPM Polls Plugin und nicht für Wordpress selbst.

Im WP-SpamFree Plugin wurde eine SQL Injection Schwachstelle entdeckt, die in der Exploit-DB bisher als "nicht überprüft" gekennzeichnet ist. Bei Secunia ist diese Schwachstelle nicht zu finden, ein SecurityFocus-Eintrag ist jedoch vorhanden.
Im UPM Polls Plugin wurde eine Blind SQL Injection Schwachstelle entdeckt, die Funktionsfähigkeit des Exploits wurde von der Exploit-DB bestätigt. Es gibt auch Einträge bei Secunia und SecurityFocus zu dieser Schwachstelle.

Websense findet die Schwachstellen bzw. die Infektion der Websites nicht weiter interessant ("The Web site injection is only somewhat interesting."). Das ist Schade, denn hätte man das ganze etwas näher untersucht, hätte man vielleicht bemerkt, dass die Schwachstellen sich nicht in Wordpress 3.2.1 befinden und vielleicht etwas weiter nach der eigentlichen Infektionsquelle gesucht. Zwar ist es durchaus möglich, über eine SQL-Injection-Schwachstelle Schadcode einzuschleusen, über eine Blind SQL Injection ist das aber ziemlich schwierig. Und bestätigt wurde bisher nur die Blind SQL Injection.

Websense hat nur den weiteren Infektionsweg untersucht. Demnach wird in die Seiten der Website kodierter Code eingefügt, der nach dem Dekodieren einen iframe in die Seite einfügt, der dann zu einer Drive-by-Infektion führt. Dabei wird lediglich ein einziger Exploit eingesetzt: Der für eine Remote Code Execution in Java. Davon wird dann das TDSS-Rootkit nachgeladen. Beim verwendeten Exploit-Kit soll es sich entweder um Incognito 2.0 oder ein komplett neues Kit handeln.

Die M86 Security Labs

Die M86 Security Labs berichten ebenfalls über kompromittierte Wordpress-3.2.1-Installationen, dort ist aber vom Heraufladen einer HTML-Seite in das normale Upload-Verzeichnis die Rede. Die Opfer werden dann gezielt per E-Mail auf diese Seite gelockt, beim normalen Besuch der Wordpress-Installation passiert gar nichts.

Übrigens berichtet auch Websense über diese Angriffe, dort aber nur aus Sicht der per E-Mail auf die ins Wordpress-Upload-Verzeichnis eingeschleuste HTML-Seite gelockten Benutzer. Laut Websense wird dort für die Drive-by-Infektion außer dem schon oben erwähnten Java-Exploit auch eine Schwachstelle im Flash Player ausgenutzt. Was davon eingeschleust wird, ist nicht angegeben. Zum Einsatz kommt auf jedem Fall das Phoenix Exploit Kit.

Aber zurück zu den M86 Security Labs: Über Wordpress gibt es dort leider auch keine weiteren Informationen. Allerdings hat man sich Zugriff auf die Weboberfläche des verwendeten Exploit-Kits verschafft und festgestellt, dass Googles Chrome ausdrücklich von Angriffen ausgenommen ist. Wieso, ist natürlich nicht bekannt. Evtl. ist die Erfolgsrate der eingesetzten Exploits (für Internet Explorer, Adobe Reader, Flash Player und Java) dort so niedrig, dass die Gefahr einer Entdeckung zu gross erscheint?

Was wissen wir wirklich?

Nach allem, was bisher bekannt ist, gibt es zwei Angriffswellen, denen mehrere Hundert Wordpress-3.2.1-Installationen zum Opfer gefallen sind: "the number of infections is growing steadily (100+)." (Websense) bzw. "hundreds of websites" (M86 Security Labs).

Beim von den Websense Security Labs gemeldeten Angriff wird der Code für die Drive-by-Infektion in die Wordpress-Installation selbst eingefügt, so dass jeder Besucher der Website darüber angegriffen wird. Das Einschleusen des Codes erfolgt dabei evtl. über SQL-Injection.

Beim von den M86 Security Labs gemeldeten Angriffen wird lediglich ein einzige HTML-Seite mit dem Code für die Drive-by-Infektion im Upload-Verzeichnis gespeichert. Die Opfer werden per E-Mail gezielt auf diese Seite gelockt, normale Besucher der Website bekommen diese Seite nicht zu sehen und sind nicht gefährdet. Wie die HTML-Seite hochgeladen wird, ist nicht bekannt.

Was sollen Wordpress-Nutzer jetzt tun?

Wie Wordpress-Nutzer eine Kompromittierung Ihrer Installation verhindern können, lässt sich leider nicht sagen - dazu müsste man wissen, wie die Installationen kompromittiert wurden. Es kann sicher nichts schaden, die jeweils aktuellste Wordpress-Version zu verwenden. Zur Zeit ist das Version 3.3.1 vom 3. Januar 2012. Allerdings enthält auch diese Version mehrere Schwachstellen im Installationsskript, für die es laut Wordpress keinen Patch geben wird, da man einen Angriff für unwahrscheinlich hält.

Außerdem sollten Sie alle nicht benötigten Plugins entfernen (bzw. noch besser: Gar nicht erst installieren) und darauf achten, dass alle verwendeten Plugins auf dem aktuellen Stand sind. Was z.B. im Fall des WP-SpamFree Plugins nicht vor einem Angriff schützt, da das ja nicht mehr aktualisiert wird.

Ob Ihre Wordpress-Installation kompromittiert wurde, können Sie an zwei Stellen erkennen:

1. An einem Script-Tag, dass mit
   <script>if(window.document)aa=(Number+Date).substr(0,4);aaa=
   beginnt, in Ihren Wordpress-Seiten (i.A. am Ende der Seite) oder
2. an einer HTML-Datei mit merkwürdigen Namen in Ihrem Upload-Verzeichnis, die dort nicht hingehört - öffnen Sie diese Seite auf gar keinem Fall im Webbrowser!

Im ersten Fall wurde Ihr Client-Rechner sehr wahrscheinlich beim Besuch Ihrer eigenen Website infiziert, sie müssen also zusätzlich auch dort mit einem Virenscanner nach installiertem Schadcode suchen. Im zweiten Fall besteht keine Gefahr, solange Sie die HTML-Seite nicht im Webbrowser öffnen.

Um die Manipulationen an der Wordpress-Installation zu beseitigen, reicht im zweiten Fall das Löschen der HTML-Datei. Im ersten Fall müssen Sie heraus finden, wo das Skript-Tag eingeschleust wurde. Entweder befindet es sich in einem Datenbankfeld oder in einer Konfigurationsdatei. Jedes Vorkommen des Skript-Tags muss gelöscht werden.

Außerdem müssen Sie herausfinden, wie der Schadcode eingeschleust wurde, und die dazu ausgenutzte Schwachstelle beheben. Ohne weiterführende Informationen über die Angriffe kann ich Ihnen dazu leider keine Hilfestellung außer dem altbekannten Rat "Kontrollieren Sie die Logfiles" geben.

Carsten Eilers