Bug in Quick Chat Plugin erlaubt SQL-Injection

In dem WordPress-Plugin Quick Chat befinden sich Bugs, die es einem Angreifer ermöglichen, SQL-Injections durchzuführen. Das Plugin ist dafür gedacht, einen einfachen Chat im eigenen Blog bereitzustellen.

Das Problem beginnt im Constructor der Klasse "Quick_Chat", der sich in der Datei "quick-chat.php" befindet: Dort wird versucht, die IP-Adresse des Clients in Erfahrung zu bringen. Dabei wird auch der HTTP-Header "X-Forward-For" mit berücksichtigt.

Dieser Wert wird dann (ungeprüft) in der Methode "new_message_ajax_handler()" in einem INSERT-Statement verwendet - also immer dann, wenn ein Nutzer eine neue Nachricht schreibt. Auch in der Methode "update_users_ajax_handler()" kommt dieser Wert ungeprüft zum Einsatz - also regelmäßig, wenn der Status der Clients aktualisiert wird. Ausnutzen kann man das ganze, indem man einfach den "X-Forward-For"-Header mit seinem SQL-Injection-Code versieht. Das ganze kann dann zum Beispiel so aussehen:

Quick Chat Injection

Quick Chat Injection

Hier habe ich das Tool Charles verwendet, um einen präparierten Header einzufügen. Dieser bewirkt, dass nicht der vom Nutzer geschriebene Text im Chatraum erscheint, sondern das (gehashte) Passwort vom WordPress-User mit der ID "1".

Auch das Plugin Quick Count verwendet in der Datei "quick-counter.php" einen ähnlichen Code in der Methode "report()" und sollte dadurch mit ähnlichen Problemen zu kämpfen haben.

Der Rat an dieser Stelle: Die Plugins sofort deaktivieren und warten, bis es ein Update gibt.

Injizierende Grüße, Kenny

Bug in WP Modal Login Plugin erstellt Nutzeraccounts

Heute mal ein spannender Bug: Das WP Modal Login bietet einem die Möglichkeit, überall auf der Seite einen Login-Screen aufzurufen. Dafür richtet man an der entsprechenden Stelle einfach einen Shortcode ein - das Login-Formular wird dann einfach als Overlay angezeigt:

1
[wp-modal-login login_text="Login" logout_text="Logout"]

Leider hat das ganze einen kleinen Schönheitsfehler, denn die Klasse "./includes/class-wp-modal.php" enthält nicht nur die Funktion, sich einzuloggen, sondern sie kann auch neue Nutzer anlegen. Das funktioniert sogar dann, wenn die Registrierung neuer Nutzer in der WordPress-Konfiguration deaktiviert wurde. Die Funktion wird zwar nicht über das Login-Formular bereitgestellt, aber es verarbeitet trotzdem entsprechende Anfragen.

Exploit mit Charles Proxy

Exploit mit Charles Proxy

Das ist sehr unglücklich, denn viele andere Plugins verlassen sich darauf, dass ein Angreifer keinen Account für die Webseite hat. Oft bestehen Sicherheitsabfragen nur daraus, zu prüfen, ob ein Nutzer eingeloggt ist oder nicht.

Da der Entwickler laut der Projekt-Webseite keine Zeit mehr für die Pflege des Plugins hat, kann der Rat nur lauten, das Plugin so schnell wie möglich zu deaktivieren. Der Entwickler hat sich - nach Rücksprache mit mir - jedenfalls dazu entschlossen, das Plugin aus dem Plugin-Repository zu entfernen.

Registrierende Grüße, Kenny

Bug in WordPress File Upload Plugin erlaubt XSS

Manchmal kann bereits das Bereitstellen von Fehlerinformationen zu viel des Guten sein - so zum Beispiel beim WordPress File Upload.

Dieses bietet Nutzern - wie der Name schon sagt - die Möglichkeit, Dateien hochzuladen. Dafür kommt AJAX zum Einsatz. In der Datei "./lib/wfu_ajaxactions.php" werden dazu die entsprechenden Handler bereitgestellt. Sollte etwas fehlgeschlagen (zum Beispiel die Session-Prüfung) bekommt der Nutzer nützliche Informationen als Rückantwort. Dies sah bisher so aus:

1
2
3
4
5
6
7
if ( $_SESSION["wfu_token_".$arr['shortcode_id']] != $_POST['session_token'] ) {
     echo "Session failed!<br/><br/>Session Data:<br/>";
     print_r($_SESSION);
     echo "<br/><br/>Post Data:<br/>";
     print_r($_POST);
     die();
}

Das ist jedoch ziemlich problematisch, denn "print_r()" escaped Ausgaben nicht. Es ist also möglich, mit einem präparierten POST-Request beliebige Texte ausgeben zu lassen. Das ganze lässt sich zum Beispiel mit einem einfachen HTML-Formular realisieren:

1
2
3
4
5
<form action="http://example.com/wp-admin/admin-ajax.php" method="POST">
  <input type="hidden" name="action" value="wfu_ajax_action" />
  <input type="hidden" name="session_token" value="<script>alert(1+1);</script>" />
  <input type="submit" />
</form>

In der nun veröffentlichten Version 2.4.4 ist das Problem beseitigt worden. Es ist daher anzuraten, das Plugin so schnell wie möglich upzudaten.

Präparierte Grüße, Kenny

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

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, dass man Webformulare per Drag&Drop erstellen und einfach im Blog auf Seiten und in Beiträgen einbinden kann.

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 absolut 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:

1
2
3
4
5
<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. :)

Formulierende Grüße, Kenny

Information Leakage im Simplr Registration Form Plus+ Plugin

Zur Abwechslung mal nur ein kleineres Problem: Dieses Mal im Simplr Registration Form Plus+ Plugin.

Dort ist es möglich, die Datei "simplr-registration-form/simplr_reg_options.php" direkt aufzurufen. Darin befindet sich dann eine Liste aller statischen Seiten der WordPress-Webseite - also auch solche, die nicht öffentlicht verlinkt sind.

Direkte Grüße, Kenny

Seite 1 von 80123...Letzte »