Vorsicht vor dem Pharma-Hack
28. Februar 2011 eingestellt von Rechtsreferendar Jens Ferner (Diplom-Jurist, hier bei Google+ und XING)
Kurz-Links: http://www.ferner-alsdorf.de/?p=4087
Teilen: Auf XING | Auf Facebook | Bei Twitter
Für mich ist das durchaus interessant: Heute wird in einer unzähligen Masse Software wie WordPress eingesetzt. Sicherheitsprobleme sind aber kaum Thema, selten liest man z.B. etwas über Defacements. Dabei, wenn man sich das Changelog von WordPress so ansieht, gibt es ja durchaus genügend Angriffspunkte in jeder Version. Und wenn ich da an die “goldenen Zeiten” (1999 bis ca. 2004) denke, in denen PHPNuke noch das Maß aller Dinge war, bin ich schon überrascht. Vielleicht aber brodelt es unter der Oberfläche.
Der “Pharm-Hack” macht die Runde, zwei Betroffene haben sich bereits “geoutet” und es werden sicherlich mehr werden.
Das Interessante am Pharm-Hack ist, dass er nicht wirklich sichtbar arbeitet: Er zeigt sich nur bei Traffic-Lastigen Artikeln (wohl die, mit den höchsten Zugriffszahlen, WordPress zählt das intern mit) und auch dort nicht offensichtlich. Er verändert nur die Meta-Tags und den Title-Tag. Das fatale Ergebnis: Die Google-Darstellungen ausgerechnet der beliebtesten Artikel des eigenen Blogs sind, man kann es deutlich sagen, Schrott für die Tonne. Es droht, neben dem Downranking, ein erheblicher Image-Verlust.
Blicken wir auf die Technik, da gibt es inzwischen einige Hürden, die vor allem in der Bequemlichkeit heutiger Webmaster zu suchen ist. Als ich vor einigen Jahren Gebote für die Webseiten-Sicherheit publizierte (man findet sie heute noch hier und da im Netz, etwa hier eine Variante), stand eine Regel ganz oben: Niemals, wirklich niemals, allen Dateien Schreibrechte geben (CHMOD 666 / CHMOD 777). Mit Faszination habe ich im Siegeszug von WordPress unter den Blog-Systemen/CMS beobachtet, dass gerade diese Sicherheitsregel systematisch missachtet werden muss, wenn man das chice Update-System einsetzen möchte. Das Ergebnis nämlich: Wo überall Schreibrechte existieren, da kann ein Lückenhaftes Plugin, ja gar ein fehlerhaftes Theme, das gesamte System gefährden und abschiessen.
Was bedeutet das für’s Image? Ich möchte sagen: Es kommt drauf an. Peinlich kann es immer sein, wenn die Webseite “hässlich” aussieht, schädlich, wenn die eigene Anwaltsseite bei Google im Zusammenhang mit illegalen Pharmazeutika auftaucht. Wenn es aber nun einmal passiert ist (dazu sogleich), hilft das auch nicht weiter. Jedenfalls wer nicht IT-Sicherheitsprodukte anbietet, von dem wird man heute nicht erwarten dürfen, dass er jede Sicherheitslücke kennt und 100%ige Sicherheit bietet. Die gibt es ohnehin nicht. Die oben genannten und verlinkten zwei Beispiele habe ich bewusst aufgegriffen um zu zeigen: Die Offensive wird nicht bestraft. Es hilft, sich offen nach außen zu stellen, das Problem zu kommunizieren und andere zu warnen. Im Regelfall führt das zu positivem Feedback – anders als der Versuch, so zu tun, als wäre nichts gewesen.
Gerade wer zwar mit einem WordPress umgehen kann, aber über rudimentäre PHP/MySQL-Kenntnisse hinaus nichts zu bieten hat, steht auch vor dem Problem, dass er gar nicht in der Lage sein wird, Probleme selber zu erkennen und zu beseitigen. Dieser Anspruch wäre auch zu hoch, würde man ihn stellen, wäre es letztlich der breiten Masse unmöglich, ein entsprechendes System einzusetzen. Dazu kommt, dass Sicherheitslücken an verschiedenen Stellen lauern: Im WordPress-Code selber, in Plugins, Themes – ja gar die PHP-Software auf dem Server selber kann Lücken haben. Von MySQL ganz zu schweigen. Hier den Überblick zu behalten ist ein Job für sich – der ja eben auch ein eigener Job ist.
Wichtig ist mir an dieser Stelle, auf das grundsätzliche Risiko hinzuweisen und wieder ein Bewusstsein zu schaffen. Wer heute mit WordPress arbeitet, geniesst schon einen sehr hohen Luxus: Womit ich mich vor Jahren mit PHPNuke rumplagen musste, spottet heute jedweder Beschreibung. Insofern ist der WordPress-Coe durchaus solider aufgestellt und kein vergleich, auch wenn ich hin und wieder über Codestellen stolpere, an denen eine Sanitize-Funktion, zumindest ein intval(), nicht so ganz fehl am Platz wäre. Wer sich ein wenig mehr zutraut, sollte ohnehin immer den Markt im Blick haben, nicht nur für die Grande Dame der CMS (Typo3). Daneben existieren viele weitere Systeme, die Beachtung verdient haben. Gemeint ist nicht Joomla, was wohl von WordPress nahezu vollständig verdrängt ist, sondern auch Drupal, das bis heute ein vollkommen unberechtigtes Schattendasein führt. Das mag daran liegen, dass man zum Verständnis von Drupal zumindest fortgeschrittene OOP-Kenntnisse mitbringen muss.
Juristisch gibt es nicht viel zu sagen, die Urheber wird man faktisch nicht erwischen. Da ich nicht selbst betroffen bin, kann ich nur orkalen, dass selbst der, der in den Serverlogfiles den Angreifer identifizieren kann, nur auf eine IP-Adresse aus dem Raum des Nahen Ostens oder Osteuropas stösst. Die wird mit hoher Sicherheit zu einem dortigen Proxy führen, ab dann ist Schluss mit der “Spurensuche”. Ich spare mir an dieser Stelle somit langatmige Ausführungen, dass der (erfolgreiche) Hack natürlich Strafbar ist, u.a. wegen einer Datenveränderung. Interessant wäre die Frage, inwieweit man als gehackte Webseite für Werbung illegaler Pharmazeutika sogar noch in Anspruch genommen werden kann – was ich hier (noch) außen vor lasse. Letztlich sind juristische Analysen dort langweilig, wo am Ende kein Täter gefunden werden kann, insofern sehe ich keinen Sinn in weiteren Ausführungen dazu.
Was heisst das nun für Webmaster? Haltet eure Systeme im Blick und “sauber”. Tools wie der “Exploit-Scanner” für WordPress sind da ein guter Ansatz. Die höchste Sicherheit hat man bis heute wohl, indem man das System immer aktuell hält, keine Schreibrechte vergibt und somit Updateroutinen nur von Hand ausführt. Wer etwas gewiefter ist, kann darüber hinaus Maßnahmen andenken, ich habe etwa einen älteren Artikel hier im Blog mit einer Routine versehen, die prüft, ob der Artikel in der Ausgabe plötzlich unerwartete Wörter anzeigt. Falls ja, erreicht mich eine Mail – ob das beim Pharm-Hack ausreichen würde, kann bezweifelt werden, wenn nicht zumindest der Artikel vom “Pharm-Hack” als Traffic-Lastig eingestuft wird.
Wer sich nun konkret mit dem Pharm-Hack auseinandersetzen möchte: Einfach in wp-plugins/akismet einmal nachsehen, ob da Dateien existieren, in denen “.bak”, “.cache” oder “.old” vorkommen. Vorher dafür sorgen, dass versteckte Dateien im FTP-Programm auch angezeigt werden. Falls eine solche Datei existiert, müssen Alarmsignale angehen, sodann auf jeden Fall den unten verlinkten Artikel lesen. Wenn die Dateien nicht existieren ist das keine Garantie, aber man kann etwas beruhigter sein.
Details zur Technik:
- Pharm-Hack erkennen und entfernen (Englischsprachig!)
Unsere Facebook-Seite hat bereits 881 Fans - folgen auch Sie uns und bleiben Sie auf dem Laufenden!An dieser Stelle würden wir Ihnen gerne weitere Inhalte zeigen - dazu ist aber Ihre Einwilligung nötig, da u.a. Ihre IP-Adresse an externe Dienste wie Facebook und Twitter übermittelt wird. Wenn Sie das wünschen, klicken Sie bitte hier - Unsere Datenschutzerklärung
(Tags: abzocke, pharm-hack, php, sicherheit, wordpress)