Dipl.-Inform. Carsten Eilers

2014 kommt eine Schwachstelle, die etwas auf sich hält, anscheinend nicht ohne Namen aus. Das gilt auch für eine SQL-Injection-Schwachstelle in Drupal. Ihr Name: Drupageddon.

Also wirklich - eine SQL-Injection-Schwachstelle bekommt einen Namen? Wenn wir das mit jeder machen, gehen uns bald die Namen aus! SQL Injection in Webanwendungen ist ja nun wirklich nichts besonderes, das kommt mit unschöner Regelmäßigkeit immer wieder vor. Dummerweise hat sich diese Schwachstelle ihren Namen wirklich verdient.

15. Oktober - Drupageddon kündigt sich an

Alles begann am 15. Oktober. Und zwar wirklich alles: Sowohl die Veröffentlichung der Schwachstelle als auch die ersten Angriffe darauf erfolgten am gleichen Tag.

Los ging es mit der Veröffentlichung eines Security Advisory von Drupal: Im Core wurde eine als kritisch eingestufte SQL-Injection-Schwachstelle (CVE-2014-3704) behoben. Die Schwachstelle wurde von Stefan Horst von Sektion Eins entdeckt, der ein eigenes Advisory und einen Blog-Eintrag dazu veröffentlicht hat.

Die Schwachstelle befindet sich im Database Abstraction API, dass eigentlich SQL Injection verhindern soll, und das macht sie besonders unangenehm. Denn dadurch gibt es nicht nur einen Angriffsvektor, sondern etliche. Das API wird ja überall verwendet, wo SQL-Abfragen benötigt werden, es ist also nicht zum Beispiel nur ein einzelnes Formular betroffen. Die Schwachstelle kann über alle möglichen Parameter ausgenutzt werden. Außerdem kann sie ohne vorherige Authentifizierung ausgenutzt werden. Es gibt ja mehr als genug Parameter, die über das API in SQL-Abfragen landen und die auch für nicht angemeldete Benutzer zugänglich sind.

Die Folgen der Schwachstelle sind wirklich kritisch: Da Drupal PDO mit emulierten Prepared Statements verwendet sind mehrere Queries in einem Aufruf erlaubt, so dass unabhängig von der vorgegebenen Abfrage eine beliebige weitere eingeschleust werden kann. Das bedeutet, dass immer beliebige Daten in die Datenbank eingetragen werden können, auch wenn bei der ursprünglichen Abfrage nur Daten abgefragt werden. Letztendlich erlaubt das die Ausführung beliebigen PHP-Codes über Drupal-Features mit Callbacks. Außerdem kann PHP-Code auch direkt aus der Datenbank heraus ausgeführt werden.

Noch am 15. Oktober tauchten die ersten Exploits für die Schwachstelle auf, zum Beispiel auf Pastebin. Dieser Exploit basiert auf einem auf Reddit veröffentlichten SQL-Code, über dessen Herkunft nichts bekannt ist.

Übrigens wurde der Fehler schon im November 2013 an Drupal gemeldet, allerdings nicht über den Kanal für Schwachstellen. Und daher auch nicht als Schwachstelle erkannt. Obwohl es ein (wohl frei vergebenes) Tag #security gab. Hmmm... sollte man in Zukunft sicherheitshalber alle Fehler direkt als Schwachstelle melden, sicher ist sicher?

16. Oktober - Drupageddon ist da

Am 16. Oktober hat Tamer Zoubi beschrieben, wie er innerhalb von 30 Minuten ausgehend vom Patch einen Exploit entwickeln konnte. Zu diesem Zeitpunkt wurde die Schwachstelle bereits ausgenutzt: Steven Adair von Volexity meldete sowohl Massenscans nach der Schwachstelle als auch gezielte Angriffe auf einzelne Server.

Nach und nach wurden immer mehr Angriffsmethoden entdeckt.

29. Oktober - Drupal warnt vor seit 14 Tagen kompromittierten Servern

Erst am 29. Oktober hat Drupal erneut reagiert und ein "Public Service Announcement" veröffentlicht, in dem man vor den Angriffen auf und Kompromittierungen über die Schwachstelle warnt. Man sollte sicherheitshalber davon ausgehen, dass alle Websites, die nicht spätestens 7 Stunden nach der Veröffentlichung des Security Advisories am 15. Oktober. d.h. bis um 11pm UTC am 15. Oktober entsprechend 1 Uhr MESZ am 16. Oktober gepatcht waren, nun kompromittiert sind. Angesichts der Uhrzeiten dürfte das sehr viele Drupal-Websites in Europa betreffen.

Kommt diese Warnung nicht etwas spät? Warum hat man den Cyberkriminellen 14 Tage Zeit gelassen, auf den kompromittierten Servern Unheil anzurichten und zum Beispiel Drive-by-Infektionen darüber zu verbreiten? Doch hoffentlich nicht wirklich, weil PSA immer Mittwochs veröffentlicht werden? Das wäre ja - also, dazu fällt mir kein Vergleich ein. Und auch kein veröffentlichbarer Kommentar.

Das Kind liegt im Brunnen. Seit 14 Tagen.

Es reicht also nicht mehr aus, einfach nur den Patch zu installieren, da dadurch eine möglicherweise installierte Backdoor nicht entfernt wird. Wer seine Drupal-Installation nicht rechtzeitig aktualisiert hat, kommt um das Einspielen eines vor dem 15. Oktober erstellten Backups plus Installation des Updates oder Patches nicht herum. Auch dann nicht, wenn man keine Spur einer Backdoor findet. Denn es gibt einfach zu viele Möglichkeiten, wie und wo eine Backdoor installiert werden kann. Und selbst wenn man eine Backdoor findet, reicht es nicht aus, nur die Backdoor zu entfernen. Denn dann weiß man zwar, dass der Server kompromittiert wurde, aber nicht, ob die gefundene auch die einzige installierte Backdoor war.

Ach ja: Wenn ein Server kompromittiert wurde und dabei Benutzerdaten ausgespäht wurden ist der Server-Betreiber dafür verantwortlich, die Benutzer zu informieren. Ich bin gespannt, wie sich das entwickelt.

Ein Angriff hinterlässt wirklich keine Spuren in Logfiles

Nur der Vollständigkeit halber sei erwähnt, dass Stefan Horst am 3. November einen Proof of Concept veröffentlicht hat. Da es schon mehr als genug Exploits gibt, war der eigentlich nicht mehr nötig. Die Möglichkeit der Ausnutzung der Schwachstelle wurde ja schon durch die ganzen Angriffe bewiesen. Der PoC ist aber aus einem anderen Grund interessant: Er verwendet nur einen einzigen GET-Request, und der Exploitcode wird als Cookie übertragen, erscheint also in keinem Logfile.

Carsten Eilers