WordPress nutzt wie sehr viele Webanwendungen die Datenbank MySQL. Jedes gute und WordPress geeignete Hosting-Paket sollte solche Datenbanken besitzen. Ohne Datenbank ist WordPress nutzlos, denn alle „dynamischen“ Daten sind dort gespeichert. Blogposts und Seiten sowie Usernamen und Einstellungen werden in der Datenbank gespeichert. Auch Einstellungen für Plugins sind teilweise dort gespeichert. Gehen wir nun die Tabellen im einzelnen an. Wer selbst mal ein Blick in seine Datenbank werfen möchte, der sollte mal bei seinem Webhoster nach dem Tool phpMyAdmin fragen.

Die Tabelle WP – USERS

In dieser Tabelle werden alle Benutzer eines Blogs sowie deren Einstellungen und Berechtigungen gespeichert. Passwörter werden als MD5-Hash gespeichert.

Die Tabelle WP – OPTIONS

In dieser Tabelle werden alle WordPress spezifischen Einstellungen zum Blog gespeichert. Z.B. der Blogname sowie die Blog URL.

Dieses Bild zeigt nur ein Teil aller möglichen Optionen. Ist das Blog-Netzwerk von WordPress aktiviert, so wird diese Tabelle um einiges größer.

Die Tabelle WP – COMMENTS

Hier werden, wie der Name schon deuten lässt, alle Kommentare und dazugehörige Daten gespeichert. Also das Kommentar, die Autoren E-Mail Adresse, die Webseite und natürlich der Name.

Die Tabelle WP – COMMENTMETA

Diese Tabelle dient hauptsächlich dem häufig verwendeten und in WordPress integrierten Plugin Akisment. Hier werden Spam Daten mit den Kommentarnummern verbunden, sodass Akismet überprüfen kann, ob es sich um Spam handelt oder nicht.

Das waren die wichtigsten Tabellen von WordPress. Natürlich kann es von Blog zu Blog unterschiedlich viele Tabellen, je nach Anzahl der Plugins geben. Es wird empfohlen, die Datenbank regelmässig zu aktualisieren.

Bild von eriwst (Flickr)

Begonnen hatte es am 29.01 gegen 00:13 um diese Zeit habe ich geschlafen, sodass ich natürlich nicht mitbekam, dass ich die erste Mail vom Plugin „Limit Login Attempts“ erhielt. Dieses Plugin kann ich allen nur sehr ans Herz legen, es hat mir während des ganzen Angriffes gut geholfen. Hätte ich es nicht eingesetzt so würde es WP – Blogger wohl nicht so schnell in dieser Form wieder verügbar sein. Nun ich dachte mir bei dieser ersten Mail nicht viel, vielleicht hatte jemand am Adminbereich rumgespielt nur aus Spaß.

Dieser Eindruck änderte sich schlagartig gegen 14:37. Ich erhielt eine Mail von WordPress, dass jemand auf Passwort vergessen geklickt hätte. Im Klartext sah diese Mail so aus:

Jemand hat für den folgenden Blog und Benutzernamen das Passwort zurückgesetzt.

http://wp-blogger.de

Benutzername: deichy

Um dein Passwort zurückzusetzen, besuch die folgende Adresse. Wenn du das nicht möchtest, ignoriere diese E-Mail einfach und nichts wird passieren.

***Link zum Zurücksetzen***

Jetzt wurde ich stutzig, denn ich konnte mich sehr wohl an die Mail vom Morgen erinnern. Nur schade, dass dort keine IP steht sonst hätte ich das Ganze mit der Echtzeit Analyse Wassup zurückverfolgen können.

Nachdem das geschehen war, bekam ich weitere Mails vom Plugin „Limit Login Attempts„. Sowohl für De-Script, für WP-Blogger und für eine weitere Kunden-Homepage. Gleichzeitig wurde auf dieser Kundenhomepage auch das Passwort zurückgesetzt. Dank „Wassup“ konnte ich beobachten wie auf

Bild von dongga BS (Flickr)

De-Script und WP-Blogger verdächtigerweise von den gleichen IP’s die xmlrpc.php angesprochen wurde. Unter anderem mit diesen Befehlen, welche einzelne Dateien löschen oder ändern sollen. Das hat in Einzelfällen sogar geklappt.

Außerdem fand ich im Rootverzeichnis der Kunden-Homepage eine .exe Datei. Diese hat die index.php vermutlich geändert. Im Normalfall ist die index.php von WordPress wenige Zeilen lang. Nachdem der Angriff geschehen war, gabs zuerst eine Fehlermeldung beim Aufrufen der Seite welche auf Fehlerhaften PHP Syntax zurückführte. Also schaute ich nach und siehe da keine kurze index.php, nein, das waren 2000 Zeilen Code. Nachdem die .exe Datei gelöscht war und eine alte index.php eingespielt war funktionierte alles wieder problemlos.

Somit fuhr ich abends meinen PC runter in guter Gewissheit, dass alles funktioniert. Vorher waren jedoch noch etwa 6 Mails vom Plugin „Limit Login Attempts“ eingegangen. Jedesmal unterschiedliche IP’s aber der gleiche Hostname. Somit deutet das auf einen gekaperten Server hin. Wie ich später rausfand gehörten diese Server zu Amazon.

Am nächsten Morgen traute ich meinen Augen kaum. 32 Mails vom Plugin, alles unterschiedliche IP’s. Außerdem hatte wieder jemand gegen 1:00 Uhr versucht mein Kennwort auf De-Script zurückzusetzten. Auf Wp-Blogger war der Admin Bereich zerschossen und somit durfte ich ein Backup einspielen.

Nachdem ich dann eine Mail an meinen Server Support schrieb und dieser die betreffenden IP’s sperrte hörten die Angriffe auf. Es wurde eine Beschwerde bei Amazon eingelegt und es stellte sich heraus, dass es Postlink-Server waren von welchen aus der Angriff gestartet wurde.

Jetzt stellt sich die Frage wie ist der Angreifer reingekommen? Durch den Admin Bereich nicht und auch über FTP nicht. Dank Logfiles war es die xmlrpc.php welche oft aufgerufen wurde. Diese Datei dient dazu Trackbacks und Pingbacks zu empfangen sowie für das Fernpublizieren mit z.B. dem WordPress iPhone App. Wer die Datei nicht braucht sollte die Funktion deaktivieren und die Datei löschen. Für meinen Blog, jedoch wird Sie benötigt auch wenn die Datei ein Sicherheitsrisiko darstellt.

Außerdem habe ich das Verzeichnis WP-Admin mit .htaccess geschützt. Ich kann allen nur ans Herz legen das Plugin „Limit Login Attempts“ zu nutzen. Eine weitere Liste wichtiger Plugins findet ihr hier.

Wenn man einmal einen solchen Angriff als Opfer gegenüberstand so wir einem schnell bewusst, dass dort organisierte Kriminalität am Werke ist und der Kampf zwischen den Hackern und den Entwicklern sich immer weiter ausweitet.