Sicherheit in WordPress: WP-Version aus dem Feed und Quelltext entfernen

Artikel vom 5. August 2009

Wo die Software, da die Hacker: Je erwachsener eine Anwendung, desto magnetischer ist die Beziehung zum Einbrecher. Gewusst wie und wo, hat der eingeschleuste Winzling eine immense (Aus)Wirkung. Applikationen auf Basis von OpenSource haben Dank offenem Quelltext besonders zu leiden, werden massig zum Ziel automatisierter Attacken. Es gilt also eigene WordPress-Installationen zu schützen: Den Admin-Bereich, dito die für den Leser sichtbaren Blogseiten.

WordPress: Zeitnahe Bugfixes bei Sicherheitsrisiken
Die permanent steigende Nutzerzahl zwingt WordPress-Entwickler dazu, Aktualisierungen für gemeldete Sicherheitslöcher zügig und unbürokratisch unters Volk zu bringen. Auch wenn häufige Updates für Aufwand und Unstimmigkeiten auf der Seite der Konsumenten sorgen, werden kritische Lücken prompt und zuverlässig isoliert. Will heißen: Bestimmte Sicherheitslecks betreffen auch bestimmte WordPress-Versionen.

Angeblich für Statistiken, doch auch Angreifer machen davon Gebrauch

Um einem Provokateur die Information über das eingesetzte WordPress zu konfiszieren, wird die aktuell verwendete Versionsnummer aus dem RSS-Feed und den Metadaten des Blogs ausgeschnitten. Denn genau an diesen Stellen fügt WordPress selbsttätig den Hinweis über die installierte Instanz ein, um Statistiktools bedienen zu können. Vermisst also der böswillige Roboter die Auskunft über die vorrätige Version, so wird der Blog bestenfalls übersprungen und entgeht somit einem möglichen Angriff mit Ausnutzung einer ausdrücklichen Schwachstelle.

Der Generator lässt sich mithilfe von WordPress-Plugins gleichwertig umschreiben. Eleganter und effektiver ist es jedoch, das Merkmal gänzlich abzuschalten bzw. die Ausgabe zu unterdrücken. Nachfolgende Befehl-Zeilen übernehmen diese sicherheitsrelevante Aufgabe und werden in der lokalen functions.php eingefügt.

WordPress als Generator im RSS-Feed und Quelltext unterdrücken

<?php
function remove_wp_generator() {
  if (is_admin() || is_feed()) {
    return;
  }

  if (function_exists('the_generator')) {
    add_filter(
      'the_generator',
      create_function(
        '$x',
        'return;'
      )
    );
  }
}

add_action(
  'init',
  remove_wp_generator
);
?>

Hinweis
<?php und ?> gehören nur dann übernommen, wenn die Datei functions.php entweder neu erstellt wurde oder gänzlich leer ist.

Ausgabe des Generators im Theme
Bedauerlicherweise geben zahlreiche Themes im Template header.php die verräterische Information ebenfalls aus und steigern somit die vorhandene Gefahr. Es empfiehlt sich in der besagten Datei des ausgewählten Theme nachzuschauen und die Zeile <meta name=”generator” … /> zu löschen.

Analyse auf Vorhandensein der WP-Version in den Metadaten
Um aufzuzeigen, wie unvorsichtig deutsche Blogger mit der Bekanntgabe der Versionsnummer umgehen und Hackern Tür&Tor offen halten, wurden insgesamt 35.594 deutschsprachige Blogs ausgewertet: Der Quelltext der Startseiten wurde auf die Anzahl der Metatags mit Versionsinformationen analysiert. Mit erstaunlichen und nicht bedenkenlosen Resultaten:

WordPress nennt sich gerne als Generator in den Metadaten des Blogs
Wie oft wird WordPress als Generator in den Metatags genannt?

Nachgefragt
Wie sieht es in euren Blogs aus: Habt ihr die Auskunft im Quelltext und Feed eliminiert? Oder haltet ihr das nicht für sicherheitsrelevant?

[Der Autor] Sergej Müller ist enthusiastischer Software Engineer mit Schwerpunkten Webentwicklung und WordPress. Seit 2007 programmiert und vertreibt er wpSEO, das weltberühmte und patentierte SEO-Plugin für WordPress-Blogs.

37 Kommentare zum Artikel

360 Tage zuvor | #1 Frank

Dazu nutze ich mein kleines Plugin Secure WordPress, was dieses Thema abfängt. Das Ändern der Versionsnummer in einen fiktiven Wert passiert nur bei WP-Versionen, die nicht die Funktion the_generator() haben.

360 Tage zuvor | #2 Sergej Müller

Frank, korrekt. Hatte auch dein Plugin oben im Artikel verlinkt.

360 Tage zuvor | #3 Frank

Der Link oben im Artikel verweist auf ein altes Plugin, was ich nicht mehr pflege. Insofern sollte lieber das neue Plugin, welches ja auch andere Themen zur Sicherheit behandelt, genutzt werden. In diesem Plugin entferne ich auch komplette die Version, überall, außer im Admin-Bereich und ändere nicht den Wert der Version.

360 Tage zuvor | #4 Sergej Müller

Frank, werde ich nachziehen. Danke für den Hinweis auf die neuere Version, habe diese irgendwie nicht mitbekommen.

360 Tage zuvor | #5 Frank

Kein Problem, daher ja der Hinweis.

360 Tage zuvor | #6 Fabian

Jetzt ist mein Template auch frei von dieser Zeile. Ich habe zwar Franks Plugin genutzt, trotzdem aber diese Zeile in der header.php stehen gehabt. Meine Unvorsichtigkeit kommt wohl von der Tatsache, dass mir bisher noch nichts passiert ist. Bin mir aber bewusst, dass das die falsche Einstellung ist.

Gruß

360 Tage zuvor | #7 Jared

Hi Sergej,

ich will ja nicht pingelig wirken aber schau dir mal die Verteilung im Kreisdiagramm an ;) Da scheint irgendwas schief gelaufen zu sein

360 Tage zuvor | #8 Sergej Müller

Jared, hast du Recht. Ist ja eine Google Charts Grafik und da habe ich 17% anstatt von korrekten 7% als Parameter übergeben. Ist angepasst, merci.

360 Tage zuvor | #9 Sergej Müller

Frank, jetzt weiß ich, warum ich ursprünglich auf dein älteres Plugin verlinkt hatte: Die Überschrift auf der Seite des neueren Plugins steht in fetter Schrift “WordPress Login Sicherheit” – da bin ich im Unterbewusstsein davon ausgegangen, dass es sich dabei wirklich um den Schutz der Login-Maske handelt. Erst am Ende des Beitrags wird auf die Möglichkeit, die WordPress-Version zu entfernen, hingewiesen. Nur mal so, aus der Sicht des Lesers wahrgenommen ;)

360 Tage zuvor | #10 Frank

Ja, stimmt – aber du weist ja, es ist nicht leicht den Kern zu nennen. Das Plugin wächst ja auch und so sind nach und nach diverse Themen dazu gekommen.

360 Tage zuvor | #11 Sergej Müller

Frank, ich kenne es zu gut. Wollte nur meine Inkompetenz verteidigen ;)

360 Tage zuvor | #12 Connie

Na, wenn ich die functions.php manipuliere, dann hab ich doch gleich nach einer Aktualisierung wieder die Versionsinfos eingefangen, oder irre ich mich?

360 Tage zuvor | #13 Ivan

Ich verschleiere fast zu Beginn meines Blogs die Versionsnummer von WordPress. Eigentlich würde ich es für gut befinden, wenn WordPress diese Funktion entfernt.

360 Tage zuvor | #14 Sergej Müller

@Ivan
Solange die Mehrheit der Blogger diese Information am Leben lässt, ist es für Automattic – das Unternehmen hinter WordPress – eine durchaus gute und zuverlässige Grundlage, um auf die Verbreitung bestimmter Versionen zuzugreifen.

360 Tage zuvor | #15 Sergej Müller

@Connie
functions.php liegt im Verzeichnis deines Themes. Bei einer WordPress-Aktualisierung werden nur die Core-Dateien überschrieben, keinesfalls der Inhalt des wp-content-Ordners. Genau aus diesem Grund werden solche Anpassungen auch nicht direkt im Systemkern erledigt, sondern in die extra dafür vorgesehene functions.php ausgelagert.

360 Tage zuvor | #16 ocean90

Ivan , nicht die functions.php aus dem wp-includes Verzeichnis, sondern die aus deinem Themeverzeichnis, wie Sergej es schon sagte.

358 Tage zuvor | #17 michi

Hm, ich hab das jetzt mal probiert, hab den String in die functions.php eingefügt und in der header.php meines Themes nachgeschaut, ob dort der meta-Tag mit “generator” noch zu finden ist.. war er nicht.

Hab dann mal meinen Blog mit strg+Aktualisieren neu geladen. Ergebnis: Im Quelltext ist die Versionsangabe immer noch drin.

Dann mal mit dem IE die Site aufgerufen (da hatte ich den Blog mit dem aktuellen Theme noch gar nicht angesurft..). Auch da ist die Angabe immer noch drin. Was mach ich falsch, bzw. wo könnte der meta-Tag noch in den Templates versteckt sein?

Gruß und ne angenehme Nacht,
michi

358 Tage zuvor | #18 michi

Okay, update zu meinem letzten Eintrag.
Ich hab den String jetzt mal ans Ende der functions.php gepackt.. nun klappts. Hatte ihn irgendwo in der Mitte halbwegs sinnvoll plaziert – da hat er sich wohl nicht wohlgefühlt ;)

358 Tage zuvor | #19 Sergej Müller

@michi
Sehr schön. Hauptsache, es klappt.

358 Tage zuvor | #20 michi

Leider musste ich den Code wieder rausnehmen, da er bei mir nen Zeilenfehler im Backend erzeugt hat (beim Logout). Kein Plan wieso.. naja, ich werd damit mal ein bissl in meiner Testumgebung rumspielen.

358 Tage zuvor | #21 Sergej Müller

Michi, bestimmt liegt es nicht am obigen Code – aus 2 Gründen: Erstens, wurde dieser ausgiebig auf zahlreichen Blogs getestet und zweitens, die allererste Abfrage sorgt dafür, dass die Befehle aus dem Beispiel oben im Admin-Bereich nicht ausgeführt werden.

Entweder du hast es falsch eingefügt oder ein anderer Code verursacht (in Verbindung mit diesem) den eigentlichen Fehler. Aber das muss du schon schauen.

358 Tage zuvor | #22 michi

ich bin mir sogar ziemlich sicher, dass es nicht am obigen code liegt. Wohl eher am Code-Aufbau des Themes.. werd ich mich mal durchfuchsen.

358 Tage zuvor | #23 Sergej Müller

Michi, sag Bescheid, wenn du etwas Verwertbares gefunden hast.

355 Tage zuvor | #24 michi

soo, habs jetzt wohl hinbekommen! ;) Zunächst in meiner Testumgebung, dort werde ich es dann auch noch ein paar Tage testen, bevor ich es in meinen Blog einbaue.

Der Fehler lag wohl darin, dass ich den Code wie oben angegeben so in die functions.php reinkopiert hatte, dass irgendwo eine Klammer vor oder nach dem String dann nicht mehr richtig geschlossen wurde..

Also hab ich den Code von oben ohne <?php … ?> genommen und dann innerhalb eines schon vorhandenen PHP-Tags in der functions.php plaziert. Und nun funktionierts.

Naja, kann passieren – zumal ich nicht von mir behaupten möchte, mehrere Seiten PHP richtig lesen zu können, vor allem wenn diese (wie in WP-Themes) in meherere Template-Dateien gesplittet sind.

Soo, lieber ‘Blog of the Week’-Meister – reicht das als Feedback von deiner Leserschaft? (jahaa, ich lese auch die Interviews, die mit dir geführt werden!)

Viele Grüße,
michi

355 Tage zuvor | #25 Sergej Müller

Fein. Ich musste die PHP-Anfangs- und End-Tags angeben, falls die functions.php neu erstellt werden musste. Kann ich aber als kleinen Hinweis oben im Text darauf hinweisen. Schönen Dank.

354 Tage zuvor | #26 atxx

Hallo dein Beitrag gefällt mir gut allerdings finde ich es auch immer ganz praktisch wenn man nachschauen kann als Besucher welche WP Version den so vom Rest der Welt genutzt wird :P.

354 Tage zuvor | #27 Sergej Müller

atxx, genau so denken die Hacker auch ;)

354 Tage zuvor | #28 Dieter

Hallo Sergej,

ich verwende das WP-Plugin Secure WordPress von Frank (siehe 1. Kommentar), damit aus dem Quelltext als auch dem RSS-Feed weder die WordPress-Version noch WordPress selbst direkt erkennbar sind.

Selbst Webmastercoffeee erkannte nicht, dass ich WordPress im Einsatz habe (siehe hierzu meinen Blogbeitrag “Webseitenanalyse mit Webmastercoffee”).

Beste Grüße
Dieter

354 Tage zuvor | #29 Cujo

Was spricht eigentlich dagegen, den Meta-Tag einfach in der header.php zu löschen?

353 Tage zuvor | #30 Sergej Müller

Cujo, spricht absolut nichts dagegen – das empfehle ich ja ebenfalls oben im Artikel. Bedauerlicherweise fügt WordPress – aus dem Core heraus – einen weiteren Metatag mit der WordPress-Version hinzu, den man nicht ohne den oberen “Trick” herausbekommt.

344 Tage zuvor | #31 shibumi

vielen dank für dieses posting. das ist ein thema was ich bisher noch gar nicht gross betrachtet habe. das liegt noch viel vor mir.

326 Tage zuvor | #32 Alex Rabe

Also bei der aktuellen Welle von Angriffen ist mir aufgefallen, das Hacker sich nicht im Geringsten die Mühe machen die Meta Information auszuwerten, es wird blind alles versucht anzugreifen was ein WordPress Blog ist. Das ist mir schon immer augefallen, im Apache Log finden sich dutzend Versuch von Angriffen, selbst auf Dateien die garnicht vorhanden sind (z.B. Joomla / Mambo Bug’s). Und das du WP installiert hast, kannst du nun wirklich nicht verschleiern…

326 Tage zuvor | #33 Sergej Müller

@Alex Rabe
Also mir ist aufgefallen, dass Blogs ohne Metainformationen von der gleichen Quelle deutlich seltener “angepingt” werden. Und das reicht mir als Bestätigung der vorgeschlagenen Lösung eindeutig. Klar, Abweichungen kann es je nach Blog und Stärke bzw. Häufigkeit der Attacken geben – wird keiner dementieren. Aber auf lange Sicht gesehen (und ich beobachte die Änderungen seit fast einem Jahr) lohnt sich der Einsatz.

325 Tage zuvor | #34 Sergej Müller

@Alex Rabe
Und wenn wir schon beim Thema “Bots achten sowieso nicht auf die WordPress-Versionsnummer”: Der zurzeit im Umlauf befindliche Virus mit der so genannten Permalink-Hintertür hat sich die Opfer ganz schlau ausgesucht: Nein, es wurde nicht wahllos jeder beliebige WordPress-Blog angegriffen, die Google-Suche nach meta generator content WordPress … lieferte das gewünschte Ergebnis.

Mehr muss ich zu der Wirksamkeit der obigen Technik nicht sagen.

294 Tage zuvor | #35 Joachim

Vielen Dank für die Information und die Anleitung. Hab das gleich gemacht und hat problemlos funktioniert. Thx

82 Tage zuvor | #36 Denis

Probleme mit diesem habe ich noch nicht entstanden. Aber danke für die Beratung und Warnung!

26 Tage zuvor | #37 Michael

Hallo, was ich bedauere ist, das dies noch nicht in die nachfolgenden Versionen übernommen wurde, da ja wie oben schon beschrieben wurde, dies einem Angreifer schon wichtige Informationen liefert. Habe dies auf einem meiner Blogs nunmehr realisiert, welcher sich in produktiver Umgebung befindet.

Gibt es noch weiter, simple Hardcodemöglichkeiten, im verwendetem Theme Sicherheitslücken bzw. Hinweise auf Solche zu verschleiern?

MfG Micha