Loading...
Blogs & Stories

SpiderLabs-Blog

Mit mehr als einer halben Million Lesern pro Jahr ist dies die Anlaufstelle der Sicherheitsgemeinschaft für technische Informationen zu den neuesten Bedrohungen, Informationen zu kritischen Sicherheitslücken und aktuellen Forschungsergebnissen.

SQL-Injections in WordPress-Plugins: übersehene Injection Points ORDER und ORDER BY

Trustwave SpiderLabs hat kürzlich eine Untersuchung von etwa 100 beliebten WordPress-Plugins auf mögliche SQL Injection-Schwachstellen durchgeführt. Die gute Nachricht ist, dass in der überwiegenden Mehrheit keine derartigen Schwachstellen gefunden wurden. Es wurde festgestellt, dass die meisten Plugins entweder Prepared Statements oder eine geeignete SQL-Sanitisierung verwenden, wenn sie benutzergesteuerte Daten in eine Query einbinden. Bei den identifizierten fünf anfälligen Plugins fielen einige Muster auf, unter anderem, dass vier von fünf nur in einer der oder in beiden ORDER- und ORDER BY-Klauseln anfällig waren.

In jedem dieser Fälle wurden die Schwachstellen den jeweiligen Anbietern aufgezeigt. Als dieser Artikel geschrieben wurde, war eine der vier Schwachstellen noch nicht behoben, diese wird daher hier nicht benannt (aber bleiben Sie dran für zukünftige Beiträge). Die anderen drei Plugin-Schwachstellen (mit jeweils mehr als 10.000 aktiven Installationen) waren:

  • Membership & Content Restriction – Paid Member Subscriptions < 2.4.2. -- Der Parameter „order“ war bei der Suche auf der Seite „Members“ anfällig, während sowohl „order“ als auch „order-by“ in der Suche auf der Seite „Payments“ anfällig waren.
  • WP Simple Booking Calendar <= 2.0.6. -- Der Parameter „order-by“ in der Aktion „Search Calendars“ war anfällig.
  • Stop Bad Bots <= 6.59 -- Die Parameter „order“ und „order-by“ waren auf drei unterschiedlichen Seiten anfällig.

Weitere, überwiegend gute Nachrichten

Die Verwendung von ORDER und ORDER BY als Injection Points schränkt Angreifer enorm ein. Da diese Injection Points herkömmliche Datenexfiltration wie UNION nicht unterstützen, sind Hacker bei Anfragen in der Regel auf einfache Ja/Nein-Antworten beschränkt.

Zahlreiche Anfragen zu stellen, kann immer noch ein praktikabler Weg sein, hochwertige Daten zu extrahieren. Einzelne Anfragen sind meistens von geringem Nutzen.

Noch mehr überwiegend gute Nachrichten

Ein weiterer Faktor, der zum geringen Schweregrad dieser Schwachstellen beiträgt, ist, dass keine Schwachstelle ohne Authentifizierung oder mit geringen Rechten ausgenutzt werden kann.

Nennenswerte Schlussfolgerungen

  • Auch wenn sie weniger besorgniserregend sind, sollten Entwickler diese beiden potenziellen Injection Points nicht übersehen.
  • Ein häufiges Muster bei den Schwachstellen war, dass die Anfrageparameter „order“ und „order-by“ während der normalen, legitimen Funktionalität nie wirklich vom Client gesendet wurden, obwohl ähnliche Parameter von der Anwendung auf dem Server ausgeführt wurden.

Möglicherweise handelte es sich dabei um früher aktiv genutzte Funktionen, aber der Client-Code wurde so weiterentwickelt, dass diese Parameter nicht mehr übermittelt wurden. Zumindest in einigen Fällen könnte es auch sein, dass die Parameter tatsächlich aktiv in der „Pro“-Version des Plugins verwendet werden. In jedem Fall erinnert es daran, dass alles, was einem Dead Code ähnelt, eine Schwachstelle darstellen kann.

Der Tipp in diesem Zusammenhang aus der Research-Perspektive: Besteht der Ansatz darin, normale Anfragen zu erfassen und dann ein Tool wie sqlmap nur gegen die Parameter laufen zu lassen, die in der normalen Anfrage vorhanden sind, können einige Schwachstellen übersehen werden.

  • Es ist üblich, die versuchte SQL-Sanitisierung relevanter Parameter zu erkennen. Zum Beispiel enthielt das erste der drei oben aufgeführten Plugins diesen Code, der dann mit zusätzlichem Inhalt verkettet wurde, um eine ausgeführte Query zu erstellen:

$args [‘orderby‘] = sanitize_text_field ($_REQUEST[‘orderby‘] );

$args [‘order] = sanitize_text_field ($_REQUEST[‘order‘] );

Unglücklicherweise ist diese spezielle Sanitisierungs-Funktion für das, was hier erforderlich ist, unwirksam. Verwenden Sie Sanitisierung anstatt Prepared Statements, dann achten Sie darauf, was die SQL-Sanitisierung einer bestimmten Funktion tatsächlich durchführt und ob diese den Erfordernissen entspricht.

Der beste Weg, SQL Injection-Attacken zu vermeiden, ist die Verwendung von Prepared Statements. Wenn Sie jedoch im Zuge der SQL-Sanitisierungen ORDER- und ORDER BY-Klauseln verwenden, ist die beste Sanitisierung die Verwendung eines positiven Sicherheits-Modells. Stellen Sie beispielsweise sicher, dass der ORDER-Parameter exakt „asc“ oder „desc“ ist, und bestätigen Sie, dass der ORDER BY-Parameter exakt einer der erwarteten Spaltennamen ist.

Verweise

TWSL2021-012: Vulnerabilities in WordPress Plugin Membership & Content Restriction ­­­­­– Paid Member Subscriptions

TWSL2021-013: Authenticated SQL Injection in WordPress Plugin Stop Bad Bots

TWSL2021-014: Authenticated SQL Injection in WordPress Plugin WP Simple Booking Calendar

Verwandte SpiderLabs-Blogs