Bug in Form Builder Plugin ermöglicht vollständige Kompromittierung

21.08.2014 yahe legacy security update wordpress

Und wieder einmal ist mir ein besonders fieser Bug über den Weg gelaufen. Dieses mal habe ich ihn im Form Builder Plugin gefunden. Form Builder ist dafür gedacht, Webformulare per Drag&Drop zu erstellen und einfach im Blog auf Seiten und in Beiträgen einbinden zu können. Das ganze funktioniert, indem man einen "form"-Tag mit einer zugehörigen ID in den Seitentext schreibt. Das Plugin klinkt sich in den "the_content"-Hook ein, sucht nach dem "form"-Tag, nimmt die ID, geht damit gegen einen Server des Plugin-Anbieters und ruft das HTML des Formulars ab, um es anzuzeigen.

Zum Abrufen haben die Entwickler des Plugins eine eigene Klasse namens "formHttpRequest" geschrieben, die sich in der Datei "includes/http.class.php" befindet und per CURL die Serveranfragen stellt. Leider benimmt sie sich dabei etwas merkwürdig. Anstatt einfach nur eine Anfrage an den Server zu stellen, bereitet sie vorher jede Menge vor, unter anderem nimmt sie in der Methode "connect()" alle per POST gesendeten Dateien an und versucht sie in den Uploads-Ordner zu schreiben (normalerweise "./wp-content/uploads/"). Aufgrund eines fehlenden Slashes misslingt das aber, sodass die Dateien anschließend z.B. "./wp-content/uploadstest.txt" heißen, wenn die ursprünglich hochgeladene Datei "test.txt" hieß.

Die hochgeladenen Dateien werden zwar nach Beenden des Requests wieder gelöscht, während der Request noch läuft können sie jedoch aufgerufen werden. Da man zudem beliebig viele und (von der Serverkonfiguration abhängig) auch beliebig große Dateien mitschicken kann, kann die für den Request benötigte Zeit auch beliebig verlängert werden. Sollte der Server des Pluginanbieters zudem den Request mit einem Fehler beantworten, werden die Dateien gar nicht mehr entfernt.

Der Exploit-Code ist simpel. Der POST-Request muss einfach gegen eine Seite des Blogs gerichtet werden, auf der sich ein entsprechendes Formular befindet. Während der Exploit läuft, muss man dann nur versuchen, seine hochgeladene Datei aufzurufen:

<form enctype="multipart/form-data" action="http://example.com/example" method="POST">
    <input type="hidden" name="MAX_FILE_SIZE" value="30000" />
    Uploads: <input type="file" name="file[]" multiple="multiple" />
    <input type="submit" />
</form>

Es ist bisher nicht bekannt, ob diese Lücke bereits aktiv zum Angreifen von WordPress-Blogs verwendet wurde. Der Fehler wurde in der aktuellen Version 2.4.2 zumindest gemindert. Die Dateien werden zwar immer noch verarbeitet, verbleiben nun jedoch zumindest im temporären Upload-Ordner von PHP (z.B. "/tmp"). Installationen, bei denen der temporäre Upload-Ordner über das Web erreichbar ist, bleiben damit weiterhin angreifbar. Trotzdem sollten alle Nutzer dieses Plugins schnellstmöglich updaten.

Update

Ich hatte noch einmal Kontakt mit den Entwicklern gehabt, die nun eine neue Version 2.4.3 mit einem wesentlich besseren Lösungsansatz veröffentlicht haben.