WordPress ist mittlerweile eines der beliebtesten Publishingsysteme auf der Welt. Die weite Verbreitung und vor allem seine einfache Anwendung auch für Laien haben aber auch dazu geführt, dass es bei Hackern ganz weit oben auf der Abschlussliste steht.
Mit WPScan steht ein Werkzeug zur Verfügung, mit dem man seine (oder auch andere) WordPress-Installationen auf Schwachstellen testen kann.
Auf WPScan bin ich durch den Artikel „Wie kann ich WordPress sicherer machen“ gestossen und habe es gleich mal ausprobiert. Zuvor hatte ich Plecost im Einsatz, aber WPScan scheint mir eine größere Entwicklergemeinde zu haben.
Das Programm basiert auf Ruby und wird Git-gehostet. Es ist also Vorbedingung, dass beide Pakete auf eurem Rechner installiert sind.
Vorweg: mit der Installationsanleitung für Ubuntu von der originalen WPScan-Webseite bin ich nicht erfolgreich gewesen. Das Problem ist (zumindest auf meinem Lubuntu) auf Ruby-Seite zu suchen. Mit dieser Anleitung ging es dann irgendwie (trotz Fehlermeldungen).
Wenn man es dann geschafft hat, den Scanner endlich zu installieren – wird die ganze Arbeit mit WPScan auch wieder in einem Terminalfenster mit der Kommandozeile erledigt.
Dazu wechselt man in das WPScan Verzeichnis:
cd wpscan
Alle Befehle in WPScan starten mit:
ruby wpscan.rb --[Befehlspräzisierung]
Beispielsweise aktualisiert dieser Befehl die WPScan interne Datenbank:
ruby wpscan.rb --update
Mit diesem Befehl listet WPScan alle Plugins auf der angegebenen URL auf (sofern diese erkannt werden):
ruby wpscan.rb --url www.example.com --enumerate p
Es gibt dann logischerweise auch entsprechende Befehle, um die installierten Themes aufzulisten, die eingerichteten Benutzer usw.
Auch das Abklopfen von Passwörtern wird durch eine Brute Force Funktion ermöglicht. Sofern man eine .txt Datei der am häufigsten verwendeten Passwörter besitzt. Da weiss ich allerdings nicht, wie sich das mit einem auf der Gegenseite installierten Plugin wie Limit Login Attempts verhält. LLA und andere Plugins schliessen ja den Angreifer auf IP-Adressen-Basis aus, sofern er eine bestimmte Anzahl von fehlerhaften Logins erzeugt. Auch ist für mich noch unklar, welche Ergebnisse bei Installationen mit verschobener Login-Maske zu erwarten sind.
Nack Absetzen des Befehls spuckt das Programm erstmal Basisinformationen zur untersuchten Webseite aus (lokale Installationen lassen sich übrigens auch scannen):
- Verwendete WordPress Version
- Interessante Einträge in der robots.txt
- Webserver (durch Header ausgelesen)
- XML-RPC Interface
- aktives Theme
Dann folgen die Ergebnisse, nach denen man eigentlich gesucht hat.
Zu den erkannten Plugins und Themes werden potentielle Schwachstellen (sofern bekannt) aufgelistet und Webadressen genannt, auf denen diese Schwachstellen beschrieben sind. Kann WPScan die Pluginversion nicht herausfinden, listet es einfach Sicherheitslücken alter Versionen auf und gibt an, ab welcher Version diese geschlossen wurden.
Die Ergebnisse waren bei mir recht unterschiedlich. Weder die Plugins noch die Themes wurden alle erkannt. Entweder ist die interne Datenbank (ca. 500 Themes und 2100 Plugins) nicht wirklich auf dem neuesten Stand oder die Plugin- und Theme-Programmierer haben Mittel und Wege gefunden, ihre Entwicklungen nach außen zu verschleiern. Möglich wäre auch noch, dass ich z.T. Plugins verwende, die nicht unter den Top 10, Top 100, Top 1000 zu finden sind.
WPScan arbeitet nicht mit Magie, Tricks oder versteckten WordPress-Funktionen. Es bringt nur Ergebnisse zutage, die man auch „per Hand“ würde herausfinden können. Nur dass dies länger dauert.
Darin liegt der Nutzen dieser Software: alles an Informationen schnell und geordnet aufzulisten.
Insgesamt ist WPScan eine runde Sache, wenn man einmal testen will, wie gesprächig (um nicht zu sagen geschwätzig) die eigene WordPress-Seite ist. Eine echte, tiefgründige Sicherheitsanalyse kann das Programm natürlich nicht liefern, dafür braucht es einfach Expertentum. Es kann auch nur Sicherheitslücken benennen, die bereits bekannt sind. Integriert ein Programmierer für sein Plugin/Theme eine Funktion oder Bibliothek, die Sicherheitslöcher enthält, wird WPScan das nicht beanstanden. Es scannt und interpretiert nicht den Code sondern trägt nur zusammen, was über diese oder jenes Plugin/Theme gemunkelt wird.