Sonstiges

Blog hacked

und das nächste Blog (WordPress), das es erwischt hat. Wie immer scheint es um das Platzieren von Spamlinks zu gehen. Was ist eigentlich mit den vielen Blogs, die stillgelegt sind, wo also der Admin nicht mehr reinschaut? Wir bekommen ja immer nur die mit, die man noch aktiv betreibt bzw. die man aktiv mitliest.

Ob man Automattic ansprechen sollte, um bspw. dann das Logfile zwecks Analyse zuschicken zu können oder bringt das nüscht, weil a.) zu aufwendig und b.) nicht erfolgversprechend? Würde mich interessiern, ob man mehr auf WordPress basierende Lücken nutzt oder sind das eventuell eher MySQL/Apache Sicherheitslücken, auf die sich die Spamhacker stürzen?

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

28 Kommentare

  • Keine Software ist (Sicherheits-)Fehlerfrei. Aber Apache und Mysql legen schon seit langer Zeit besonderen Wert auf stabilen und sicheren Code.

    Von WordPress (und dessen diversen Plugins) kann ich das so pauschal nicht sagen. Vor gut eineinhalb Jahren, als ich mir damals WordPress und dessen Quellcode etwas genauer anschaute, habe ich danach für mich die Entscheidung getroffen, aus Sicherheitsgründen von WordPress die Finger zu lassen.

    Unabhängig von der Softwarequalität dürfte es auch daran liegen, dass gerade WordPress durch seine einfache Bedienbarkeit bei IT-Laien beliebt ist, und diese Personen aber mit Softwareupdates oftmals überfordert sind, falls sie deren Notwendigkeit denn überhaupt erkennen, und so auch in der Software schon behobene Sicherheitslücken in vielen Blogs immer noch vorhanden sind.

  • Die meisten Angriffe oder auch Spam sind automatisiert. Ich kann nur immer wieder sagen, enfernt die Zeile
    meta name=“generator“ content=“WordPress …php bloginfo(‚version‘); …“
    aus dem Header.
    Mein Blog ist ca 1 Jahr alt und ich habe bis jetzt nur 139 Spamkommentare, von manuellen Versuchen mal abgesehen.

  • Also in Apache gabs schon länger keine kritischen Sicherheitslücken mehr. Stand zumindest letztens auf Heise. Hauptproblem dürfte WordPress selbst sein. WP selbst ist ja dafür bekannt, dass öfters mal Probleme mit SQL-Injections entdeckt werden. Außerdem kanns beim Update ja schnell mal zu Problemen kommen, wenn man eigene Anpassungen am Blog gemacht hat. Viele haben dann nicht mehr so wirklich die Lust ein Update zu machen. Und dann ists schnell mal passiert. Durch die Verbreitung von WP lohnt sichs dann für Spammer eben auch automatisierte Skripte einfach mal pauschal über alle WordPress-Blogs laufen zu lassen, die man über Google finden kann.

    Ähnlich nervig aus Sicht des Administrators war phpBB2. Nachdem ich ein paar Jahre ein solches Forum administriert hatte und mir die ständigen Updates auf die Nerven gingen, habe ich mich bei meinem eigenen Blog dann für Serendipity entschieden. Die Sicherheits-History sieht wesentlich besser aus als die von WP und ein Update ging bisher auch immer durch simples Überschreiben der alten Installation. Bereits installierte Plugins liefen bisher auch danach noch wie gewohnt.

  • Irgendwas ist da aber zugange.
    Bei den von mir betreuten Blogs habe ich sei dem 10. März einen signifikanten Anstieg im Zugriff auf die comment.php
    Top Seitenurl Besucher Größe Einstieg Ausstieg
    /comment.php 66426 92 Bytes 51527 50992

    Es schlagen aber keine Spamkommentare auf.
    Ich arbeite übrigens mit Serendipity

  • Soll nicht sogar in der aktuellen WordPress Version eine Lücke sein?
    Ein weiteres Problem könnte sein das viele WordPress updaten, indem die neue Version einfach über die alte Installation kopiert wird. Dadurch bleiben allerdings alte, nicht mehr verwendete, php-Dateien auf dem Server die dann wieder zum hacken genutzt werden können.

  • Micha’s Vorschlag mit entfernen der loginfo/version ist schon mal ein Anfang. WP läßt sich aber dennoch recht einfach identifizieren.

    Die meisten „hacks“ dürften auf Software Lücken basieren. Die Ausnutzung von MySQL/Apache Sicherheitslücken dürfte nur ein sehr geringer Teil ausmachen. Gerade bei „nicht mehr genutzten Blogs“ handelt es sich doch in der Regel um Webspace Pakete bei denen der Server weiterhin von dem Provider gepflegt wird.

  • @Micha und M.:
    Die Version von Michas Blog ist 2.xxx – ich weiß sie genauer, sage hier aber nicht mehr.

    Man muss schon die Variablen zur Versionsangabe überall entfernen, also auch in allen vier Feed-Quelldateien, die WordPress zur Generierung der Feeds verwendet. Ich vermute sogar, dass „böse“ Bots die WP-Versionen eher über Feed-Aggregatoren auslesen als über den HTML-Header der Startseite.

    Aber bei WP-Updates muss man diese Dateien natürlich jedes Mal wieder neu anpassen.

    Es gibt aber ein Plugin, mit dem man die Feed-Version mit einer Zufallszahl verschleiern kann, ohne, dass die Update-Meldefunktion beeinträchtigt wird.

  • @Micha, M, Boris: Was soll das bringen? Ein solcher Exploit wird durch HTTP-Anfragen auf bestimmte Skripte ausgeführt. Nichts hält einen Bot davon ab, einfach alle seine Exploits auszuprobieren, ohne überhaupt die Versionsnummer des Blogs zu checken. Genau genommen muss er nicht mal prüfen, ob ihr überhaupt WordPress einsetzt, sondern könnte einfach alle seine Blog-Exploints ausprobieren.

    Außerdem bekommt ihr damit ein falsches Sicherheitsgefühl. Ich selbst mache auch nicht gerne Updates und bin sogar froh, dass jeder die Versionsnummer meiner Software ganz einfach herausfinden kann, da mich das immer wieder zum zeitnahen Updaten motiviert. Und letztlich sind die Sicherheitsupdates das einzige, das euere Blogs wirklich schützen kann.

  • @ahe: solche Typen sind äußerst effizient und verballern nicht ihre Zeit und Ressourcen, um auf vielleicht statischen Seiten alle Exploits auszuprobieren.
    Die gucken schon genau, was sie sich vornehmen wollen.
    Auch habe ich dadurch kein falsches Sicherheitsgefühl, aber ein bischen hilft es doch.

  • Zu Micha (13): Ich bin mir manchmal gar nicht so sicher, dass die so genau nachschauen. Die letzten Angriffsversuche auf meine WP-Installationen, die ich erlebt habe, die habe ich zunächst für dDoS-Attacken gehalten. (Alter der jetzt beschriebenen Angriffe: so ein bis zwei Wochen.)

    Die IP-Adressen waren fröhlich über die Weltgeschichte verstreut, wohl lauter zombifizierte Windows-Rechner, die den Spammern ja auch ganz andere Dienste leisten. Es gab folgende Vorgehensweisen:

    Versuch, massenhaft „Leser“ zu registrieren
    Dies geschah unabhängig davon, ob die Registrierung eines Lesers möglich war oder nicht. Alle Mailadressen waren bei gmail, da scheinen die Cracker also gerade so richtig gut dranzukommen – früher war es noch Yahoo. Offenbar hat der momentane Angriff etwas mit einer falschen Prüfung der Rechte angemeldeter Benutzer zu tun.

    Obskure Aufrufe der xmlrpc.php
    Der letzte Bug, der dort gefixt wurde, ist schon recht lange her. Aber offenbar vertrauen die Cracker darauf, dass nicht jeder Blog aktuell ist und probieren fröhlich auch uralte Lücken aus. Da es sich um HTTP-POST handelt, weiß ich nichts über die Daten, die untergejubelt werden sollten.

    Verteilte Wörterbuch-Attacken auf die Passwörter
    Immer wieder kam es zu Login-Versuchen. Ebenfalls HTTP-POST, daher weiß ich nichts von den Daten. Aber die Häufung war schon sehr auffällig…

    Schlussfolgerungen:

    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 Rechner nicht zu einer Schleuder für die Malware der Spam-Mafia machen will. Es gab für die fragliche WordPress-Version sogar eine korrigierte xmlrpc.php irgendwo (Google hilft), falls ein Upgrade des gesamten WordPress aus dem einen oder anderen Grund nicht in Frage kommt.

    Die Wörterbuchattacken sind gefährlich. Man kann ihnen nur durch sichere Passwörter begegnen. Ob die sechstellige Sedezimalzahl für den initialien Admin-Account ausreichend ist? Ich glaube kaum, und ich weiß auch nicht, ob die aktuelle oder ob frühere Versionen hier eine gewisse Vorhersagbarkeit haben (zum Beispiel in Abhängigkeit von der Installationzeit, die man ja auch am ersten Standard-Post ablesen kann). Ich werde mir das in den nächsten Wochen einmal ganz genau anschauen.

    Das einfache Verbergen der Version hilft nicht. Gleichartige Angriffe gingen über verschiedene installierte Versionen, die von 2.0.x bis 2.3.3 reichten. Es sind dumme Skripten, mit denen da gecrackt wird.

    Empfehlungen:

    Unbedingt die xmlrpc.php-Lücke stopfen, wenn sie besteht!

    Den bei der Installation angelegten Account mit dem Benutzernamen „admin“ löschen! Vorher einen eigenen Adminaccount mit einem möglichst kryptischen Benutzernamen anlegen, der natürlich ein starkes Passwort kriegen muss! So muss bei der Wörterbuchattacke doppelt geraten werden, der Loginname und das Passwort — das erhöht die Schutzfunktion erheblich.

    Als Anzeigename nicht den Login-Namen verwenden! Sonst wird es doch ein bisschen einfach für Bruder Hackkopf…

    Übrigens hilft das alles nichts, wenn man auf seinem Arbeitsrechner bereits eine Malware laufen hat, die Passwörter aller Art mitloggt. Deshalb unbedingt zum Bloggen einen einigermaßen sauberen Rechner verwenden. Der beste Schutz in WordPress würde nichts helfen, wenn das Betriebssystem des Bloggers offen wie ein Scheunentor steht.

    Abschließendes:

    Ich selbst verberge nicht, welche WP-Version ich verwende, und ich habe Angriffsversuche auf meine Sites erlebt. Dennoch haben meine Sites diese Angriffe überstanden. Die einzigen Maßnahmen, die ich selbst getroffen habe (und zwar schon seit langem), sind die, die hich hier auch angegeben habe.

    Am meisten Sorgen mache ich mir persönlich um die paar Sites, die Benutzern eine Registrierung erlauben. (Ich kann es an diesen Stellen nicht vermeiden.) Man muss sich immer vor Augen halten, dass das Login-Privileg eben ein Privileg ist. Jemand, der bereits in das Dashboard kommt, hat eine wichtige Hürde überwunden und kann seiner Destruktivität auf ganze andere Weise freien Lauf lassen. Eine einzige Unsauberkeit an einer einzigen Stelle, ob es nun eine SQL-Injection (in WP immer gut möglich, auch und vor allem in einigen Plugins) oder eine unzureichende Rechteprüfung ist, und schon wird das Blog übernommen. (Am besten, indem zunächst ein zusätzlicher User mit vollen Privilegien erzeugt wird, das kriegt jeder 6jährige Nachwuchshäcker auf dem Pisspott hin. Denn wird mit diesem Admin bequem und mit guter Benutzerführung das Blog etwas umkonfiguriert, anschließend wird der User einfach wieder gelöscht. Wenn das in der Datenbank geschieht, kriegt der Betreiber des Blogs nicht einmal eine Mail über den neu registrieren User.)

    Ich hoffe, es macht etwas nachdenklich. Was wir brauchen, ist eine vernünftige Analyse dieses Problems, bis dahin kann auch ich nur im Nebel stochern.

  • @Micha (13): Kennst Du denn „solche Typen“?

    Tatsächlich kann ich es regelmässig beobachten, dass es bei einer neuen Website/Domain nicht lange dauert, um die URLs der üblichen Exploit-Versuche, und darunter besonders WordPress und phpBB, im Log zu erkennen. Selbstverständlich läuft beides nicht auf den betreffenden Websites.

    Wer also meint, aus Sicherheitsgründen die Version seines WordPress verschleiern zu wollen und meint, das würde ihn (oder sie) auch nur ansatzweise gegen Exploit/ Hackversuchen schützen, handelt naiv und sollte sich vielleicht mal mit dem Thema „Security thru Obscurity“ beschäftigen.

  • @ahe (#12):
    Es ist wohl ein falscher Eindruck durch den Fehlschluss entstanden, dass das durch die Versionsverschleierung (minimal) erhöhte Sicherheitsgefühl dazu führt, dass man sich Updates spart und sorgloser mit seinem Blog umgeht.

    Das ist in meinem Fall tatsächlich nicht so. Das wäre allerdings auch ziemlich gefährlich, nicht zuletzt aus den folgenden Erwägungen heraus:

    Da leider immer noch niemand (so weit ich Kenntnis habe), der viel mehr Ahnung als ich von PHP, vom Programmieren überhaupt und vom Hacken und Spammen im Speziellen hat, sich aufgemacht und sich mal so ein paar „böse“ Bots beschafft und genau angeschaut (und das Ganze en détail publiziert) hat, sind für mich alle vermeintlichen Erkenntnisse über das, was „böse“ Bots genau tun und wie sie es tun, reine Vermutung.

    Das gilt natürlich auch für die vermutete Arbeits-und Denkweise der Idioten hinter den Bots.

    Alles, was ich an Erkenntnissen habe, sind Rückschlüsse aus meinen Logdateien (Server und Blog) und ein paar berichtete Erkenntnisse von anderen. Dazu noch meine eigenen Spekulationen über Motivation, Fleiß oder Faulheit der s.o. dahinter.

    Und weil die Versionsnummer meines Blogs sowieso niemanden außer mich etwas angeht, und deren Verschleierung nicht schadet, kann ich sie auch verbergen.

    Natürlich darf das nicht zu trügerischem Sicherheitsgefühl führen, gar keine Frage …

  • Mir scheint, WordPress ist das neue Windows! Weit verbreitet, teils schlamping geschrieben. Viel Third Party Müll.

    Leute, sucht euch Alternativen.

  • Langsam wird’s aber echt etwas nervig, zumal man bisher sich wohl auf englische Blogs konzentriert hatte.
    Zudem beinhaltet die aktuelle (!) WP-Version etliche dokumentierte Lücken, daher dauert auch die neue Version länger als geplant.
    Im Grunde wird jetzt eben jeder vernünftige Blogger gezwungen sich darüber Gedanken zu machen und die Basics ( 😉 ) wie im Kommentar oben von Elias umzusetzen.
    Ansonsten noch ein Tipp für eher statische Seiten, die mehr als CMS denn Blog dienen (hat man ja auch nicht so im Blick): lokal aufsetzen, mit wget statisch abspeichern und per sftp hochladen. Mit Suche, Kommentieren und vielen Posts schauts da aber schlecht aus. Dafür sicher(er).
    Abschließend: ruhig von Zeit zu Zeit die ausgehenden Links prüfen (Spamer verlinken nicht auf normale Seiten, die fallen schnell auf).

  • Stimmt, ich habe im Template das: meta name=“€?generator“€? content=“€?WordPress entfernt und nun schon ein paar tage ruhe. Danke für diesen hilfreichen Tip.