Sonstiges

WordPress: Die Krux mit der Beliebtheit

tja, WordPress mag eins der Blog-Tools sein, die weltweit mit am beliebtesten sind, zugleich schießen sich Spammer und Hacker vermehrt drauf ein. Kann mich nicht erinnern, dass ich 2006 in der deutschen Blogosphäre ein Blog gehacked worden ist, 2007 war es dann soweit. Und 2008 scheint es sich zu häufen. Was nun einige Blogger zum Anlass nehmen, sich der Sache genauer anzunehmen:
– Unser täglich Spam: Aktuelle Angriffe auf WordPress-Blogs (mit vielen Tipps)
– Tom’s Diner: Blog-Hack III (schlägt vor, im WordPress-Forum die Lücken zusammenzutzragen)
– Webrocker: WordPress Hackereien
– Ein Blick auf BlogSecurity kann nie schaden

So oder so muss man aufgrund der Beliebtheit von WordPress akzeptieren, dass es nicht mehr sicher ist. Nicht, weil die Software unsicher geworden ist, sondern weil mehr und mehr Leute draußen Sicherheitslücken abtasten und entdecken. Das ist nix Neues, das gabs und gibts mit phpBB (beliebte Forensoftware), mit Windows, mit IE, und und und. Software ist nie sicher, es kommt nur drauf an, wie smart und motiviert diejenigen sind, die nach Lücken suchen. Live with it:)

Was kann man letztlich als Anwender tun? Eigentlich nix, außer WordPress auf dem Laufenden zu halten, was den Einsatz neuer Versionen angeht, ebenso die Plugins updaten. Und, regelmäßig sichern, wobei ich damit die Datenbank und das eigene Template meine. Sollte das Blog dann gehacked werden, ab dafür, Backup einspielen und gut ist. Natürlich sollte man schauen, dass man sein WP updatet, die Plugins ebenfalls und auch die Accounts ändert.


Neue Stellenangebote

Growth Marketing Manager:in – Social Media
GOhiring GmbH in Home Office
Senior Social Media Manager:in im Corporate Strategy Office (w/d/m)
Haufe Group SE in Freiburg im Breisgau
Senior Communication Manager – Social Media (f/m/d)
E.ON Energy Markets GmbH in Essen

Alle Stellenanzeigen


Wie man das feststellt, ob man gehacked wurde? Am besten wäre es, seinen eigenen Feed zu abonnieren, da momentan Spam-Hacks beliebt sind, die in bestehende Blog-Artikel Spamlinks eintragen. Das führt dazu, dass die Artikel im Feed erneut erscheinen, wobei man dann schon im RSS-Reader einstellen sollte, dass geänderte Artikel eben angezeigt werden sollen. Das hilft wie gesagt nur als ein Indikator, da es aber unterschiedliche Hacks gibt, muss man drauf hoffen, dass man es früh genug entdeckt. Auch da kann man sich helfen: Wie groß ist meine gesamte Domain (über die Administrationsoberfläche des Hosters nachschauen) in Kilobyte, wie groß ist das WordPress-Verzeichnis, wie groß ist der root-Folder, wie groß ist der public-Folder (Größe der Log-Datei und eventuell automatische Sicherungen abziehen)? Gibt es einen ungewöhnlichen Anstieg des Datenvolumens? Weiterhin sollte man die Datenbank checken (über Tools, die der Hoster zur Verfügung stellt). Wie groß ist die Datenbank, genauer gesagt, wie viele Datensätze sind insgesamt gespeichert? Und über FTP sollte man sich die Verzeichnisse genauer ansehen. Ist ein neues Verzeichnis hinzugekommen? Eine neue Datei? Außer denen, die man im Upload-Verzeichnis selbst hochgeladen hat, dürfte es keine neuen Dateien geben (Ausnahme: Wer Caching-Mechanismen nutzt, der wird natürlich gecachte Dateien im Cache-Verzeichnis erzeugen). Also: Backups machen, eigenen Blog-Feed abonnieren, Speicherverbrauch, Anzahl Datensätze und Verzeichnisse/Files checken. Alles Tätigkeiten, die man in bestimmten Intervallen ausführen kann, ohne dass es in Stress ausartet. Wie gesagt, wer eine Seite unbedingt hacken will, wird es eh schaffen, wenn er genügend Zeit mitbringt und über ein profundes Wissen verfügt. Also ab dafür.

Über den Autor

Robert Basic

Robert Basic ist Namensgeber und Gründer von BASIC thinking und hat die Seite 2009 abgegeben. Von 2004 bis 2009 hat er über 12.000 Artikel hier veröffentlicht.

40 Kommentare

  • vielleicht noch ein Tipp, um Hacks festzustellen:
    die letzten Hacks haben fast immer Links auf diverse SPAM-Produkte im Gambling- oder Pharma-Bereich eingeschleust, und die maskiert, dass sie im Browser nicht sichtbar waren.
    Bei den Blogs die ich betreue prüfe ich regelmäßig den Quelltext der Seite und führ eine Suche nach gängigen SPAM-Keywords durch.
    Wenn man es highly-sophisticated haben will, dann kann man auch noch den Browser so einstellen, dass er sich als google-bot meldet. 😀
    Ich hab gottseidank aber noch keinen Hack gefunden… sind halt einfach zu unbedeutend meine Blogs. 😛

  • es soll letztlich auch Attacken geben, die gezielt auf Blog mit hohem Pagerank abzielen, aber das ist nur ein Teil. Bekanntheit schützt nicht, egal wie rum.

  • Yup, stimmt, sowohl Bekanntheit als auch Unbekanntheit schützen nicht, man hat ja aus jeder Gruppe schon Betroffene getroffen.
    Ergo: Updaten und regelmäßig prüfen…. oder?

  • Vor allem der Tipp, die eigenen Feeds zu abonnieren, ist wichtig. Schon alleine deswegen, weil man nur dann sehen kann, wenn mal aufgrund eines unerlaubten Sonderzeichens (Feeds sind XML, nicht HTML, also sind z.B. nicht alle „Enities“ erlaubt) ein Feed ungültig wird. Außerdem sieht man nur über die eigenen Feeds, was die Mehrzahl der Leser sieht.

    Gerade für Spammer dürften übrigens doch wenig frequentierte oder gar tote Blogs nicht uninteressant sein: Sie werden weniger beobachtet und gepflegt, weswegen Spamlinks nicht so schnell entdeckt werden.

  • >So oder so muss man aufgrund der Beliebtheit von WordPress akzeptieren, dass es nicht mehr sicher ist.

    Dem kann ich so ganz und gar nicht zustimmen, es mag ein Faktor sein, aber einer unter vielen. Bestes Beispiel ist Linux, das Gros des Netzes läuft darauf und demnach wäre es eines der unsichersten Betriebssysteme auf dem Planeten. Das paßt nicht, vielmehr kann man WP schlechten Code attestieren und eine schlechte Basis hat dann natürlich bei entsprechend großer Verbreitung auch das Nachsehen. Die Unterscheidung bei Software per se ist eben, wie gut ist die Basis? Wenn diese okay ist kann die Verbreitung kaum etwas ausrichten in puncto Fehleranfälligkeit und der Rest liegt in der Eigenverantwortung mündiger User. Bei Betriebssystemen wäre dieser Punkt erfüllt mit bewußt eingesetzter Software, sprich Kenntnis bezüglich der Risiken und Nebenwirkungen, bei Weblog Software wären das Plugins und Themes die es zu beobachten gilt. Eine vernünftige Basis jedoch bietet WP im Vergleich zu anderen Blogs jedoch nicht.

  • ja, hmhmhm, wenn ich an die vielen Updates bei Linux und Apache und MySQL denke.. hmhmhm.. anyway, Vorteil ist, wenn man eine große Entwicklercommunity hinter sich weiß, dass es eigentlich sicherer werden müsste. Angesichts dessen, dass komplexere Systeme von vornherein zahlreiche Angriffsflächen bieten, muss man sich fragen, ob Automattic überfordert ist, denn WP ist nicht mal ansatzweise mit der Komplexität eines OS zu vergleichen. Da sollte es also weniger Angriffsflächen geben.

  • mhm…grummel, einen Blog hat man ja oft auch als nicht so affiner Nutzer. Genau das ist dann aber auch mein Problem. Ich kann da was reinschreiben, bin ja froh, dass es WordPress so einfach macht, aber noch mehr Administratoren Aufgaben kann ich mangels Wissen dann doch nur mit erweitertem Wissen übernehmen.

    Genau dies macht es für mich aber wieder zur Einstiegshürde. Will ja einfach mal fix was bloggen, was mich gerade so beschäftigt.

    Wie gesagt, so geht´s mir, trifft nicht für andere zu.

  • man man man, schiebt ihr heut wieder panik weil paar blogs gehackt wurden. Kann mal jemand logfiles veröffentlichen wie die besagten blogs gehackt wurden, alles andere ist kalter kaffee.

  • Du wertest das als Panik, ich sehe keine:) Aber die Idee mit den Logfiles hatte ich auch schon vorgeschlagen, wobei ich die an Automattic senden würde;))

  • dann bin ich dafür, dass wenn Automattic zurückkommt mit dem Bericht, das man das öffentlich zu lesen bekommt. Würde mich schon interessieren obs an der Dummheit der Betreiber oder an einer Schwachstelle in WP liegt.

  • Jemand sollte ein Plugin schreiben, das alle diese Daten regelnässig überprüft. Gesamtgrösse der Ordner, Anzahl der Dateien, Grösse der MySQL-Datenbank, etc.. Das sollte dann täglich in eine andere Datenbank geschrieben werden, die unabhängig von WordPress läuft.. In WordPress kann man dann einstellen, wieviele Tage man überwachen möchte, 30,60,90 oder was auch immer. Zusätzlich werden regelmässig Erinnerungen an diverse Wartungsarbeiten im Header des Blogs und im WP-Admin ausgegeben… 😉

    Das wäre fein. 🙂

  • Mir fällt gerade auf, das deine Seite hier nicht valide ist….

    Ergebnis der Prüfung:
    ———————-
    https://www.basicthinking.de/blog/2008/03/25/wordpress-die-krux-mit-der-beliebtheit/#comment-818479

    Zeile 374 Zeichen 90 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&model“
    Zeile 374 Zeichen 98 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&width“
    Zeile 374 Zeichen 108 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&height“
    Zeile 374 Zeichen 119 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&fontcolor“
    Zeile 374 Zeichen 136 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&pricecolor“
    Zeile 374 Zeichen 154 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&bgcolor“
    Zeile 374 Zeichen 169 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&bdcolor“
    Zeile 374 Zeichen 184 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&count“
    Zeile 374 Zeichen 192 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&picsize“
    Zeile 374 Zeichen 202 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&layout“
    Zeile 440 Zeichen 245 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&java“
    Zeile 440 Zeichen 252 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&security“
    Zeile 440 Zeichen 270 – Warnung: Unmaskiertes „&“ oder unbekanntes Element „&invisible“
    Zeile 440 Zeichen 179 – Warnung: XHTML-Element <img> nicht geschlossen
    Zeile 372 Zeichen 1 – Warnung: Element <a> hat proprietäres Attribut „titel“
    Zeile 254 Zeichen 3 – Warnung: Leeres Element <p> anpassen/löschen
    Zeile 291 Zeichen 1 – Warnung: Leeres Element <li> anpassen/löschen

    0 Fehler / 17 Warnungen

  • Die ganze Diskussion über Probleme mit WordPress sind ja schön und gut. Aber solange nicht mal jemand Logfiles schickt, aus denen ersichtlich ist wie der Hack stattgefunden hat, solange kann man nicht wirklich viel zu dem Thema sagen als das was man immer tun solle wenn man PHP Anwendungen am start hat.

  • Naja, alles kann und wird ja irgendwie mal gehackt. Und bei der Anzahl an WordPress-Blogs ist es auch kein Wunder dass es WordPress so häufig trifft. Mir ist das relativ schnuppe, Hauptsache ist erstmal dass ich durch so einen Hack nicht viel verlieren. Darum mach ich täglich automatisch ein Backup.

  • ich beobachte das gerade „hautnah“ bei einer alten Kundenseite: älteres WordPress, keine plugins, und *zack* gerade hat sich ein User mit gmail-Adresse registriert – obwohl die User-registrierung im backend garnicht freigegeben ist.

    Benutzername: Anthony
    E-Mail: Anthony21@gmail.com

    anscheinend wird dort angesetzt. wenn die registrierung erfolgreich verläuft, stehen diesem neuen user natürlich tür und tor offen.
    Mal schauen, wie das weiter geht…

  • Ich bin ganz froh das ich nicht immer die neueste Version von WP verwende. Denn i.d.R. werden mehr neue Features eingebaut, und damit neue Schwachstellen, als Fehler behoben. Irgendwie ist es auch logisch, je mehr Funktionen vorhanden sind, je komplexer ein System ist, desto anfälliger wird es.
    Eigentlich müsste man sich zu den Anfängen zurück besinnen und die Anzahl an unnötigen Funktionen reduzieren. Wie oft importiert man z.B. Beiträge aus anderen Blogs? Muss diese Funktion tatsächlich als fest eingebaute Funktion vorhanden sein? Oder würde da nicht ein Plugin reichen welches man bei Bedarf verwendet? Gleiches gilt für Tagging. Nicht jeder taggt seine Artikel. Und und und.
    Eine WP-Version die alle zusätzlichen Funktionen über Plugins bereit stellt, ist auch deshalb sicherer, weil man so die Schwachstelle einkreisen kann. Man muss nur vergleichen welche Blogs betroffen sind und welche Plugins aktiv sind. Derzeit gleicht bereits die Suche nach der Schwachstelle der Suche nach der berühmten Nadel im Heuhaufen.

    BTW:
    SELECT id from wp_post WHERE content LIKE ‚%display:none%‘;
    Mit dieser MySQL-Abfrage werden alle Posts angezeigt die ein „display:none“ enthalten. Also eigentlich alle Posts, die versteckte Spamlinks enthalten. Weitere Abfragen kann man dann ggf. mit anderen Merkmalen ausführen. So wäre recht schnell ein Plugin umzusetzen welches auch in älteren Beiträgen (die, die nicht im Feedreader erscheinen) nach Spamlinks sucht.
    Ansonsten muss amn es halt per Hand inPHP-Myadmin machen.

  • Übrigens kann es auch durchaus helfen, ganz einfach die Dateinamen der Plugins bzw. deren Ordner ganz einfach umzubenennen und nicht die Standard-Namen zu verwenden. Aus einem Ordner „akismet“ wird dann z.B. der Name „0815_akismet“ etc. Die Plugins funktionieren in der Regel weiterhin problemlos (muss man natürlich ausprobieren) aber der durchschnittliche Hacker läuft mit seinen XSS-Versuchen ins Leere.

    Zumindest einen kleinen zusätzlichen Schutz dürfte dies bieten; wenn ich jedenfalls meine Logfiles und entsprechende Hack-Versuche darin so betrachte, werden meist stumpf irgendwelche Standard-URLs verwendet, egal, ob ich das Plugin installiert habe oder nicht.

    Solche Hackversuche habe ich übrigens bis vor kurzen in diesem Jahr fast täglich gezählt. Zusätzlich blocke ich seit einiger Zeit über .htaccess bestimmte Spam-Hoster oder immer wiederkehrende Bot-Abfragen, was solche Hackversuche und Kommentar-Spam deutlich reduziert hat. Es kommen allerdings natürlich immer neue dazu…

  • @Ralf

    Ich hab leztens einen Ordner auf meinem Webspace entdeckt den ich mit Sicherheit nicht angelegt habe.
    Zu finden waren dort html Dateien zu irgendwelchen Pokerseiten, Pornokram etc.
    Andere Sachen habe ich bisher nicht entdeckt und wollte deshalb gerade den Befehl von dir ausführen, bekomme aber einen Fehler mit der ID #1064. Was hab ich falsch gemacht?

    Grüße
    Denis

  • @Denis:
    der Befehl muss lauten: SELECT id from wp_posts WHERE content LIKE ‚%display:none%‘ – ein s an post dran.

    Und falls Du den Tabellen-Präfix beim installieren noch geändert hast, dann musst Du anstatt wp_posts halt xyz_posts nehmen – dann sollte es klappen.

  • Hackangriffe auf WordPress-Blogs…

    Derzeit scheint es ein Sicherheitsproblem auch in der neusten WordPress-Version zu geben, dass es erlaubt unbemerkt Spamlinks in Artikeln unterzubringen. Entsprechende Berichte finden sich hier, hier oder auch hier und hier.
    Der Spam sorgt zudem daf&#2…

  • @Andreas
    Das bekomm ich jetzt als Meldung.

    SELECT id
    FROM wp_posts
    WHERE content LIKE ‚%display:none%‘
    LIMIT 0 , 30

    MySQL meldet:

    #1054 – Unknown column ‚content‘ in ‚where clause‘

    Grüße
    der MySQL Noob Denis 😉

  • Sicherlich ist nichts sicher. Auch bei einem großen CMS wie Typo3 kann es passieren. Meistens werden einfach Passwörter genommen, was dann keine Kunst mehr ist.

  • In der Tat haben die Attacken rasant zugenommen. Die letzten Hacks in Mengen waren ja fast alles hacks über unsichere Plug Ins. So zum Beispiel related post Plug ins mit Sicherheitslücke oder Cookie Disclaimer.. Leider muss man einfach immer am Ball bleiben, aktualisieren und Plug Ins checken..