Category: wordpress

Bug in Login With Ajax Plugin erstellt Nutzeraccounts

29.08.2014 yahe legacy security wordpress

Anfang dieser Woche hatte ich über ein Plugin informiert, mit dem ein Angreifer ungefragt neue Nutzer anlegen kann. Damit ist das vorgestellte Plugin leider nicht allein. Denn auch das Login With Ajax Plugin hat diese unschöne Sonderfunktion.

In der Datei "login-with-ajax.php" befindet sich die Klasse "LoginWithAjax", die man mit einem präparierten Formular dazu bringen kann, neue Accounts anzulegen, selbst dann, wenn die Registrierung neuer Nutzer eigentlich in der Wordpress-Konfiguration ausgeschaltet wurde:

<form action="http://example.com/" method="POST">
  <input type="hidden" name="lwa" value="true" />
  <input type="hidden" name="login-with-ajax" value="register" />
  <input type="hidden" name="user_login" value="exploit" />
  <input type="hidden" name="user_email" value="exploit@example.com" />
  <input type="submit" />
</form>

Ich bekam vor mehreren Wochen von den Entwicklern die Aussage, dass sie das Problem ASAP beheben würden. Seitdem ist jedoch nichts mehr geschehen. Der Tipp an dieser Stelle kann deshalb nur lauten, das Plugin zu deaktivieren, bis es ein Update gegeben hat. Viele andere Plugins prüfen häufig lediglich, ob ein Nutzer eingeloggt ist, bevor sie ihre Funktionalität bereitstellen. diese Absicherung kann aufgrund des Bugs derzeit umgangen werden.

Update

In der Version 3.1.3 wurde dieser Fehler nun endlich behoben.


Bug in Quick Chat Plugin erlaubt SQL-Injection

27.08.2014 yahe legacy security wordpress

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. Diese wird immer dann aufgerufen, wenn ein Nutzer eine neue Nachricht schreibt. Auch in der Methode "update_users_ajax_handler()" kommt dieser Wert ungeprüft zum Einsatz. Sie wird regelmäßig aufgerufen, 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

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 lautet, die Plugins sofort zu deaktivieren und auf ein Update zu warten.


Bug in WP Modal Login Plugin erstellt Nutzeraccounts

25.08.2014 yahe legacy security wordpress

Heute mal ein spannender Bug: Das WP Modal Login Plugin 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:

[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

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 keine Zeit mehr für die Pflege des Plugins hat, hat er sich dazu entschlossen, das Plugin aus dem Plugin-Repository zu entfernen.


Bug in WordPress File Upload Plugin erlaubt XSS

22.08.2014 yahe legacy security wordpress

Manchmal kann bereits das Bereitstellen von Fehlerinformationen zu viel des Guten sein, so zum Beispiel beim WordPress File Upload Plugin. Dieses bietet Nutzern 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:

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:

<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.


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

21.08.2014 yahe legacy security 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.


Search

Links

RSS feed

Categories

administration (40)
arduino (12)
calcpw (2)
code (33)
hardware (16)
java (2)
legacy (113)
linux (27)
publicity (6)
review (2)
security (58)
thoughts (21)
windows (17)
wordpress (19)