Permalink

12

Hacking WordPress – Ein Blick hinter die Kulissen

1. Hilfe ich wurde gehackt!Hacking WordPress

Allein in Deutschland ist der Verbreitungsgrad von WordPress enorm – Tendenz weiter steigend. Im weltweiten Vergleich mit anderen Content Management Systemen (CMS) hält WordPress einen Anteil von bis zu 51% (Top Million Sites). Beeindruckende Zahlen also, die WordPress immer stärker in den Fokus von professionellen Angreifern rückt. So attackierte ein Botnet im April diesen Jahres WordPress-Installationen weltweit.

Zum Schutz und Absicherung von Installationen wurden bereits zahlreiche Anleitungen veröffentlicht. Empfehlenswert sind »Hardnening WordPress«, »Initiative: Mehr Sicherheit für WordPress« (Sergej Müller) und meine Artikelserie »WordPress absichern«.

In diesem Beitrag werden allerdings keine weiteren Schutzmaßnahmen vorgestellt, sondern wie Angreifer vorgehen, um WordPress-Installationen zu hacken. Es soll ein kleiner Einblick hinter die Kulissen sein – in der Realität existieren weitaus mehr Möglichkeiten und Varianten.

2. Hinweis zu »Hacking WordPress«

Der Angriff von WordPress-Installationen oder Systemen ohne Erlaubnis bzw. Einverständniserklärung stellt eine strafbare Handlung dar. Wer ohne vertragliche Grundlage fremde Systeme angreift begibt sich auf sehr dünnes Eis. Die nachfolgenden Informationen dienen der Aufklärung und sollten lediglich im Rahmen eines Penetrationstests Verwendung finden. Im Gegensatz zu illegalen Hacking-Angriffen stellt ein Penetrationstest ein auftragsgesteuerter Einbruch in ein oder mehrere Systeme dar. Das Vorgehen dient im Grunde der »Qualitätskontrolle« der aktuell umgesetzten IT-Sicherheit im Unternehmensumfeld.

Ein Angriff / Penetrationstest lässt sich in unterschiedlichen Phasen unterteilen, von denen ein Teil sequentiell wiederholt wird. Phase 1 dient zunächst der Informationsgewinnung über das Ziel. Während ein Penetrationstester in Phase 4 die Ergebnisse festhält, wird sich ein Angreifer diesen Schritt wohl eher sparen…

4-Phasen-Modell

3. Informationsgewinnung – Phase 1

Im ersten Schritt wird ein Angreifer möglichst viele Informationen über sein Ziel sammeln, die für den weiteren Verlauf von Interesse sein können. Zu diesem Zweck werden verschiedene öffentlich verfügbare Informationsquellen durchsucht. Diese werden im Anschluss ausgewertet und sollen Aufschluss darüber geben, über welchen Weg ein Einbruch am einfachsten realisiert werden kann. Für diesen Zweck stehen unterschiedliche Tools zur Verfügung – die meisten davon befinden sich auf der Linux Distribution Kali, dem Nachfolger von BackTrack. Die Distribution wird sowohl von Hackern, als auch von Penetrationstestern zur Auffindung von Schwachstellen / Sicherheitsanalysen eingesetzt.

Dabei helfen Tools die unter [Information Gathering] zusammengefasst sind. Letztendlich werden in der ersten Phase folgende Ziele verfolgt:

  • Ziel identifizieren
  • System / Anwendungsversion bestimmen
  • Verfügbare Netzwerk-Ports
  • Laufende Services
  • Verteidigungsstrategien erkennen
  • [ ... ]

Wink Du kannst den Blog aktiv unterstützen! Support me ✓

3.1 Beispiel: WordPress Identifikation

Das Verstecken der WordPress-Versionsnummer oder sonstigen Meta-Daten wird bei Laien oftmals mit dem Schutz gegen Spambots oder Sicherheitslücken in Verbindung gebracht. In der Tat lassen sich damit die besonders »dämlichen« Bots an der Nase herumführen, aber bereits semi-professionelle Varianten lassen sich von den Security by Obscurity Maßnahmen nicht beirren. Sie benutzen ausgeklügelte Methoden zur Feststellung ob eine Seite mit WordPress betrieben wird.

Wer selbst mal schauen möchte ob seine WordPress-Installation als solche erkannt wird kann folgende Webseite nutzen: Is it WordPress?

Is it WordPress?

Mehr Informationen benötigt? Beispielsweise alle installierten Plugins? Auch gar kein Problem mit dem Tool plecost. Hier ein Fingerprint einer WordPress-Installation:

Fingerprint

Mit Hilfe der gesammelten Informationen lässt sich WordPress bzw. eines der installierten Plugins gezielt angreifen. Details zu Schwachstellen für bestimmte Versionen stellt beispielsweise CVE-Details zur Verfügung.

3.2 Beispiel: System identifizieren

Nmap ist ein Werkzeug zum Scannen und Auswerten von Hosts in einem Netzwerk und fällt in die Kategorie der Portscanner. Der Name steht für Network Mapper. Nmap wird in erster Linie für Portscanning eingesetzt. Daneben verfügt es über weitere Techniken, wie beispielsweise die Erkennung des eingesetzten Betriebssystems (OS-Fingerprinting).

OS-Detection

Letztendlich dienen solche Informationen wiederum als Ausgangspunkt für die weiteren Phasen, in denen Schwachstellen aktiv ausgenutzt werden.

3.3 Beispiel: Erkennung von Benutzer-Accounts

Um sich in den Administrationsbereich von WordPress einzuloggen ist die Kombination aus einem Benutzernamen und Passwort erforderlich. Falls ein Angreifer im Vorfeld den Benutzernamen »erraten« kann, benötigt er im Anschluss lediglich das korrekte Passwort. Insgesamt erleichtert das ein erfolgreiches Eindringen in den sensiblen Administrationsbereich.

Oft genügt dazu die Eingabe von

wordpress-blog-adress.de/?author=1

in die Browser-Zeile. In der Standard-Installation bekommt ein Administrator / Nutzer eine eindeutige Identifikationsnummer zugewiesen. Meist endet diese auf author=1 bzw. kann durch den Austausch der 1 am Ende leicht durchprobiert werden.

Falls der WordPress-Betreiber dies manuell geändert hat hilft ein Skript für nmap – wer probiert schon gerne alle Kombinationen durch:

WordPress-User

4. Angriffsvektoren finden – Phase 2

Ausgehend von den in Schritt eins gesammelten Informationen werden anschließend mögliche Einstiegspunkte in das System identifiziert. Mit Hilfe von Tools und manuellen Abfragen wird konkrekt nach Schwachstellen und Lücken gesucht, die einen Einbruch ermöglichen. Unter [Vulnerability Analysis] sind die benötigten Tools zusammengefasst und dienen folgenden Zielen:

  • Schwachstellen identifizieren
  • Identifizieren und priorisieren von System Zugangspunkten
  • Risiken einschätzen
  • [ ... ]

4.1 Administrationsbereich

Äußert beliebt als Einstiegspunkt ist der Login zum Administrationsbereich von WordPress – nicht zuletzt deswegen, weil sich ein Angriff bei vielen Installationen mit einfachen Mitteln bewerkstelligen lässt.

Über den Browser lässt sich prüfen, ob der Administrationsbereich generell für jeden erreichbar ist:

wordpress-blog-adress.de/wp-admin

Nach der Eingabe eines Benutzernamens und Passwort kann zunächst die Reaktion von WordPress erkundet werden.

WordPress Login

Im ersten Beispiel wird der Account »admin« bestätigt. Dieser ist also vorhanden und dient vermutlich der Administration der WordPress-Installation.

Aus Beispiel zwei lässt sich die Verwendung eines Security-Plugins ableiten. Vermutlich kommt hier Login LockDown / Limit Login Attempts oder ein ähnliches Plugin zum Einsatz. Diese protokollieren fehlgeschlagene Login-Versuche. Falls ein Anmeldeversuch innerhalb von 5 Minuten dreimal hintereinander fehlschlägt blockiert das Plugin die anfragende IP-Adresse beispielsweise für eine Stunde. Script-Kiddies und dämliche Bots lassen sich von solchen Maßnahmen abschrecken – professionelle Angreifer hingegen weniger.

4.2 Fehlende SSL-Verschlüsselung

Hauptsächlich wird SSL für die Absicherung zwischen Webbrowser und Webserver eingesetzt – also immer dann, wenn sensible Informationen über das unsichere Internet ausgetauscht werden sollen.

Über den Browser wird abermals der Login zum Administrationsbereich aufgerufen:

wordpress-blog-adress.de/wp-admin

HTTPS-Login

Falls zwischen Browser und Server keine verschlüsselte SSL-Verbindung ausgehandelt wird, können die Anmeldedaten mitgeschnitten werden. Ganz konkret: Ein WordPress-Blogger nutzt das kostenlose WLAN in seinem Lieblingskaffee und loggt sich in den Administrationsbereich ein. Da die Verbindung nicht über SSL abgesichert wird, kann einer Angreifer die Anmeldedaten im Klartext bzw. unverschlüsselt mitlesen. Solch ein Angriff ist mit einfachen Mitteln bereits von Anfängern durchführbar.

5. Ausnutzen von Schwachstellen – Phase 3

Gefundene Schwachstellen gilt es in Phase 3 gezielt auszunutzen. Dafür werden vorhandene Exploits verwendet oder neue entwickelt, die es ermöglichen Systeme zu kompromittieren. Falls in ein System eingerungen werden kann, ergeben sich aus dem Zugriff oftmals weitere mögliche Angriffsziele, die vorher nicht erreichbar waren. Mit der Toolkiste aus [Exploitation Tools] oder [Privilige Escalation] stehen in Kali genügend Mittel zur Verfügung. Verfolgt wird damit:

  • Schwachstellen in Systemen / Anwendungen ausnutzen
  • Systemzugriff erhalten
  • Zugang zu geschützten Web-Bereichen
  • Erfassen von sensiblen Daten
  • [ ... ]

5.1 Brute-Force WP-Login

Da Administratoren über die weitreichendsten Berechtigungen verfügen, stellen sie ein beliebtes Ziel für Angreifer dar. Einmal eingeloggt erlauben Sie beispielsweise das Hinzufügen von schädlichen PHP- oder Javascript-Befehlen direkt über das Dashboard. In der Informationsphase wurden bereits Anmeldeinformationen gesammelt, die gezielt für den Einbruch in das Backend genutzt werden können.

Geschützt wird der Administrationsbereich aus einer Kombination von Benutzername und Passwort. Falls ein Angreifer bereits über den Benutzernamen verfügt, so muss er im nächsten Schritt das Passwort »erraten«. Mittels einem Brute-Force-Angriff wird durch Ausprobieren das passende Passwort ermittelt. In freier Wildbahn führt dieser Angriff oft zum Erfolg, da viele Anwender noch immer unsichere Passwörter verwenden.

Speziell für diesen Zweck steht Hydra zur Verfügung. Neben WordPress-Installationen kann damit eine breite Palette von Systemen und Anwendungen angegriffen werden.

Hydra

5.2 Das Tool WPScan

WPScan ist speziell auf WordPress zugeschnitten. Es bietet zahlreiche Funktionen, wie beispielsweise die Erkennung der installierten Plugins, Themes und WordPress-Versionen. Des Weiteren ist es in der Lage Benutzer-Accounts für Brute-Force-Angriffe zu »erraten« und verweist direkt auf Schwachstellen-Datenbanken, falls während des Scans auffällige Plugins gefunden werden. Im Beispiel wird eine Lücke im Plugin W3 Total Cache (Version 0.9.3) detektiert.

WPScan5.3 Metasploit

Metasploit ist eine Art Allzweckwaffe bzw. große Toolbox für Penetrationstests und Sicherheitsanalysen. Es besteht aus unterschiedlichen Teilbereichen, Teilprojekten und Modulen – der Umfang erlaubt den Einsatz in allen Phasen eines Penetrationstests. Auch Angreifer machen sich Metasploit zu Nutze, um in fremde Systeme einzudringen. Hier lediglich ein kurzer Einblick in das Metasploit Universum.

Das Metasploit Modul »wordpress_login_enum« dient zur Feststellung von gültigen Benutzer-Accounts und kann im Anschluss einen Passwort-Rate-Angriff durchführen.

Metasploit6. Weitere Möglichkeiten

Die oben dargestellten Tools und Möglichkeiten stellen lediglich eine Mini-Auswahl dar. In der Praxis existieren unzählige Tools und Varianten, Webanwendungen und deren Host-Systeme zu hacken. Allein in den Datenbanken von Metasploit und exploit-db.com sind hunderte von Schwachstellen erfasst und beschrieben. Immer wieder Ziel sind Plugins, Themes und der WordPress-Kern selbst.

Hinweis:
Auch von deaktivierten Plugins oder Themes geht eine Gefahr aus. Selbst wenn sie nicht aktiv verwendet werden, so sind sie im Normalfall dennoch erreichbar. Beispielsweise erlaubt das Plugin Asset-Manager (Version <= 2.0) einen Datei-Upload in ein temporäres Verzeichnis – anschließend kann darüber Schadcode ausgeführt werden. Für diesen Einbruch muss das Plugin nicht aktiv sein, sondern lediglich auf dem Webspace vorhanden.

Lücke: WordPress Asset-Manager PHP File Upload Vulnerability.

6.1 Angriffe auf Systemebene

Allein für Phase 1 (Informationsbeschaffung) wird ein Angreifer viel Zeit aufwenden, um an Daten / Informationen zu gelangen, die ihm später nützlich sein können. Immerhin hängt davon indirekt der Erfolg für den späteren Einbruch ab. Bereits einfache Wege wie, Google-Hacking (Dorks), DNS-Informationen und soziale Netzwerke stellen wichtige Informationsquellen dar. Daraus lassen sich oftmals Informationen ableiten, die entscheidende Hinweise für einen erfolgreichen Angriff bieten. Womöglich bietet eine WordPress-Installation selbst keinen Angriffspunkt, was den Fokus auf das Host-System richtet. Als Beispiel:

  • MySQL-Datenbank
  • FTP / SSH Service
  • CPanel oder andere Tools für die web-basierte Administration
  • phpMyAdmin Zugänge
  • [ ... ]

Für die Sicherheit von WordPress müssen alle Zahnräder ineinandergreifen – letztendlich hat ein Angreifer immer das Ziel das schwächste Zahnrad auszumachen.

7. Fazit

Der Artikel WordPress-Hacking soll einen Eindruck über den Ablauf eines Angriffs vermitteln – auch wenn die Phasen leicht vermischt sind. Angreifer verfolgen damit meist unterschiedliche Ziele. Oftmals dienen infizierte WordPress-Installationen als Ausgangspunkt für weitere Angriffe oder zum Versenden von Spam-Mails. Neben Vandalismus und Rachegelüste sind praktisch unzählige Absichten denkbar.

Wenn eure WordPress-Installation selbst schon gehackt wurde oder ihr die Sicherheit im Vorfeld verbessern wollt, dann empfehle ich nochmals folgende Anleitungen: »Hardnening WordPress«, »Initiative: Mehr Sicherheit für WordPress« (Sergej Müller) und meine Artikelserie »WordPress absichern«.

Bildquellen:

Skull: „#9358035“, http://de.fotolia.com/id/9358035

Empfehle den Beitrag weiter:

Hat dir der Beitrag gefallen?

Dann abonniere doch den RSS-Feed oder füge mich zu deinem Xing-Profil hinzu. Du kannst mir auch bequem auf APP.NET oder Twitter folgen.

Gerne kannst du mich auch unterstützen: Support me ✓

Autor: Mike Kuketz

Mike beschäftigt sich seit vielen Jahren professionell mit dem Thema IT-Sicherheit. Er ist Gründer von Kuketz IT-Security (www.kuketz-security.de) und unterstützt Unternehmen bei der Implementierung neuer IT-Sicherheitstechnologien. Weitere Infos: Über mich

12 Kommentare

  1. Die Seite unter 5.2 ist über den Namen noch recht eindeutig zuzuordnen. Damit wird ja quasi die Schwachstelle öffentlich gemacht. Ich hoffe doch, dieser Fehler wurde vorher gemeldet und ist schon geschlossen, oder?

    • Danke Torsten – hab’s jetzt gänzlich unkenntlich gemacht.
      Die oben dargestellte Lücke lässt sich lediglich unter besonderen Voraussetzungen ausnutzen – mehr dazu in den Security-Advisories.

      Die Lücke ist übrigens in WP3 Total Cache 0.9.3 in Kombination mit WP 3.7.x geschlossen.

  2. Ein wirklich sehr guter Artikel. Den werde ich auf jedem Fall in meine Linksammlung aufnehmen. Leider erlebe auch ich viel zu häufig, dass sich Nutzer auf “Security through obscurity” verlassen.

    Ich habe bisher auf meine WordPress Systeme zum Glück noch keinen Einbruch erlebt, aber ein Webserver wurde mal kompromittiert. Dabei geschah der Angriff per FTP, trotz ziemlich komplexer Passwörtert. Seitdem erlauben wir den FTP Zugang nur noch über SFTP mit Public-Key-Verfahren und Passphrase. Aber das schützt eben nicht vor Lücken durch unsichere Plugins oder Themes. Es bleibt eben immer ein Restrisiko.

  3. Hi.. ;) Toller Artikel! Endlich mal ein Artikel unter
    vielen, die Klartext sprechen und die Vorgehensweise (für Laien)
    schön erklärt, sowie die Schwachstellen der sogenannten
    “Sicherheitsplugins” klar auch aufzeigt. Schon mit einfachen
    Sicherheitseiten wie hier, erfährt man schon einiges:
    http://sitecheck.sucuri.net/ Da bringt das Ausblenden von
    WP-Version / JS / Versionsnummer .. etc. nicht wirklich viel. Ich
    stelle mir nur die Frage, warum dann überhaupt der Aufwand? Denn
    wer will, kann sich über kurz- oder lang überall “hacken” :( Können
    wir nicht eine Software erfinden um die Blödel aufzuspüren und die
    in einen Sack zu stecken und draufzuhauen? Sorry, aber die Hacker
    zerstören Existenzen bzw. wertvolle Zeit von einfachen
    Webseitenbetreibern! Obwohlgleich diese gleich in grotesker Weise
    ja den Fortschritt (Sicherheit) antreiben… ? Also liebe Hacker,
    bitte informiert doch lieber die Webseitenbetreiber über
    Schwachstellen, anstatt fast “feige” von hinten einzubrechen. Denn
    Fehler suchen und finden und das mit den heutigen Programmen, ist
    das eine erstrebenswerte Kunst? (( Liest wohl kein Hacker, aber wer
    weiß ;)) Ich werde mir Ihre Ratschläge auf Ihren Seiten durchlesen,
    vielleicht finde ich noch was (bestimmt!), womit ich mein Gewissen
    beruhigen kann. Vielen Dank für das Lesen! Grüße

  4. Hallo, vielen Dank für die vielen Tipps. Mit den WordPress Sicherheitsplugins lässt (z.b. WPSecurity usw.) lassen sich ja direkt viele der Sicherheitslücken schließen und Angriffe erschweren. Wir hatten einige Zeit immer das Problem (Domainfactory-Server), dass trotz der Sicherheitsplugins immer Schadcode in unsere header.php eingeschleust wurde.
    Dies ist allerdings nicht nur bei unseren WordPress-Installationen, sondern auch anderen Installationen passiert.
    Hat jemand hierzu einen Tipp oder eine Ursache, wie man an diese Dateien kommt aber ansonsten keine Änderungen vornimmt? Entweder muss es ja an der Serverkonfiguration liegen oder an den Dateiberechigungen. Diese haben wir für die header.php runtergesetzt, sodass niemand mehr inkl. Besitzer “ausführen” kann, und seitdem ist Ruhe. Ganz wohl ist uns bei der Sache allerdings trotzdem nicht, weil wir die genaue Ursache dazu nicht kennen…
    Vielen Dank für eure Hinweise!
    Steffen (timako)

    • Hallo Steffen,

      wie ich in meinen Kommentar weiter oben schon angemerkt habe, passieren sehr viele Angriffe über FTP. Da hilft dann eben auch kein Plugin als Schutz. Falls es dir möglich ist, suche dir mal die FTP Logfiles raus. Dort ist so etwas meist sehr schnell zu erkennen.

      Bernhard

    • @timako – interessanterweise habe ich bei vielen WP-Installationen auf verschiedensten Hostingaccounts nur bei domainfactory bisher genau oder ziemlich genau das gleiche Problem. Ich bin mir ziemlich sicher, alle Sicherheitshausaufgaben gemacht zu haben, daher kann es m.E. nur ein generelles Sicherheitsproblem bei domainfactory sein, welches von DF natürlich dementiert wird. Für mich, da es bei allen anderen Hostern derartige Probleme noch nie gab, Anlass genug, von Domainfactory zu einem anderen Anbieter zu wechseln.

    • Ich führe Penetrationstests durch, auch wenn es in diesem Artikel jetzt nicht direkt rüberkommt. ;)
      Pauschalangebote halte ich allerdings für unseriös, da ein »Sicherheits-Check« von WordPress von diversen Faktoren abhängt.

      Wenn du Interesse hast, darfst du dich gerne melden.

  5. Der Artikel desillusioniert ein wenig :-)

    Bisher lege ich immer mehrere Fake-Benutzer an, um dann als 5. oder 6. User den eigentlichen Admin einzurichten. Hat das überhaupt Sinn? Oder wäre es hilfreich, quasi als “Ablenkung” den User 1 z. B. als “admin”, aber mit Abonnenten-Rechten, bestehen zu lassen?

  6. @Joachim: Das ist alles nicht wirklich hilfreich bei der Sicherheit. Ein Skript kann auch kurz mal die ersten 100 User durchtesten /?author=1 … 100 (siehe Punkt 3.3)
    Ein htaccess-basierter zusätzlicher Passwortschutz ist definitiv effektiver und schützt den PHP-Interpreter zusätzlich vor zu viel Anfragen.

Hinterlasse eine Antwort

Pflichtfelder sind mit * markiert.