SELECT * FROM pg_shadow;

Quelle: Caspar Camille Rubin / Unsplash

Damit die Studierenden der Universität Leipzig fleißig SQL Befehle üben können, war der Lehrstuhl so freundlich, ihnen eine Plattform dafür bereitzustellen. Das "Leipzig Online Test System" kurz Lots. Hier kann man sich wild austoben und eine Datenbank über Bücher und Autor:innen nach Herzenslust abfragen. Aber nicht nur Wissen über Bücher konnte man dem System entlocken!

Das Backend bildet eine Java App und eine Postgres Datenbank. Es ist also ein echter Datenbankserver, der im Hintergrund arbeitet und keine simulierte Umgebung. Das bedeuted, dass das System sicherheitstechnische Leitplanken braucht. Auch die Mitarbeitenden des Lehrstuhls werden wohl wissen, dass einem Bachelor Studenten auch schnell mal die Finger auf der Tastatur ausrutschen können und plötzlich wird ein "DROP" statt eines "SELECT" an den Server geschickt. Doch wenn man von diesem low hanging Fruits absieht, kann man noch andere auch sehr low hangende Fruits ergattern, denn die Lots Datenbank ist genauso auskunftsfreudig über sich selbst, wie zum Thema Bücher.

So konnte der Datenbank-User per "SELECT current_user" abgefragt oder sich im System umgeschaut und durch die Config Dateien gestöbert werden. Nachdem ich mich ein bisschen in das Innenleben von Postgres eingelesen habe, stieß ich noch auf die pg_shadow Datei, die die Passwörter der User als MD5 Hash enthält. Für MD5 gibt es ausreichend Rainbow Tables im Netz zu finden, die zumindest gängige Passwörter als Hashes enthalten. Und das Passwort des Users war mehr als gängig.

Ein Screenshot des Lots Systems, der die pg_shadow Datei (geschwärzt) zeigt.

Ein kleiner Ausflug

Das Lots System ist mehr als elf Jahre alt. Interessierte können es hier finden. Mit ein bisschen stöbern in den Quelldateien, stößt man auf die Sicherheitsmaßnahmen, um unbefugtes Verhalten zu verhindern. Hier in den Untiefen der Javawelt evaluiert ein String Matching, ob die Anfrage eines der bösen Wörter wie z.B. "DROP" enthält. Auch das Verändern von Berechtigungen wird unterbunden oder das Erstellen von Tabellen. Allerdings wurden nicht alle SQL Befehle abgefangen, mit dem man Böses anfangen kann.

Und was sind nun die Angriffsvektoren?

DOS Angriffe

Nicht abgefangen von der App, werden Befehle wie "TRUNCAT" und "REVOKE". So kann man mit letzterem dem Datenbank User die Berechtigungen entziehen, sodass das System nicht mehr zu verwenden ist. Auch vergisst das String Matching vollkommen Postgres interne Befehle, wie z.B. "pg_terminate_backend" wonach der Spaß natürlich auch schnell vorbei ist.

Persistent XSS

Persistent XSS ist ein Angriff, bei dem die Angreiferin Code in die Datenbank einschleust, der dann von der App später an einen Nutzer ausgegeben wird. Ermöglicht wird das Ganze dabei per "SELECT INTO".

Ich habe ja das Passwort (╭ರ_•́)

Um auf vorhin zurückzukommen: Das Passwort stand ja als MD5 Hash in der pg_shadow Datei. Das heißt, ich kann mich einfach einloggen? So leicht war es leider nicht. Denn eine wertvolle Konfiguration hatte der Lehrstuhl dann doch getan. Die IP Adressen Ranges konnte ich dabei aus einer der Config Dateien entnehmen. "Leider" waren zwei IP-Adressen mit /32 CIDR Ranges spezifiziert. Wie ich mir von einem Kontakt bestätigen ließ, sind das je die IP-Adressen von dem Büro des zuständigen Mitarbeiters an der Uni und am SCADS.AI. Also: keine Chance.

Responsible Disclosure

Die Sicherheitslücken wurden rasch geschlossen, nachdem ich das Problem nach Neujahr an den Lehrstuhl und zuständige Personen kommuniziert hatte. Ich hab einen Call geführt mit zwei Personen aus der Arbeitsgruppe, die mir meine Angriffsvektoren so nochmal bestätigt haben.

Niclas Stoffregen, 14.01.2022