1. Herzlich willkommen bei WPDE.org, dem grössten und ältesten deutschsprachigen Community-Forum rund um das Thema WordPress. Du musst angemeldet oder registriert sein, um Beiträge verfassen zu können.
    Information ausblenden

Gibts ne Lücke?

Dieses Thema im Forum "Allgemeines" wurde erstellt von miccom, 13. Februar 2009.

  1. miccom

    miccom Well-Known Member

    Registriert seit:
    2. Juli 2006
    Beiträge:
    193
    Zustimmungen:
    0
  2. hakre

    hakre Well-Known Member

    Registriert seit:
    25. Juni 2007
    Beiträge:
    348
    Zustimmungen:
    0
    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.
     
    #2 hakre, 18. Februar 2009
    Zuletzt bearbeitet: 18. Februar 2009
  3. codestyling

    codestyling WPD-Team

    Registriert seit:
    30. März 2008
    Beiträge:
    1.904
    Zustimmungen:
    0
    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/:
    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.
     
  4. hakre

    hakre Well-Known Member

    Registriert seit:
    25. Juni 2007
    Beiträge:
    348
    Zustimmungen:
    0
    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.
     
  5. codestyling

    codestyling WPD-Team

    Registriert seit:
    30. März 2008
    Beiträge:
    1.904
    Zustimmungen:
    0
    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!
     
  6. hakre

    hakre Well-Known Member

    Registriert seit:
    25. Juni 2007
    Beiträge:
    348
    Zustimmungen:
    0
    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.
     
  7. codestyling

    codestyling WPD-Team

    Registriert seit:
    30. März 2008
    Beiträge:
    1.904
    Zustimmungen:
    0
    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.
     
  8. hakre

    hakre Well-Known Member

    Registriert seit:
    25. Juni 2007
    Beiträge:
    348
    Zustimmungen:
    0
    *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.
     
    #8 hakre, 18. Februar 2009
    Zuletzt bearbeitet: 18. Februar 2009
  9. Sebbi

    Sebbi Member

    Registriert seit:
    19. Februar 2009
    Beiträge:
    9
    Zustimmungen:
    0
    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:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    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.
     
  10. hakre

    hakre Well-Known Member

    Registriert seit:
    25. Juni 2007
    Beiträge:
    348
    Zustimmungen:
    0
    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.
     
  11. Sebbi

    Sebbi Member

    Registriert seit:
    19. Februar 2009
    Beiträge:
    9
    Zustimmungen:
    0
    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):
    HTML:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    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
     
  12. hakre

    hakre Well-Known Member

    Registriert seit:
    25. Juni 2007
    Beiträge:
    348
    Zustimmungen:
    0
    Ja da kommt doch langsam Licht ins Dunkel. Eine wirklich wichtige Empfehlung ist es die einzelnen Anwendungen voneinander zu isolieren. Das mit dem wwwrun ist nicht mehr zeitgemäss. Rede mal mit dem Serveradmin, es gibt da eignetlich ganz nette Wege einzelne vhosts unter eigenen usern laufen zu lassen. Gerade mit PHP Anwendungen mit älterer Codebasis (wie WordPress) würde ich da nichts anbrennen lassen.

    Ich kann auch besonders Suhosin empfehlen. Das Teil hat einem öfter schonmal den Arsch gerettet.

    WordPress 2.6.1 hatte den Bug, dass Payload aus anderen Verzeichnissen nachgeladen werden konnte (#6871).

    WordPress 2.7.1 hatte den Bug insoweit immer noch, dass der Payload weiterhin aus dem Plugin Verzeichnis nachgeladen werden konnte (#9164).

    Das Ticket konnte ich aufgrund von deinem Report aufmachen, es gibt bereits einen ersten Patch. Ich Teste den gerade und ich schätze es recht positiv ein, dass dann auch mit 2.7.2 besser auf solche Attacken reagiert werden kann.

    Das Snippet was Du gerade gepostet hast ist ja auch mal interessant. Da sieht man mal wie viel Mühe der Angreifer sich gegeben hat um die WordPress Installation möglichst lange als Web-Drohne nutzen zu können.

    Man Merke!: Javascript is evil. Ruhig auch mal auf der eigenen Seite JS ausmachen. Ich empfehle NoScript für Firefox.
     
  13. Sebbi

    Sebbi Member

    Registriert seit:
    19. Februar 2009
    Beiträge:
    9
    Zustimmungen:
    0
    @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 ;)
     
  14. NHQ

    NHQ Member

    Registriert seit:
    1. Oktober 2008
    Beiträge:
    21
    Zustimmungen:
    0
    Moinsens...

    möglicherweise - ich kann es nicht genau sagen, weil ich nur einen Bruchteil dieses Threads verstanden habe - ist bei mir sowas ähnliches gelaufen... Irgendwann zwischen 8 und 14 Uhr - ich war natürlich außer Haus, denn als ich heute Nachmittag ins Blog gucken will, gibts Server-Fehler... jemand - und das war nicht ich - hat den WP-Ordner 777 gestellt...

    Bei zwei Plugins fanden sich in den Ordern .old-Dateien


    Hab nun erstmal auf die ersten Kommentare hier hin den gesamten Plugin-Ordner vom letzten Backup drüber gezogen und die Schreibrechte entsprechend geändert, muss mir jetzt nochmal den Rest euer Sachen durchlesen

    Mir ist gerade so richtig schlecht....
     
  15. Sebbi

    Sebbi Member

    Registriert seit:
    19. Februar 2009
    Beiträge:
    9
    Zustimmungen:
    0
    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
     
  16. Sebbi

    Sebbi Member

    Registriert seit:
    19. Februar 2009
    Beiträge:
    9
    Zustimmungen:
    0
    Hier alle Daten und Dateien, die ich bisher gesammelt habe.

    Grüße
     
  17. NHQ

    NHQ Member

    Registriert seit:
    1. Oktober 2008
    Beiträge:
    21
    Zustimmungen:
    0
    Hi nochmal,

    hatte bei dir schon entsprechende Hinweise gesehen und tatsächlich zwei neue Admin-Einträge gefunden, die ich in der DB entsprechend gelöscht habe... so weit so gut...

    Allerdings muss ich ab hier sagen "Oh weia", denn ich bewege mich nun schon weit ab außerhalb meines Kompetenzbereichs... wp-options, wp-usermeta... ich habe Null Ahnung, was davon valide und was schadhafter Code sein soll... Gucke mir gleich deine Zips an... wenn ich da was von finde was mach ich damit? Rauslöschen?

    Update:
    - active_plugin sieht sauber aus (als wüßte ich, was sauber ist *lol*)
     
    #17 NHQ, 20. Februar 2009
    Zuletzt bearbeitet: 20. Februar 2009
  18. Sebbi

    Sebbi Member

    Registriert seit:
    19. Februar 2009
    Beiträge:
    9
    Zustimmungen:
    0
    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?
     
  19. NHQ

    NHQ Member

    Registriert seit:
    1. Oktober 2008
    Beiträge:
    21
    Zustimmungen:
    0
    Also der active_plugins-Eintrag sieht sauber aus, da ist nur drin, was ich auch an Plugins hab, kein anderer Kram...

    Ich hab ne ganze reihe von einträgen mit option_name wie rss_867bd5c64f85878d03a060509cd2f92c Magpie-Dingens in der aller möglicher Text steckt, was ist denn davon schlecht????

    Vers. 2.7.1, Welcher Art Server??? Nen Net-Housting-Server, frag mich nich nach den Spezifikationen *g*

    Update: internal_Links_cache ist bei mir leer, das hatte ich auch schon in Google Webastertools nachgeguckt, da war nichts...

    Update2: Ganze 11(!) first_name-Einträge mit dem entsprechenden SuperUser-Code... was mache ich damit? Nur den Inhalt löschen oder den ganzen Eintrag? Was ist mit den dazugehörigen wp-capabilities und Wp-user-level-Einträgen???
     
    #19 NHQ, 20. Februar 2009
    Zuletzt bearbeitet: 20. Februar 2009
  20. NHQ

    NHQ Member

    Registriert seit:
    1. Oktober 2008
    Beiträge:
    21
    Zustimmungen:
    0
    Ach ja und vielleicht noch diese Frage aus der Kategorie Döfst-Anzunehmender-User: Gibts irgendwo nen Schema, das zeigt, welche Ordner/Dateien denn welche (Schreib-)Rechte haben müssen (maximal/minimal) damit WP läuft??? Wenns da überhaupt individuelle Unterschiede gibt...
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden