WordPress - REST API Informationspreisgabe über Medien-Endpunkte

Im Rahmen einer aktuellen Analyse wurde die öffentliche WordPress REST API einer Website betrachtet. Dabei zeigte sich ein typisches Bild vieler WordPress-Installationen: Während die Benutzer-Enumeration bereits erfolgreich abgesichert wurde, ist die Medienbibliothek weiterhin umfangreich über die REST API abrufbar.

Untersucht wurden die öffentlich erreichbaren Endpunkte:

• /wp-json/
• /wp-json/wp/v2/media
• /wp-json/wp/v2/users

Die Benutzerabfrage liefert erwartungsgemäß einen 401 Unauthorized Fehler. Eine Auflistung von WordPress-Benutzern ist somit nicht möglich und eine häufig kritisierte Schwachstelle wurde bereits geschlossen.

Wo liegt weiterhin ein Risiko vor?

Der Medien-Endpunkt stellt weiterhin umfangreiche Informationen ohne Anmeldung bereit. Dazu gehören unter anderem:

• Dateinamen und Upload-Zeitpunkte
• Bildgrößen und Dateigrößen
• Verknüpfungen zu Seiten und Beiträgen
• Autoren-IDs
• Direkte Links zu Originaldateien

Für Angreifer sind solche Informationen interessant, da sie die automatisierte Analyse einer Website erleichtern und wertvolle OSINT-Daten liefern können.

Wurde ein Sicherheitsvorfall festgestellt?

Nein.

Im untersuchten Datenbestand fanden sich keine Hinweise auf:

• vertrauliche Dokumente
• Zugangsdaten oder API-Keys
• Datenbank-Backups
• Konfigurationsdateien
• Schadcode oder kompromittierte Inhalte

Die öffentlich erreichbaren Dateien beschränkten sich überwiegend auf Bilder, Grafiken und Marketingmaterial.

Bewertung

Aus Security-Sicht handelt es sich aktuell nicht um einen Incident, sondern um ein klassisches Hardening-Thema. Die Funktionalität der REST API ist grundsätzlich vorgesehen, sollte jedoch regelmäßig überprüft und auf das tatsächlich benötigte Maß reduziert werden.

Empfehlungen

• Regelmäßige Prüfung der Medienbibliothek auf veraltete oder nicht mehr benötigte Uploads
• Überprüfung, welche REST-Endpunkte wirklich öffentlich erforderlich sind
• Entfernung sensibler Metadaten aus Bilddateien
• Regelmäßige Security Reviews von WordPress, Themes und Plugins
• Dokumentation und Nachverfolgung von Hardening-Maßnahmen

Fazit

Die Untersuchung zeigt, dass Sicherheitsmaßnahmen bereits teilweise umgesetzt wurden. Insbesondere die Absicherung der Benutzerliste ist positiv zu bewerten. Gleichzeitig bleibt die öffentlich zugängliche Medienbibliothek ein potenzieller Informationslieferant für OSINT-Recherchen und sollte im Rahmen eines kontinuierlichen Security Hardenings überprüft werden.

Security ist nicht nur das Schließen von Schwachstellen, sondern auch die bewusste Reduzierung unnötiger Informationspreisgabe. 

REST Webservice - Mittels Postman HTTP-APIs testen

HTTP-Schnittstellen (z.B. REST oder SOAP) werden in fast allen modernen Webanwendungen verwendet. So ist es möglich über eine API Datensätze zu erstellen (PUT), zu lesen (GET), zu ändern oder zu löschen (siehe auch HTTP Request Methods). Fehler in der API sollten mittels Tests (Unittests) schnell gefunden werden, da Fehlfunktion fatale Auswirkungen haben können. Zusätzlich bieten sich aber auch Integrationstests mit Hilfe von Postman an. Auf diese Funktion gehe ich kurz in diesem Artikel ein. Nur so kann sichergestellt werden, das eine Software wie erwartet funktioniert.

Mit Hilfe von Postman kann man die APIs bequem testen und gleichzeitig Funktionen für automatische Tests verwenden.

Der Download von Postman erfolgt unter https://www.postman.com .

Es muss natürlich eine öffentliche REST-API zur Verfügung stehen, ich verwende hier als Beispiel https://www.predic8.de/rest-beispiel.htm, ein Projekt der predic8 GmbH an .

Hilfreich ist zudem die Postman-Dokumentation https://learning.postman.com/docs/introduction/overview/ .

Postman-Collection anlegen

GET https://api.predic8.de/shop/v2/products

Testen kann man jetzt den Request mit einem Klick auf "Send", jetzt wird eine Liste von  Produkten angezeigt.

GET https://api.predic8.de/shop/v2/products/13 => Einzelnes Produkt
GET https://api.predic8.de/shop/v2/vendors/3 => Einzelner Hersteller
GET https://api.predic8.de/shop/v2/orders/4 => Eine Bestellung
POST https://api.predic8.de/shop/products/ => Anlegen eines Produkt

Beispiel Response

{
    "meta": {
        "count": 19,
        "start": 1,
        "limit": 10,
        "next_link": "/shop/v2/products?start=11&limit=10"
    },
    "products": [
        {
            "id": 19,
            "name": "Grapes2,",
            "self_link": "/shop/v2/products/19"
        },
        {
            "id": 18,
            "name": "Grapes1,",
            "self_link": "/shop/v2/products/18"
        },
...
    ]
}

Mit Postman wurde die jeweiligen Endpunkte der API aufgerufen und es gab auch eine Antwort (Response) vom Server, aber ist dies jetzt auch die Antwort welche man erwartet hat?

Integrationstests mit Postman

Beim Aufruf von GET products wird ein Test hinterlegt (Prüfung Statuscode = 200).

• Tab "Tests" anklicken
• JavaScript Code hinzufügen (Postman zeigt im rechten Bereich bereits einige Vorschläge an)

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

Diese Methode lässt sich einfach erweitern unnd mann den HTTP Status inkl. der zurückgegebenen Daten mit den zu erwarteten Werten abgleichen. 

Auch lassen sich Tests der einzelnen Endpunkte umsetzen und so eine "Reise" eines User nachbauen. Der folgende Test nimmt die ID des Response-Body eines neu angelegten products und schreibt diese in die Variable productId.

const body = JSON.parse(responseBody); pm.collectionVariables.set("productId", body.id);

In den nachfolgenden Requests, kann man diese Variable jetzt mit doppelt geschweiften Klammern verwenden /products/{{productId}} .

Quelle: https://stackoverflow.com/a/58325002

WordPress - Brute-Force Angriffe mit XML-RPC und REST-API

Das freie Content-Management-System WordPress ist weit verbreitet und oft werden nach einer Erstinstallation keine neuen Releases bzw. Security Updates mehr eingespielt. Hierdurch ergeben sich über die XML-RPC Schnittstelle in Verbindung mit der REST-API Möglichkeiten für eine Brute-Force-Attacke.

1. Schritt: REST-API Wordpress User herausfinden

• Unter der URL http://DOMAIN.DE/wp-json/wp/v2/users lassen sich die User der Wordpress Installation auslesen, sofern die API von Wordpress nicht deaktiviert wurde.

• Gleichzeitig lassen sich hier ggf. massenhaft E-Mail Adressen abgreifen, wenn die User als E-Mail Adressen angelegt wurden. 
• Beheben lässt sich dies durch anpassen der functions.php, siehe auch https://wordpress.stackexchange.com/questions/252328/wordpress-4-7-1-rest-api-still-exposing-users oder alles unter dem Pfad "/wp-json" auf dem Webserver selber mit Hilfe von HTTP-Basic-Auth absichern.
  

2. Brute-Force-Angriff über die XML-RPC Schnittstelle

• Über die xmlrpc.php lassen sich Anfragen zur Authentifizierung per Webservice mit Benutzernamen und das Passwort senden.
• Benötigt man diese Schnittstelle nicht, sollte man die xmlrpc.php deaktivieren. Mit Hilfe des WordPress XML-RPC Validation Service kann man überprüfen, ob der Service aktiv ist.
• Bei GitHub finden sich viele xmlrpc-bruteforcer, mit nur wenigen Schritten, lassen sich so mit Hilfe von einem Python-Script Brute-Force-Angriffe starten.

• Passende Listen mit Passwörtern finden sich z.B. unter https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10k-most-common.txt.
• Die 10 Tausend am häufigsten verwendeten Passwörter lassen sich so in nur wenigen Sekunden mit dem Script überprüfen.
• Deswegen auch hier der Tipp, Passwörter am Besten mit einer Länge von mind. 12 Zeichen immer per Zufall generieren lassen!

 

Swagger - Interface Definition Language (IDL) für REST-APIs

Mit Hilfe des Swagger-Editor unter http://editor.swagger.io oder einem Plug-in für die Entwicklungsumgebung (z. B. für IntelliJ) kann man sehr schnell einen ersten API-Ansatz mit Hilfe der vorhanden Schnittstellenbeschreibung erstellen.

Es kann auch eine bestehende API-Dokumentation per URL importiert werden und der online Editor von Swagger zeigt rechts direkt eine Vorschau der API-Definition in einem "menschenfreundlichen" Format.

Soap UI - SSL Konfiguration und anderes JRE (Java Runtime) verwenden

In einem früheren Beitrag habe ich beschrieben, wie man einen Webservice abfragen kann. Siehe auch http://sebastianhemel.blogspot.de/2015/11/webservice-abfrage-per-konsole-mit-wget.html .

Hier beschreibe ich, wie man bei Soap UI einen eigenen SSL Zertifikatsspeicher verwenden kann und auch die interne Java Runtime von Soap UI durch eine eigene installierte Java Runtime (JRE) zu ersetzen.

1. Eigenen Zertifikatsspeicher erstellen
   1. "C:\Program Files\Java\jre7\bin\keytool" -genkey -alias testcert -keyalg RSA -keystore beispiel.jks
   2. Beliebige Werte für das selbstgenerierte Zertifikat eingeben und das Passwort "changeit" verwenden.
    
2. Das gewünschte Zertifikat in den soeben angelegten Speicher importieren
   1. common-name-test.de.crt
   2. "C:\Program Files\Java\jre7\bin\keytool" -import -alias common-name -keystore "D:\Schnittstellen\keystore\beispiel.jks" -file D:\Schnittstellen\ssl-zert\common-name-test.de.crt
    
3. SOAP-UI Konfig anpassen
   1. C:\Program Files\SmartBear\SoapUI-5.1.3\bin\soapui.bat
   2. Keystore setzen und lokales jre verwenden
      1. set CLIENT_CERT=D:\Schnittstellen\keystore\beispiel.jks
      2. rem set JAVA=%SOAPUI_HOME%..\jre\bin\java
      3. set JAVA=C:\Program Files\Java\jre7\bin\java
      4. set JAVA_OPTS=-Djava.net.preferIPv4Stack=true -Djavax.net.ssl.keyStore=%CLIENT_CERT% -Djavax.net.ssl.keyStorePassword=changeit -Djavax.net.ssl.trustStore=%CLIENT_CERT% -Djavax.net.ssl.trustStorePassword=changeit
   3. SSL-Debug aktivieren
      1.  set JAVA_OPTS=%JAVA_OPTS% -Djsse.enableSNIExtension=false
      2.  set JAVA_OPTS=%JAVA_OPTS% -Djavax.net.debug=ssl,trustmanager
       
4. SOAP-UI mit "soapui.bat" starten

 

Webservice Abfrage per Konsole mit wget

Mit Hilfe von Soap UI kann man Anfragen von Webservices (z.B. Axis2) per GUI testen. Allerdings kann es vorkommen, dass z.B. nur der jeweilige Server eine Firewallfreischaltung für den Webservice hat. Ist dies der Fall, kann man eine Webservice Anfrage auch mittels Konsole und wget durchführen.

Dafür benötigt man folgendes:

• input.xml - Anfrage an den Webservice
• soapResponse.xml - Hier wird der Response vom Webservice hinterlegt
• webservice.sh - Ausführbares shell script mit der wget Anfrage

Inhalt webservice.sh (incl. Basic-Auth und http-header):

wget http://www.xqz.de/axis2/services/WebService --http-user=TEST --http-password=XYZ123 --post-file=input.xml --header="Content-Type: text/xml" --header="user: TEST" --output-document=soapResponse.xml