WordPress-Websites mit Zwei-Faktor-Authentifizierung sichern

WordPress-Login mit Zwei-Faktor-Authentifizierung
WordPress-Login mit Zwei-Faktor-Authentifizierung

Was ist Zwei-Faktor-Authentifizierung?

Beim E-Banking ist es selbstverständlich, nicht allein auf Passwörter zu vertrauen: Dort muss man bei jedem Login einen nur einmal gültigen Code eingeben, den man entweder per SMS zugeschickt erhält, mit einer Smartphone App generiert, von einem RSA Key abliest oder (heute kaum noch verbreitet) einer Papier-Strichliste entnimmt. Alle diese Verfahren basieren auf dem Prinzip, dass man nicht nur das Passwort kennen muss, sondern auch noch ein physisches Objekt (ein Smartphone, einen Code-Generator, eine Liste) besitzen muss, um sich einloggen zu können.

Diese sogenannte Zwei-Faktor-Authentifizierung macht ein Login wesentlich sicherer, denn das Risiko, dass ein Unbefugter sowohl das Passwort in Erfahrung bringt als auch in den Besitz des physischen Objekts kommt, ist vergleichsweise gering. Und falls letzteres ein Smartphone ist, dann kann man es durch einen PIN noch zusätzlich absichern.

Read more…

WordPress: Pharma Hack eliminieren – zweiter Versuch

Vor einigen Wochen habe ich an dieser Stelle beschrieben, wie dieses Blog Opfer des sogenannten Pharma Hacks wurde. Leider zeigte sich kurz danach, wie raffiniert dieser Hack funktioniert – offensichtlich hatte ich nicht den gesamten Schadcode eliminiert, und so präsentierte sich mein Blog schon nach wenigen Tagen wieder folgendermassen in der Trefferliste von Google:

Open Mind Blog mit Phrama Hack

Das ist mehr als ein Schönheitsfehler: Der Traffic auf meinem Blog brach aufgrund des Pharma Hacks auf etwa die Hälfte ein. Diese Situation zwang mich, mich nochmals eingehender mit diesem Angriff und dessen Bekämpfung auseinanderzusetzen – hier die dabei gewonnenen Erkenntnisse, die ich primär dem Artikel “How to Diagnose and Remove the WordPress Pharma Hack” verdanke.

Was bewirkt der Pharma Hack?

Wie man im obigen Screenshot erkennen kann, wird das TITLE-Tag von Blog-Artikeln durch Werbung für verschiedenste Pharmazeutika ersetzt, deren Namen Sie von Spam-Mails bestens kennen dürften. Allerdings wird diese Werbung nur dann eingeschleust, wenn der Google-Spider auf das Blog zugreift, so dass der Hack nicht auffällt, solange ein menschlicher Besucher das Blog liest – nur in den Trefferliste von Google fällt der Hack auf.

Zusätzlich werden offenbar Links auf einschlägige Websites in die Blog Posts eingebaut. Ich selbst konnte zwar keinen solchen Link entdecken, aber wenn es sie nicht gäbe, würde der Hack keinen Sinn machen, weil der Hacker vom verunstalteten TITLE-Tag allein noch keinen Vorteil hat. Denn letztlich ist der Pharma Hack ein Parasit: Sein Ziel ist es nicht, das gehackte Blog zu schädigen, sondern ihm Links unterzujubeln und so Suchmaschinenoptimierung der übleren Sorte zu betreiben.

Wo versteckt sich der Pharma Hack?

Dass der Pharma Hack nur schwer zu entfernen ist liegt daran, dass sich der Schadcode in verschiedensten Dateien des Plugin-Verzeichnisses sowie in der Datenbank verteilt und auch einiges unternimmt, um unentdeckt zu bleiben – eine blosse Suche nach Entschlüsselungsfunktionen wie eval() oder base64_decode(), wie sie für Hacks typisch sind, führt deshalb nicht zum Ziel.

Wie wird man den Pharma Hack wieder los?

  1. Komplett-Backup von Datenbank und Dateisystem durchführen.
  2. Aktuellste WordPress-Version installieren. Dies löst zwar nicht das konkrete Problem, ist aber eine generelle Sicherheitsmassnahme für jede Web-Applikation, um zukünftigen Hacks vorzubeugen.
  3. Plugin-Verzeichnis von infizierten Dateien befreien. Dies ist leichter gesagt als getan, denn der Hack versteckt sich einigermassen zufällig in den verschiedensten Plugins in den verschiedensten (gelegentlich auch unsichtbaren) Dateien. Statt alle Plugin-Verzeichnisse nach verdächtigen Dateien durchzusehen (was sowohl zeitaufwändig als auch technisch anspruchsvoll ist) habe ich mich diesmal zu einer Radikalkur entschlossen: Ich habe den gesamten Plugin-Ordner per FTP gelöscht und anschliessend alle Plugins neu installiert. Am besten macht man vorher einen Screenshot des Plugin-Managers im WordPress-Backend, um den später zu wissen, welche Plugins installiert werden müssen.
    Das ist natürlich eine brachiale Methode und entsprechend nicht ganz unproblematisch. Je nach dem, welche Plugins man im Einsatz hat, ist das Blog nach diesem Eingriff mehr oder weniger verunstaltet oder gar gänzlich offline. Und unter Umständen ist es auch mit der blossen Neuinstallation eines Plugins nicht getan, weil Modifikationen und Konfigurationsdateien gelöscht wurden. Im Notfall kann man aber immer noch einzelne Plugins aus dem Komplett-Backup wiederherstellen, und letztlich geht es um eine Güterabwägung: Ich persönlich habe lieber ein temporär verunstaltetes Blog in Kauf genommen, um den Hack endlich loszuwerden.
  4. Schadcode aus WordPress-Datenbank eliminieren. Hier geht es darum, mit phpMyAdmin (oder einem anderen Datenbank-Frontend) einzelne Datensätze aus der Tabelle wp_options zu löschen. Die exakte Anleitung hierzu finden Sie im bereits erwähnten Artikel von Chris Pearson.

Ob diese Methode wirklich funktioniert? Nun, wir werden sehen. Im Moment jedenfalls sieht es gut aus:

Open Mind Blog ohne Pharma Hack

BuddyPress vor fremden Blicken schützen

WordPress Backend Login

Wer mit WordPress und BuddyPress seine eigene Social-Network-Plattform aufbaut, möchte möglicherweise nicht jedem beliebigen Besucher Zugang gewähren. Dabei geht es um zwei verschiedene Aspekte: Einerseits sollen nicht eingeloggte Besucher die Plattform nicht einsehen können (oder höchstens einige ausgewählte Seiten wie z.B. das Registrierungsformular), andererseits sollen neu registrierte Benutzer ihr Login erst nach der Freischaltung durch einen Administrator nutzen können.

Klingt einfach? Ist es aber nicht! Das Problem liegt zunächst darin, dass WordPress von Haus aus wohl das Backend, nicht aber das Frontend durchgängig mit einem Login schützt. Erschwerend kommt in unserem Fall dazu, dass das BuddyPress-Plugin einige spezielle Seiten anlegt (Activitiy Stream, Members, Groups), welche WordPress nicht wie normale Seiten behandelt; nicht alle Plugins, welche das Frontend mit einem Passwortschutz versehen, schützen deshalb auch die BuddyPress-Seiten. Und last but not least kennt WordPress keine Freischaltung von neu registrierten Benutzern durch einen Administrator, sondern erlaubt es den Benutzern, sich über einen per E-Mail zugestellten Aktivierungs-Link selbst freizuschalten.

Um also eine BuddyPress-Installation komplett vor fremden Blicken zu schützen benötigt man Plugins, und zwar gleich mehrere. Verschiedene meiner Testkandidaten haben zudem mit WordPress 3.1 und BuddyPress 1.2.8 – also den allerneusten Versionen – nicht korrekt funktioniert.

Plugin Schutz des Frontends Freischaltung von neuen Usern
BP Registration Options schützt nur BuddyPress-Seiten, aber keine Standard-WordPress-Seiten OK
Private BuddyPress OK
New User Approve wirkungslos
Absolute Privacy schützt nur Standard-WordPress-Seiten, aber keine BuddyPress-Seiten OK
WP Members wirkungslos
More Privacy Options wirkungslos
BuddyPress Privacy Component fehlerhaft (Website nicht mehr erreichbar)
Force User Login schützt nur Standard-WordPress-Seiten, aber keine BuddyPress-Seiten

 

Was in meinem Fall schliesslich funktionierte, war die Kombination aus Private BuddyPress als umfassender Schutz des Frontends und Absolute Privacy als zuverlässiger Freischaltprozess für neu registrierte Benutzer. Dass es allerdings dermassen umständlich ist, eine BuddyPress-Installation sauber gegen aussen abzuschotten, scheint mir schon ziemlich bedenklich – eine solche Funktionalität gehört meiner Meinung nach ins Basissystem und sollte nicht mit Plugins nachgerüstet werden müssen.

More Privacy Options: Passwortschutz für WordPress-Blogs

Login im WordPress Frontend 

Natürlich ist das Backend von WordPress über ein Login vor unbefugtem Zugriff geschützt. Das Frontend hingegen ist prinzipiell für alle zugänglich. Somit kann jeder Besucher des Blogs alle Artikel lesen, sobald diese publiziert sind. Nur auf Ebene des einzelnen Artikels bzw. der einzelnen Seite kann der Autor die Sichtbarkeit einschränken – sofern er daran denkt. Einen ganzen Blog hingegen kann WordPress nicht mit einem Login zu schützen, dazu muss man schon den Verzeichnisschutz des Webservers bemühen (z.B. über .htaccess).

Einstellungen zur Privatsphäre mit More Privacy Options

Eine Alternative stellt das Plug-in More Privacy Options dar. Es erweitert die Einstellungen zur Privatsphäre, so dass man die Sichtbarkeit eines Blogs auf registrierte Benutzer oder gar nur auf Administratoren beschränken kann. Das Plug-in ist auch kompatibel mit Blog-Netzwerken (mehrere Blogs in einer einzigen WordPress-Installation) und kann dann individuell pro Blog aktiviert werden. Einzig die deutsche Übersetzung fehlt – dafür sieht man auf Anhieb, welche zusätzlichen Optionen man More Privacy Options verdankt.

Schwere Sicherheitslücke in TYPOlight

TYPOlight Logo

Gemäss TYPOlight-Entwickler Leo Feyer weist der TYPOlight Installer eine schwere Sicherheitslücke auf, die es jedem ermöglicht, die Passwort-Abfrage zu umgehen und die Datenbank-Zugangsdaten sowie – falls der Safe Mode Hack verwendet wird – FTP-Zugangsdaten auszulesen.

Abhilfe schafft ein Update auf die TYPOlight-Version 2.7.6. Wer aus bestimmten Gründen kein Komplett-Update durchführen möchte oder kann, installiert stattdessen einen Patch, der für die TYPOlight-Versionen 2.7, 2.6, 2.5 und 2.4 bereitsteht.

TYPO3 Security Checklist: 47 Massnahmen, um eine TYPO3-Installation sicherer zu machen

image

UPDATE: Version 0.9.2 verfügbar (Problem mit TYPO3-Font “Share” gefixt)

Der Angriff auf die Website von Bundesinnenminister Wolfgang Schäuble hat Diskussionen über die Sicherheit von TYPO3 entfacht. Wer nun allerdings TYPO3 als unsicher abqualifiziert und denkt, dass dies mit “seinem” CMS nicht passieren könnte, macht es sich zu einfach. Grundsätzlich ist jede Software angreifbar, um so mehr, wenn sie auf einem öffentlich zugänglichen Webserver läuft. TYPO3 ist weder sicherer noch unsicherer als vergleichbare Systeme – es ist vielmehr eine Frage der richtigen Handhabung.

Die TYPO3 Security Checklist ist eine Sammlung von rund 50 Tipps für die Praxis, wie man eine TYPO3-Installation sicherer macht. Sie richtet sich nicht an Entwickler, sondern an TYPO3-Administratoren, welche eine Website aufsetzen und betreiben. Die Empfehlungen lassen sich in den meisten Fällen auch in einer Shared-Hosting-Umgebung umsetzen, wo man nur beschränkten Zugriff auf Webserver und Datenbank hat.

Dies ist die erste öffentliche Version dieser Checkliste. Ergänzungen und Korrekturen nehme ich gerne entgegen – sei es als Kommentar in diesem Blog, sei es per Kontaktformular.

wrg_anotherbelogin: Das bessere Backend Login für TYPO3

image

Auf den ersten Blick ist wrg_anotherbelogin nichts anderes als eine weitere Extension, mit der ein vergesslicher TYPO3 Backend User sein Passwort zurücksetzen kann. Doch obwohl die Extension offiziell so heisst, ist sie weit mehr als nur Another Backend Login.

Die Hauptfunktion besteht nämlich nicht darin, den Zugang zum Backend zu ermöglichen, sondern ihn zu unterbinden, falls Verdacht auf Missbrauch besteht. Konkret kann TYPO3 so konfiguriert werden, dass ein Backend User Account nach einer bestimmten Anzahl von fehlgeschlagenen Login-Versuchen automatisch gesperrt wird. Nach demselben Prinzip können auch IP-Adressen blockiert werden, was Brute-Force-Attacken erheblich erschwert. Über alle relevanten Ereignisse kann der Administrator per E-Mail benachrichtigt werden.

Meiner Meinung nach müssten alle diese Funktionen fix in den TYPO3 Core integriert werden. Bis es soweit ist, sollte wrg_anotherbelogin zur Standardausstattung einer jeden TYPO3-Installation gehören.

Das Ende einer modernen Legende: Gelöscht ist gelöscht!

Auch in diesem Blog sind schon Tools vorgestellt worden, mit denen Daten sicher gelöscht werden können: Eraser und DBAN. Und auch ich habe in diesem Zusammenhang die alte Regel wiederholt, dass Daten nur dann endgültig gelöscht sind, wenn man sie mehrfach durch Zufallsdaten überschrieben hat.

Nun zeigt eine Studie von Craig Wright, dass diese Behauptung empirisch nicht zu belegen ist – das einmalige Überschreiben mit Nullen reicht absolut aus. Die Chance, ein einzelnes Bit korrekt zu rekonstruieren, ist zwar noch leicht grösser als 50%, für relevante Datenmengen tendiert diese Wahrscheinlichkeit jedoch sehr rasch gegen Null.

Zeit also, von dieser modernen Legende Abschied zu nehmen. Folgende zwei Regeln haben allerdings weiterhin Gültigkeit:

  1. Das normale Löschen einer Datei über den Papierkorb ist nicht sicher: Auch wenn der Papierkorb geleert wurde, ist die Datei – sofern das Betriebssystem die betreffenden Sektoren auf der Festplatte inzwischen nicht für andere Daten genutzt hat – mit einfachen Tools wiederherstellbar.
  2. Oft existieren von einer Datei diverse Kopien – in Form von Backups, temporären Dateien, Browser Caches, Auslagerungsdateien etc. Diese zu finden ist erheblich schwieriger und stellt bei wirklich sensitiven Daten ein erhebliches Sicherheitsrisiko dar.