Unser täglich Spam

Aus dem Internet frisch auf den Tisch. Köstlich und aromatisch.


Aktuelle Angriffe auf WordPress-Blogs

Montag, 24. März 2008, 2:41 Uhr

Infectious Substance - In case of damage or leakage immediately notify public health authority!In den letzten Tagen entsteht immer häufiger der Eindruck, dass in den aktuellen Versionen des Blogsystemes WordPress ein schwerer Fehler vorliegen muss. Angesichts der offenbar sehr schweren Probleme wird von Bloggern schon öffentlich darüber nachgedacht, zu einer anderen Software zu wechseln, obwohl die Migration bestehender Inhalte auf ein neues System in der Regel kein Spaziergang ist. (Es sollen ja auch weiterhin alle alten Links funktionieren und Google soll auch fortan zu den richtigen Seiten führen – so segensreich Import-Skripten auch sein mögen, da ist eigentlich immer auch etwas Handarbeit nötig.) Nachdem inzwischen auch bekanntere Blogger das Problem thematisiert haben, hier auch einige Anmerkungen von mir, die vielleicht auch substanziell Neues zur Suche nach dem Problem beitragen können.

Wie tritt das Problem auf

Ein betroffener WordPress-Blogger stellt fest oder wird von Lesern darauf hingewiesen, dass seine älteren Beiträge durch typische Suchmaschinen-Spam versalzen wurden, also durch riesige Linklisten, die sich in erster Linie an Google und andere Bots richten.

Das entspricht dem bisherigen Blogmissbrauch der Spammer, wenn sie entsprechende Kommentare oder Trackbacks verfassten. Gegen diese Form der Spam gibt es vielfältige Abhilfe (zum Beispiel Akismet), die einem ungefähr 99 Prozent dieser Pest vom Halse hält.

Das qualitativ neue an der gegenwärtigen Spamwelle ist es, dass die Spam nicht mehr als Kommentar erscheint, sondern als Bearbeitung eines regulären Blogbeitrages. Wir haben es hier also nicht mehr „nur“ mit kriminellen und asozialen Spammern zu tun, sondern mit richtigen Crackern. (Ich lehne die Bezeichnung „Hacker“ für solche Barbaren ab, da sie inhaltlich falsch und eine Beleidigung für jeden Hacker ist.) Diesen Crackern ist es über eine zurzeit noch völlig unbekannte Lücke möglich, ältere Beiträge in einem Blog zu bearbeiten und mit Spam „anzureichern“, die dann als normaler Eintrag im Blog erscheint. Natürlich greift hier ein gewöhnlicher Spamschutz nicht, da die Texte des Blogbetreibers ja an sich über jeden Zweifel erhaben sind und deshalb vor der Veröffentlichung nicht überprüft werden.

Bislang habe ich nur von betroffenen WordPress-Blogs gelesen. Wenn es sich um ein Sicherheitsloch in WordPress handelt, denn ist dies das wohl schwerste Sicherheitsloch in der gesamten Geschichte dieser Software.

Wie man an den Datumsangaben sehen kann (im Screenshot ist es der 16. März, die verlinkten Blogeinträge sind vom 22. März), handelt es sich um eine ganz aktuelle Gefahr. Da die genauen Bedingungen eines solchen Angriffes zurzeit noch nicht bekannt sind, besteht die Möglichkeit, dass momentan jedes WordPress-Blog in eine Litfaßsäule für Spammer umgewandelt werden kann.

Oder anders gesagt: Niemand kann sich im Moment sicher vor diesem Angriff fühlen. Die „kleinen“ Blogs mit wenigen Zugriffen sind genau so bedroht wie die „großen“ mit einem riesigen Leserstamm. Die Zielrichtung des Angriffes sind nicht menschliche Leser, sondern es geht um die Manipulation der Ranking-Verfahren der großen Suchmaschinen; da ist dem Cracker jeder Link recht.

(Um diese Unsicherheit ein bisschen zu beheben, wäre es wünschenswert, dass wenigstens die Versionsnummern der betroffenen Blogs und die darin verbauten Plugins offen bekannt würden. Wenn es sich nicht um die ganz aktuellen Versionen handelt, sollten betroffene Blogger allerdings vorher ihr WordPress updaten, bevor solche Informationen an eine feindselige Welt gegeben werden.)

Angriffszenarien in meinen Blogs

Auch meine Blogs waren (nicht nur) in den letzten Tagen von Angriffsversuchen betroffen, ich weiß allerdings nicht, ob diese Versuche im Zusammenhang mit den aktuellen Cracks stehen. Dennoch möchte ich diese versuchten Angriffe hier kurz charakterisieren, damit ein Eindruck von der kriminellen Energie entsteht, die sich im Moment an gängigen Blogsystemen entfesselt und mit aller Gewalt Lücken reißen will.

IP-Adressen – Die IP-Adressen der angreifenden Rechner waren über die gesamte Welt verstreut. Es handelte sich durchweg um dynamisch vergebene IP-Adressen von Providern. Das bedeutet, dass diese Angriffe von gewöhnlichen Desktop-PCs ausgingen, die mit Hilfe von Malware übernommen wurden, alle diese PCs dürften Windows-Rechner sein, die von der Spam-Mafia mit Hilfe untergejubelter Trojaner übernommen wurden. Es ist nicht möglich, den Angriff zu vermeiden, indem bestimmte IP-Bereiche blockiert werden.

Leserregistrierungen – Obwohl das bei den meisten meiner Blogs nicht möglich ist, wurden mehrfach automatische Registrierungen von Lesern versucht. Die dazu verwendeten Mailadressen lagen allesamt bei Google Mail, was zeigt, dass die Spammer momentan leicht und automatisch an diese Adressen kommen können. Das könnte bedeuten, dass die von den Crackern ausgebeutete Lücke etwas mit einer Möglichkeit angemeldeter Benutzer zu tun hat, sich Rechte zu holen oder eine SQL-Injection auf das Blog loszulassen.

XMLRPC – Der letzte Bug in der xmlrpc.php von WordPress, der ausbeutbar war, liegt schon einige Zeit zurück. Offenbar vertrauen die Cracker dennoch darauf, dass noch eine größere Menge älterer WordPress-Installation in Benutzung sind und probieren deshalb auch ältere Lücken aus. Da es sich hier um einen HTTP-POST handelt, weiß ich aus den Logdateien nichts von den Daten, die transportiert werden sollten.

Wörterbuch-Attacken – Immer wieder kam es zu verteilten Login-Versuchen, die natürlich alle scheiterten. Gerade hier war die Häufung in den letzten Tagen sehr auffällig. Offenbar werden Passwörter aus einem Wörterbuch ausprobiert, bis dieser Angriff irgendwo einmal klappt. Da auch XMLRPC eine Anmeldung ermöglicht, kann es gut sein, dass die verteilte XMLRPC-Attacke ebenfalls in diese Kategorie fällt und in Wirklichkeit ein Versuch ist, die regulären Zugangsdaten des Blogs zu ermitteln.

Vertiefende Anmerkungen

Der Angriff auf die xmlrpc.php ermöglicht, wenn er erfolgreich ist, sogar das Hochladen von Dateien. Wer eine alte WordPress-Version mit dieser Lücke hat, sollte unbedingt einen Upgrade machen, wenn er seinen Webserver nicht in eine Malware-Schleuder der Spammafia umgestalten will.

Die Wörterbuchattacken sind sehr gefährlich. Wenn es einem Angreifer gelingt, sich an einem Blog als Administrator einzuloggen, steht ihm die gesamte Funktionalität des Blogs über eine leicht automatisierbare Schnittstelle (XMLRPC) zur Verfügung. Er kann mit leicht zu schreibenden, kleinen Programmen jeden Beitrag löschen oder bearbeiten und beliebige Dateien im Blog hochladen. Natürlich wäre das der größte denkbare Gewinn für die kriminellen Cracker, die sich gerade auszutoben scheinen.

Der Gefahr von Wörterbuchattacken muss in jedem Fall begegnet werden. Die erste und wichtigste Regel lautet dabei: Sichere Passwörter verwenden!

Ein sicheres Passwort findet sich nicht in einem Wörterbuch und enthält auch Ziffern, eingestreute Großbuchstaben und Sonderzeichen, sollte sich aber dennoch leicht merken lassen. Ein alter Trick ist die Verwendung von Anfangsbuchstaben eines leicht einprägsamen Satzes wie „Du solltest dein Passwort so wählen, dass es sicher ist“ – hieraus würde „DsdPswdesi“, wenn man jeweils den Anfangsbuchstaben des Wortes nimmt. Natürlich ist auch der zweite Buchstabe geeignet, natürlich kann man auch die Wortlänge nach jedem Buchstaben schreiben und vieles mehr. Dieser Trick ist nicht der Weisheit letzter Schluss, aber er ist viel besser als der Vorname der Freundin gefolgt von ihrem Alter. Und er ist natürlich auch viel besser als ein Passwort, das so schwer zu merken ist, dass man es sich irgendwo notieren muss.

(Eine kleine Anmerkung am Rande: Ich habe vor Jahren einmal in einem größeren Unternehmen die Passwörter der Mitarbeiter auf ihre Sicherheit untersuchen müssen. Es war sehr erstaunlich, dass damals etwa fünf Prozent der Mitarbeiter das Passwort „Passwort“ verwendet haben, und diese waren fast ausschließlich Mitarbeiter, die in der betrieblichen Hierarchie recht weit oben standen. Wer nach dem Lesen dieses Textes auf die Idee kommt, jetzt für sein Blog das Passwort „DsdPswdesi“ zu verwenden, darf sich bei mir eine kostenlose Ohrfeige abholen.)

Für relativ unsicher halte ich übrigens die Passwörter, die WordPress automatisch nach der Installation für den Benutzer „admin“ vergibt. Es handelt sich einfach nur um sechsstellige Sedezimalzahlen. Davon gibt es zwar gut 16,7 Millionen, was zunächst nach „viel“ klingt. Aber ich weiß nicht, ob diese Zahlen vielleicht leicht zu erraten sein könnten, da sie eine Abhängigkeit vom Zeitpunkt der Installation enthalten. (Ich werde mir in den nächsten Tagen den WordPress-Quelltext einmal anschauen, ich weiß es im Moment wirklich nicht.) Der Zeitpunkt der Installation ist einem Angreifer mit einer Genauigkeit von ein bis zwei Sekunden bekannt, wenn der ebenfalls automatisch erstellt erste Post „Hallo Welt“ im Blog erhalten bleibt; so dass hier leicht ein Problem liegen könnte – vor allem, wenn jemand diesen „ersten Post“ nicht löscht.

Was wahrscheinlich keinen Schutz bietet

Momentan wird an verschiedenen Stellen diskutiert, ob es sinnvoll ist, die Versionsnummer der WordPress-Installation nach außen zu verbergen. Ich kann dazu nur drei Dinge zur Aufklärung sagen und jedem die Benutzung seines Gehirnes empfehlen:

Security by obscurity hat noch nie funktioniert. Die Angriffe auf meine Blogs betreffen eine ganze Bandbreite verschiedener Versionen, und ich verberge meine Versionsnummern nicht. Allein deshalb glaube ich nicht, dass diese Information von den gegenwärtigen Crack-Skripten überhaupt ausgewertet wird. Es handelt sich nicht um einen Angriff pubertierender Jugendlicher, die ihre „Kreativität“ in destruktiven Attacken verwenden, um sich daran aufzubauen. Es handelt sich um einen Angriff der Spam-Mafia. Spam ist ein Milliardengeschäft, und da draußen sind zehntausende asoziale Zeitgenossen, die alles versuchen werden, um ein paar Link- und Malwareschleudern mehr in die Welt zu setzen.

Das Verbergen der Version ist schwierig; es reicht keineswegs aus, wenn man die entsprechende Meta-Angabe im Template löscht. Die Versionsnummer findet sich zum Beispiel auch in allen RSS-Feeds. Um sie dort (und vielleicht noch an anderen Stellen, die mir gerade nicht bewusst sind) sicher zu entfernen, ohne nach jedem Upgrade in die Quelltexte des Kernsystems einzugreifen, muss man sich eines Plugins bedienen, das diese Information löscht. Das ist allerdings ein Eingriff ins System, der zum Beispiel auch den Hinweis sabotiert, dass eine neue Version von WordPress verfügbar ist. Im Falle eines aktuen Sicherheitsproblemes kann das leicht bedeuten, dass man den Hinweis auf ein erforderliches Upgrade gar nicht mitbekommt, was unter Umständen viel schlimmere Löcher aufreißt. (Wer es dennoch machen will, sollte zumindest alle zwei Tage nachschauen, ob es eine neue WordPress-Version gibt und sich nicht in falscher Sicherheit wiegen.)

Wir wissen gar nicht, ob dieses Problem an eine bestimmte Version von WordPress gebunden ist oder ob es alle derzeit erhältlichen Versionen betrifft. Die externe Sichtbarkeit der Versionsnummer ist zwar ein gewisses Problem, aber es kann völlig unbedeutend für die gegenwärtigen Attacken sein.

Was etwas mehr Schutz bietet

Nun aber ein paar praktische Tipps, wie man mit geringem Aufwand etwas mehr Schutz für sein Blog erreichen kann.

Bekannte Lücken schließen – Wer noch eine Version mit einer anfälligen xmlrpc.php hat, sollte diese Lücke unbedingt und sofort schließen.

Installationsbenutzer löschen – Bei der Installation wird ein Account mit dem Login „admin“ angelegt, der volle administrative Rechte (auch über XMLRPC) hat. Hier ist einem Angreifer immerhin schon der Login-Name bekannt, auch weiß er, wie das Passwort aufgebaut ist. Ich empfehle jedem WordPress-Blogger dringend, diesen Account nur zu einem einzigen Zweck zu verwenden, nämlich, um damit einen anderen administrativen Account anzulegen. Danach mit dem anderen Account anmelden und den Benutzer „admin“ löschen. Wenn ich ein Cracker wäre, würde ich immer eine Attacke auf diesen „admin“-Benutzer versuchen, denn ich wüsste ja, dass er fast überall existiert.

Installationspost löschen – Bei der Installation erstellt WordPress ein „Posting“ mit dem Titel „Hallo Welt“ und einen „Kommentar“ zu diesem Posting. Dieses „Posting“ sollte immer gelöscht werden, da es die Information verfügbar macht, zu welchem Zeitpunkt die Installation vorgenommen wurde. Wenn diese Uhrzeit in einige Parameter einfließt, die besser privat bleiben sollten, haben Cracker nur durch diese Uhrzeit bereits einen wertvollen Hinweis für mögliche Angriffe erfahren. Außerdem ist der automatsch erstellte Text so schön nicht.

Keine Leserregistrierung – Wer es nicht aus irgendeinem Grund tun muss, sollte keine Registrierung von Lesern ermöglichen. Ein registrierter Leser hat die Möglichkeit, sich am Blog anzumelden und im Admin-Bereich herumzuklicken, er hat damit schon eine Hürde überwunden, die einem potenziellen Cracker im Wege stehen sollte. Die Möglichkeit zum Login ist ein Privileg, sie sollte niemals leichtfertig gewährt werden. Schon gar nicht. Jedem.

Der Login ist kein Anzeigename – Bei WordPress kann man einen Anzeigename (zum Beispiel für den Autor der Blogeinträge) verwenden, der frei gewählt ist. Es macht Angreifern das Leben leichter, wenn der Login-Name offen sichtbar angezeigt wird, sie müssen dann nur noch das Passwort rauskriegen. Wer besonders sicher sein will, wählt seinen Login-Namen ähnlich kryptisch wie das zugehörige Passwort. Das macht eine Wörterbuch-Attacke sehr schwierig und gibt zusätzliche Sicherheit gegen diese Art von Angriffen. Wer einen „guten“ Login-Namen verwenden will, sollte sich darüber bewusst sein, dass sich zwar der Login-Name nicht ändern lässt, dass es aber sehr leicht möglich ist, einen neuen Benutzer anzulegen. Wenn der alte Benutzer gelöscht wird, fragt WordPress nach, an welchen Benutzer die Artikel übertragen werden sollen. Hier einfach den neuen auswählen, und es sollte keine Probleme geben.

Kein überflüssiges Plugin verwenden – Jedes Plugin ist Code, der innerhalb des Blogsystemes auf dem Server ausgeführt wird. Während das Kernsystem von WordPress noch von einer größeren Anzahl Menschen auf gewisse Probleme durchgesehen wird, ist die Sicherheit eines Plugins eher eine Glückssache. Wer den Quelltext nicht lesen kann, ist auf sein Vertrauen gegenüber dem Programmierer des Plugins zurückgeworfen. Ein ganz kurzer Tipp: Jedes Plugin, dass direkt auf die Datenbank zugreift, kann bei schäbiger Programmierung von einem Angreifer aus dem Internet dazu missbraucht werden, in der Datenbank und damit auch in den Bloginhalten herumzupfuschen. Solche direkten Zugriffe können im Quelltext an den SQL-Schlüsselwörtern SELECT, INSERT, UPDATE oder DELETE erkannt werden; und jeder Editor hat eine Suchfunktion. Natürlich braucht es viel mehr Kenntnisse, um eine angreifbare Programmierung zu erkennen, aber dieser einfache Tipp kann helfen, die meisten „harmlosen“ Plugins sicher daran zu erkennen, dass nicht direkt auf die Datenbank zugegriffen wird. Aber Vorsicht! Es gibt noch eine ganze Reihe weiterer Programmiertechniken, die in einer Webanwendung sehr gefährlich sind und die sich nicht so leicht erkennen lassen. Wer auf der sicheren Seite sein will, vermeidet jedes unnötige Plugin. (Nötig ist zum Beispiel ein guter und wirksamer Spamschutz, den sollte man auf keinen Fall vermeiden.)

Backups – Angesichts der Angriffe, die den Inhalt eines Blogs zerstören können, ist zurzeit nichts so wichtig wie eine tägliche Sicherung der Daten. Ob man hierzu einen Dump der Datenbank anlegt oder ob man sich der Export-Funktion von WordPress bedient, ist zweitrangig: Hauptsache, man kann ein von kriminellen Crackern zerstörtes Blog mit möglichst geringer Mühe wiederherstellen. Da die Zerstörung offenbar auch schleichend verlaufen kann, sollten die Backups zwei Monate aufgehoben werden. Wer kann, sollte den Vorgang der Backup-Erstellung automatisieren. Aber nicht, ohne sich regelmäßig zu überzeugen, dass der automatische Vorgang auch wie geplant abläuft. Wenn sich jemand im Katastrofenfall über sein Backup freut und einen Null Byte großen Datenbankdump vorfindet, ist das eine Situation, die auch der friedlichsten Seele wenig druckreife Worte entlockt.

Mit sauberem Rechner bloggen – Die besten Schutzmaßnahmen im Blog nützen nichts, wenn der Arbeitsrechner, an dem man bloggt, mit Malware verseucht und deshalb für kriminelle Cracker offen wie ein Scheunentor ist. Wenn Passwörter aller Art mitgeloggt und unauffällig im Hintergrund an die Spam-Mafia versendet werden, denn kann man genau so gut jedem Verbrecher dieser Welt volle Schreibrechte in seiner persönlichen Website geben. Wer völlig sicher gehen will, verwendet zum Bloggen ein Betriebssystem, das nicht anfällig ist. Alle Programme zum „Virenschutz“ taugen nicht viel, da sie den aktuellen Schadprogrammen um einige Tage hinterherhinken – und schon ein einziger Tag mit mitgelesenen Passwörtern vom eigenen Blog, von Mailkonto, vom eBay-Account und anderen Webdiensten kann großen Schaden anrichten und einem richtig die gute Laune versauen. Tatsächlich können Programme zum „Virenschutz“ sogar gefährlich sein, da sie ihre Anwender in falsche Sicherheit wiegen. Die Tatsache, dass die meisten Angriffe auf Windows-Rechner ausgerichtet sind, sollte jeden darüber nachdenken lassen, ob Windows ein gutes System zur Nutzung empfindlicher Webdienste ist. Im jedem Fall ist ein Knoppix schnell von CD gebootet (dieses Medium verhindert auch die Manipulation des Betriebssystemes durch Kriminelle) und schon ein deutlicher Zugewinn an Sicherheit.

WordPress und die Sicherheit

Am letzten Punkt wird schon deutlich, dass es noch nicht einmal sicher ist, dass wir es bei den gegenwärtig erfolgreichen Attacken mit einem Problem in WordPress zu tun haben. Letztlich kann ein gecracktes Blog viele Ursachen haben.

Dass sich die Aufmerksamkeit dennoch vor allem auf WordPress als mögliche Ursache richtet, hat seine Ursache in den vielen Unstimmigkeiten dieses Blogsystemes, die WordPress immer wieder auf wenig vorteilhafte Weise ins Gerede bringen. Man kann schnell auf die Idee kommen, dass in der gegenwärtigen WordPress-Entwicklung völlig falsche Schwerpunkte gesetzt werden.

Die größte Stärke von WordPress, die konsistente und leicht verständliche Benutzerführung, wird ohne Not aufgegeben. Zudem wurden gerade in letzter Zeit immer wieder Versionen herausgegeben, die sogar ärgerliche Fehler bei den Grundfunktionen hatten (etwa beim Versenden administrativer Mails oder im Editor für Beiträge), was denn für die Version 2.3 auch noch um ein „Feature“ ergänzt wurde, welches ein völlig unnötiges Datenschutzproblem in WordPress einführte. Zu allem Überfluss haben sich die WordPress-Entwickler freiwillig unter einen unangemessenen Zeit- und Projektdruck gesetzt, anstatt dass sie einfach dann die neue Version veröffentlichen, wenn sie fertig ist. Unter Zeitdruck und dem damit verbundenen Stress hat noch niemals ein Mensch bessere Arbeit geleistet. Immerhin wird jetzt auch bei WordPress „endlich“ der „Standard“ befolgt, dass Termine nicht eingehalten werden können. Als ob. Man keine anderen Probleme hätte.

Als wenn das alles noch nicht schlimm genug wäre, hat WordPress auch eine gewisse Sicherheits-Geschichte; es gab immer wieder schwere Lücken. Diese hatten übrigens fast alle ihre Ursache in einer frühen Entscheidung zum Thema, wie man auf die Datenbank zugreifen will. Die Filterung von Benutzereingaben (und solche kann bei einer Webanwendung jeder Mensch im Internet machen) wird nicht zentral an einer Stelle vorgenommen, sondern stets jeweils dort im Code, wo die Eingaben verarbeitet werden – dabei wurden auch immer wieder einmal schwere Fehler verbaut. Oft wird davon gesprochen, dass WordPress bereits in seinem Design (solche Entscheidungen bei Software werden als „Design“ bezeichnet) unsicher sei.

Da ist es gar kein Wunder, dass sich der Verdacht auf eine Schwäche in WordPress richtet, wenn etliche WordPress-Blogs von Spammern gecrackt und zu Litfaßsäulen für kriminelle Angebote gemacht werden:

Da scheinen etliche WP-Versionen von diesen Hacks betroffen zu sein, es wird Zeit das sich das mal jemand näher anschaut. Langsam wird es nämlich unheimlich.

Inzwischen ist der Ruf von WordPress derart ramponiert, dass vereinzelt sogar Blogs völlig aufgegeben werden, wie etwa fridaynite.de:

Für gestern war ja der verschobene Termin für WordPress 2.5 angekündigt. Geschehen ist nichts. Ich hab mich vorhin allerdings gerade mal im Bugtracking System umgesehen. Da sind noch 3-400 Bugs zu finden. Ich frage mich jetzt natürlich:

Warum gibt es bei einer Software, die seit 5 Jahren entwickelt wird noch immer so viele Schwachstellen? Muss man immer auf Teufel komm raus neue Features, egal ob sinnvoll oder nicht, mit Gewalt irgendwo einbauen? Wäre es nicht wirklich sinnvoll, die Software einfach nur mal SICHER zu machen?

Warum ich das schreibe? Weil mir vor 3 Tagen ein kompletter Server gehackt wurde über ein Leck in einer WordPressinstallation. […]

Mein Entschluss steht jetzt fest: Dieser Blog wird zu gemacht.

Die Leute, die im Moment die strategischen Entscheidungen für die weitere Entwicklung von WordPress treffen und die von allen guten Geistern verlassen zu sein scheinen, sollten sich vielleicht wieder auf das besinnen, was WordPress einst stark und so überaus beliebt gemacht hat: Eine klare Benutzerführung, ein relativ minimales Grundsystem und eine einigermaßen ausgereifte Software, die für Menschen geeignet ist, die „einfach nur bloggen“ wollen. Denn ein Blog ist etwas für Menschen, es ist kein technischer Selbstzweck. Alles, was über diesen Kern hinaus geht, gehört meines Erachtens in Plugins.

Wer zu den gar nicht so wenigen Menschen gehört, die schon einmal nach einem Upgrade eine zerstörte Datenbank und deshalb einen Haufen Arbeit mit gleichermaßen aufgeblähter wie unreifer Software hatten, der weiß, dass diese Zeiten vorbei sind.

27 Kommentare für Aktuelle Angriffe auf WordPress-Blogs

  1. Ralf sagt:

    Langer Artikel, kann man viel zu sagen. Ich versuche mich mal kurz zu fassen.

    Das Verbergen der Versionsnummer ist im Moment eher zu empfehlen als davon abzuraten. Schaden kann es nicht, dafür gibt es mittlerweile gute Plugins die die Versionsnummer nur ausfiltern anstatt in den Core-Dateien rumwurschteln (z.B. von Frank Bültge)
    Damit macht man sein Blog nicht direkt sicherer, aber man erschwert den Crackern das cracken ein wenig. Und warum ihnen nicht die Arbeit so schwer wie möglich machen.

    Zugriffe begrenzen: Doch, es macht Sinn einige IP-Bereiche auszuschließen. Ich habe z.B. den kompletten Asia-Pacific-Bereich ausgeschlossen und zusätzlich noch die IPs aus Afrika. Der Grund ist ganz einfach: Dies sind Länder aus denen hauptsächlich Spam und Hack-Angriffe kommen. Ich habe jedoch weder asiatische noch afrikanische Leser. Wenn ich etwas mehr Zeit hätte, würde ich wahrscheinlich auch noch die USA blockieren. Dazu müsste ich dann aber viele IPs (z.B. Google, MSN, Yahoo, Technorati) von Hand frei schalten. Weiterhin werde ich demnächst die Russischen und Südamerikanischen IPs blockieren.
    Meine Leser kommen zu 99,5% aus Deutschland, deswegen kann ich auf Zugriffe aus den Asiatischen Räumen getrost pfeifen. Bisher spürbarer Effekt: Die Spam-Attacken sind zu 80% zurück gegangen, derzeit trudeln ca. 0,5 Spams täglich ein. Wenn denn überhaupt.

    Brute Force blocken: Ich habe mir ein kleines PHP-Script geschrieben welches IP-Adressen blockiert die zu viele Zugriffe in zu kurzer Zeit auslösen. Brute Force Attacken werden damit nicht verhindert, aber erheblich erschwert. Wer derzeit mehr als 10 mal in 3 Sekunden auf mein Blog zugreift, fliegt raus. Für einen ordentlichen Brute Force Angriff müsste der Angreifer also sehr viele IP-Adressen und recht viel Zeit mitbringen.
    In wie weit es da schon Plugins für WP oder andere Lösungen gibt, weiß ich nicht. Ich denke aber mal das es das bereits gibt.

    Der Admin sollte nicht mit der Benutzer-ID 1 oder 2 unterwegs sein. Der Benutzername ist manchmal unwichtig wenn die Benutzer über eine ID identifizierbar sind. In wie weit WP davon betroffen ist, kann ich nicht sagen. Aber wenn es einen Hack gibt der die Benutzer-ID verwendet, ist es leicht 1 oder 2 zu versuchen um an die Admin-Daten ran zu kommen.
    Besser als den Admin zu löschen ist es die Daten direkt in der DB (phpMyAdmin) zu ändern. Login-Name ändern und Benutzer-ID auf einen zweistelligen Wert setzen.

    WP-Updates: Benutze nur die WP-Version die du auch wirklich benötigst. So wie du schon geschrieben hast, sollte man sich nicht ständig auf die neueste Version stürzen. „Never touch a running system“ ist der beste Schutz um nicht unfreiwillig zum Beta-Tester zu werden. Wer ein gutes Tagging-Plugin hat, braucht keine neue WP-Version die das Tagging nun eingebaut hat. das ist Mummpitz.

    Geklaute Cookies: Ich beschäftige mich jetzt seit zwei Tagen mit den Iframes und wie man sie in das Backend rein bekommt. Einen Weg habe ich schon gefunden (über ein Statistik-Plugin), ich denke es gibt da noch mehr Wege. Liest man ein wenig im Netz, dann findet man ausreichend Quellen in denen beschrieben ist das über ein Iframe eine XSS-Attacke ausgeführt und Cookies geklaut werden können. Wie diese XSS-Attacke aussehen soll, weiß ich nicht. Bei mir hat das (noch) nicht geklappt.
    Ich denke aber das es eher an meinem Browser liegt das ich mir das Cookie noch nicht klauen konnte. Veraltete Browser sind eine weitere Schwachstelle, könne über eingeschleuste Iframes schließlich Sicherheitslücken im Browser ausgenutzt werden.

    So, das waren jetzt nur mal ein paar Gedanken zu deinem Artikel. Ansonsten netter Artikel den sich jeder gerne mal zu Gemüte führen kann.

  2. […] Diskussion mit guten Ansätzen (Kommentare) dazu. Ebenfalls lesenswert ist der Artikel Aktuelle Angriffe auf WordPress Blogs bei […]

  3. Das Plugin von Bueltge kannte ich noch nicht. Dafür jetzt aber hier den Link auf die Download-Seite, natürlich auch von mir ohne Gewähr. (Ich habe es noch nicht getestet.)

  4. […] Thinking, PHP Performance, Tom’s Diner und Webrocker). Über Webrocker bin ich auf einen sehr lesenswerten Artikel auf spam.tamagothi.de […]

  5. […] nach vielen abschieden aus der blogosphere jetzt: über die ganze wordpress crackerei und die spammafia hier ein lesenswerter artikel. […]

  6. […] 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 […]

  7. Dave sagt:

    Inzwischen gibt es einen entsprechenden Thread im WP-Forum: Gemeinsamkeiten zwischen geknackten WP-Blogs.

  8. Martin sagt:

    Danke erstmal für eure Tips.

    @Ralf – an welchen Stellen muß ich die Benutzer-ID denn ändern? Habe sie aus Unkenntnis erstmal nur bei dem Benutzer geändert (zeitgleich mit dem Login-Namen), aber bei der nächsten Anmeldung (die grundsätzlich mit dem geänderten Login-Namen klappt) meldete WordPress, ich hätte nicht die Rechte für die Seite (also der Admin-Bereich).
    Ändere ich die ID zurück, klappt es wieder. Irgendwo muß diese also noch stehen. Besten Dank für Tips!

  9. Frank sagt:

    Einige Hinweise zum Erschweren des Hackens habe ich in einem Artikel zusammen gefasst, das Ändern der ID sollte man am besten über die DB direkt machen, sonst legt man Unmengen Daten an, nur um die ID hochzuzählen.
    Das Plugin zum Verschleiern der WP-Version habe ich mittlerweile in einigen Installationen laufen und mir ist die Version in der Ausgabe so nicht mehr untergekommen. Ob es hilft, dazu möchte ich eher wenig sagen. Einige Hacker behaupten, dass man WP immer hacken kann, wenn man will. Allerdings kenne ich noch einige Leute aus „alten“ Zeiten und die knacken auch schnell jede andere Anwendung. Ob nun eine andere Plattform sicherer ist, dass ist also damit nicht bewiesen. Aber die Popularität von WP sorgt zumindest dafür, dass einige Hacker darauf aufmerksam werden.

  10. […] den letzten Tagen mehren sich die Meldungen von gehackten WordPress Blogs und wenn selbst Robert Basic darüber schreibt, dann muss Matthäus […]

  11. […] zum dem Thema: spam.tamagothi.de & neun12.de & forum.wordpress-deutschland.org & talkpress.de : Spam im Ordner […]

  12. Zu Martin: Achtung, ich sage das jetzt auf dem Gedächtnis, es kann falsch sein. Ein Blick in die Datenbank hilft.

    Es gibt nicht nur die Tabelle wp_users mit den grundlegenden Daten des Users, sondern darüber hinaus auch eine Tabelle wp_usermeta, die weitere Profildaten und die Berechtigungen enthält. Wenn man zum Beispiel dem Admin-User kurzerhand eine neue ID gibt…

    UPDATE wp_users SET ID=37113 WHERE ID=1

    …denn muss man die zusätzlichen Angaben aus wp_usermeta ebenfalls mit der neuen ID ausstatten:

    UPDATE wp_usermeta SET user_id=37113 WHERE user_id=1

    Anstelle von wp_ bitte das gewählte Datenbankpräfix für das Blog setzen. Wenn ich die Namen der Tabellen und Spalten jetzt richtig im Kopf habe, sollte das alles auf Anhieb klappen. Ich kann es leider nicht überprüfen, da ich für die WP-Datenbank ein derart sicheres Passwort benutze, dass ich es nicht im Kopf habe. Aber mein Gedächtnis für Datenbankschemata ist an sich gut… 😉

    Ach ja, bitte eine andere Zahl als ID nehmen, nicht ausgerechnet meine hier…

  13. Frank sagt:

    Es ist richtig, es müssen beide Tabellen geändert werden, sonst gibt es keinen Zugriff mehr auf das Backend von WP.
    Habe es auch im oben genannten Artikel erklärt.

  14. Frank sagt:

    Um die Registrierung auch weiterhin zu erlauben, hilft eventuell das Plugin Confirm User Registration

  15. Frank sagt:

    Edit, die beiden Tabellen genügen nicht, dann kommt es zu Problemen bei der Verwaltung und bei Artikeln mit Code. Ebenso muss _links und _posts geändert werden.

  16. […] den letzten Tagen wird ja wieder einmal viel über die Sicherheit bzw. Unsicherheit von WordPress gesprochen. In erster Linie wird WordPress beschimpft wie schlecht und unsicher es doch ist. Das […]

  17. blogfeuer sagt:

    Guter Beitrag, der mir sehr gefallen hat und zum denken anregt. Auch ich halte gar wenig davon, die WP Version zu verschleiern. Trojaner interessiert es doch auch nciht wirklich, ob ich Windows XPSP2 , 1 oder keins drauf hab….

    Halte dein WP von unnötigen Plugins frei. Update regelmässig auf Sicherheitsupdates – NICHT auf neue Versionen.

  18. Robert sagt:

    Ich denke, man muss grundsätzlich zwei Angriffe unterscheiden.
    Erstens der automatisiert, massenhafte Versuch lückenhafte Systeme zu finden. Gegen diese sollte man die gängisten Lücken blockieren.
    Zweitens gezielte direkte Angriffe. Hier dürfte es ziemlich schwer werden, aufgrund der Funktionsvielfalt zu bestehen. Im Ergebnis am sichersten dürfte das Blog ohne Plugins kurz nach dem Update sein. Aber nach dem Update ist bei WordPress ja oft vor dem Update.

  19. Zu Frank: Da hast du recht und ich habe gepennt. Aber so etwas zeigt auch, dass man Eingriffe in eine Datenbank nur vornehmen sollte, wenn es nicht anders geht und wenn man genau weiß, was man da tut. Denn selbst jemand, der sich ein bisschen im WP-Code auskennt, kann schnell etwas übersehen.

    Danke für die Korrektur.

  20. Frank sagt:

    Habe das Plugin Search & Replace erweitert, im Zuge dieser Änderungen kann man damit einfach uns schnell die ID und den Zugang ändern.

  21. […] jüngsten Cracker-Angriffe auf WordPress gehen in die zweite Runde. Dies ist nicht einfach nur ein Hinweis, sondern ein aktueller und […]

  22. […] * Aktuelle Angriffe auf WordPress-Blogs […]

  23. […] den letzten Tagen wird ja wieder einmal viel über die Sicherheit bzw. Unsicherheit von WordPress gesprochen. In erster Linie wird WordPress beschimpft wie schlecht und unsicher es doch ist. Das […]

  24. […] Liste hier in den Kommentaren noch erweitert! Sehr zu empfehlen ist auch der Beitrag von Frank in Unser täglich Spam. Schreibe einen […]

  25. […] Quick Tipps zur Sicherheit Blogtopf.de: Blogs wurden gehackt und missbraucht Spam.tamagothi.de: Aktuelle Angriffe auf WordPress Blogs Webbrocker.de: WordPress […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert