dungsocool/cve-2018-7600Schritt-für-Schritt-Laboranleitung zur Ausnutzung von CVE-2018-7600 (Drupalgeddon2) RCE in Drupal 8.5.0, einschließlich Angriffsflächenanalyse, Versions-Fingerprinting und Ausnutzung über Form-API-Injection.
Beginnen Sie mit der Auflistung der laufenden Container:
docker ps
Aus den docker ps-Ergebnissen ergibt sich der Container für dieses Labor:
p1/lab09:latest
Dieser Container exponiert den Port:
0.0.0.0:8011->80/tcp
Dies zeigt an, dass der Dienst im Container auf Port 80/tcp lauscht und auf Port 8011 des Hosts abgebildet wird.
Port 80/tcp ist der Standardport für HTTP. Daher handelt es sich bei diesem Ziellabor höchstwahrscheinlich um eine HTTP-Webanwendung. Um den Webdienst zu bestätigen, sende ich eine HTTP-Anfrage mit curl und greife zusätzlich auf die GUI der Webseite zu.
curl -i http://192.168.3.137:8011/
Bewertung der Angriffsfläche
Aus der HTTP-Antwort und der Weboberfläche wurden die folgenden Informationen ermittelt:
Web server: Apache/2.4.25 (Debian) Backend: PHP/7.2.3 CMS: Drupal Drupal version: 8.5.0 Install path: /core/install.php Public port: 8011 -> 80/tcp
Diese Informationen dienen als entscheidende Fingerprints, um sie mit CVEs abzugleichen. Insbesondere Drupal 8.5.0 ist die Version, die direkt mit CVE-2018-7600, auch bekannt als Drupalgeddon2, in Zusammenhang steht.
Laut der offiziellen Drupal-Sicherheitsmeldung sind die folgenden Versionen von SA-CORE-2018-002 / CVE-2018-7600 betroffen:
>= 8.5.0 < 8.5.1
Das aktuelle Ziel läuft mit:
Drupal 8.5.0
und liegt damit im betroffenen Versionsbereich.
⇒ Überlegung:
In diesem Stadium ist die Drupal-Version 8.5.0 ein starkes Indiz, um das vermutete CVE zu identifizieren. Ich argumentiere wie folgt:
docker ps zeigt, dass das Labor den HTTP-Dienst über Port 8011 exponiert.curl -i liefert eine gültige HTTP-Antwort von Apache/PHP./core/install.php um.Drupal >=8.5.0 <8.5.1 von CVE-2018-7600 betroffen ist.Drupal 8.5.0 und erfüllt damit die Versionskriterien, um CVE-2018-7600 zu testen.Das Ziel ist Drupal 8.5.0, das auf Apache/PHP läuft. Diese Version liegt gemäß der offiziellen Drupal-Sicherheitsmeldung im von CVE-2018-7600 betroffenen Bereich. Der nächste Schritt besteht darin, die tatsächlichen Ausnutzungsbedingungen zu prüfen, um zu verifizieren, ob das Ziel einer RCE ausgesetzt werden kann.
Aus dem vorherigen Fingerprinting-Schritt zeigt das Ziel deutlich Drupal 8.5.0 an. Laut der offiziellen Sicherheitsmeldung von Drupal betrifft die Schwachstelle SA-CORE-2018-002 / CVE-2018-7600 die Drupal-Core-Versionen:
>= 8.5.0 < 8.5.1. Das aktuelle Ziel läuft exakt mit Drupal 8.5.0 und liegt damit im betroffenen Versionsbereich. Laut der Drupal-Sicherheitsmeldung handelt es sich um eine Remote Code Execution-Schwachstelle im Drupal-Core, die es einem Angreifer ermöglichen könnte, mehrere Angriffsvektoren auszunutzen und die Kompromittierung der gesamten Website herbeizuführen.
Allerdings ist zu erkennen, dass das Ziel auf /core/install.php umleitet und die GUI den Drupal-Installationsbildschirm anzeigt. Dies deutet darauf hin, dass sich Drupal möglicherweise in einem unvollständigen Installationszustand befindet. Wenn die Einrichtung der Website nicht abgeschlossen wurde, funktionieren gängige Endpunkte, die zum Auslösen von Drupalgeddon2 verwendet werden, wie /user/register, /user/password und /user/login, möglicherweise nicht ordnungsgemäß. Daher ist es notwendig, diese Endpunkte zu überprüfen.
curl -i http://192.168.3.137:8011/user/register curl -i http://192.168.3.137:8011/user/password curl -i http://192.168.3.137:8011/user/login
Es ist zu erkennen, dass die Endpunkte weiterhin auf /core/install.php umgeleitet werden.
Fazit:
Das Ziel läuft mit Drupal 8.5.0 und fällt damit gemäß der offiziellen Drupal-Sicherheitsmeldung in den von CVE-2018-7600 betroffenen Versionsbereich. Zum Zeitpunkt des Tests befindet sich die Anwendung jedoch in einem Installer-Zustand und leitet Routen wie /user/register, /user/password und /user/login kontinuierlich auf /core/install.php um.
Dies zeigt, dass die Endpunkte, die üblicherweise zur Verifizierung von Drupalgeddon2 verwendet werden, noch nicht so funktionieren, wie sie es auf einer vollständig installierten Drupal-Site tun würden. Daher erfüllt das Ziel derzeit nur die Versionsbedingung, erfüllt jedoch noch nicht die Laufzeitbedingungen, um Remote Code Execution nachzuweisen.
=> Überlegung:
Wir müssen weiterhin nachweisen, dass Drupal in seinem Laufzeitzustand die anfälligen Routen/Formulare verarbeiten kann, dass ein Angreifer die Endpunkte ohne Authentifizierung erreichen kann und dass Verifikations-Payloads wie id erfolgreich ausgeführt werden können.
Beim aktuellen Ziel leiten die Endpunkte auf den Installer um. Der nächste Weg besteht darin, zu bewerten, ob der Drupal-Installationsbildschirm eine eigene Angriffsfläche schafft, anstatt sofort auf eine Drupalgeddon2-RCE zu schließen.
Nachdem ich überprüft hatte, dass die Drupal-Laufzeitendpunkte wie /user/register, /user/password und /user/login alle auf /core/install.php umgeleitet werden, bin ich dazu übergegangen, den Installationsbildschirm zu analysieren.
Überprüfung des Datenbankdienstes, der den Installer unterstützt
Da der Drupal-Installer derzeit beim Datenbankkonfigurationsschritt angehalten ist, habe ich überprüft, ob gängige Datenbankdienste extern exponiert sind:
nmap -sV -p 3306,5432,33060 192.168.3.137
Das Ziel exponiert derzeit den Drupal installer extern, es wurden jedoch keine Datenbankdienste erkannt, die direkt vom Rechner des Angreifers aus erreichbar sind.
Fazit: Das Labor exponiert den Drupal-8.5.0-Installer und weist eine Informationsoffenlegung bezüglich der anfälligen Version. CVE-2018-7600 ist ein valider vermuteter Vektor, aber eine erfolgreiche Ausnutzung wurde noch nicht nachgewiesen.
CVE-2018-7600 nutzt eine Schwachstelle in der Drupal Form API aus - dem Formular-Rendering-System, das die Render-Array-Struktur verwendet. Bei der Verarbeitung einer AJAX-Anfrage verwendet Drupal den Parameter element_parents, um Elemente im Formularbaum zu lokalisieren, ohne Schlüssel zu überprüfen (zu bereinigen), die mit dem Zeichen # beginnen. Angreifer injizieren Eigenschaften wie #post_render, #markup und #type über POST-Daten, um die Rendering-Engine zu zwingen, beliebige PHP-Funktionen (z. B. exec, passthru, system) auszuführen.
Voraussetzung: Mindestens ein Endpunkt, der die Form API verwendet, muss eine gültige Antwort zurückgeben (nicht umgeleitet, nicht durch Zugriffskontrolle blockiert), damit der Angreifer eine AJAX-Anfrage mit dem Payload senden kann.