Anfang des Jahres erteilte ein Kunde unseren Kollegen von G DATA Advanced Analytics den Auftrag, unter anderem eine von ihm eingesetzte Webanwendung namens „TOPqw Webportal“ des Kieler Softwareherstellers baltic IT einem Penetrationstest zu unterziehen.
Vollzugriff
Dabei fiel auf, dass es auf triviale Art und Weise möglich war, den kompletten Inhalt von Datenbanken einzusehen. Dazu hätte ein Angreifer lediglich einige Daten in der Übertragung ändern müssen. Möglich war das durch eine so genannte „SQL-Injection“. Dort gibt ein Angreifer effektiv Datenbankbefehle ein, die vom dahinterliegenden Datenbankserver ohne Hinterfragen ausgeführt werden. Mit einem frei zugänglichen Werkzeug lassen sich sämtliche Daten sowie auch die Datenbankstruktur ohne Weiteres auslesen. Unter anderem waren in der Datenbank Namen, E-Mailadressen und auch (gehashte) Passwörter lesbar. Für den Zugriff war kein Passwort erforderlich. „Das hätte ich vielleicht in einem CTF-Wettbewerb für Einsteiger erwartet – aber nicht hier“, meint Analyst Maximilian Hildebrand. „Man kann schon sagen, dass das ein ziemlicher Anfängerfehler war.“
Immerhin: Die Sicherheitslücke (CVE-2024-45876) erlaubte keine Ausführung von Code auf dem Datenbankserver. Doch der Zugriff allein war bereits schlimm genug, insbesondere vor dem Hintergrund, dass in der Datenbank persönliche Informationen über Empfänger von Sozialleistungen hinterlegt waren.
Anlegen neuer Benutzer
Eine Funktion, die neue Benutzer in der Datenbank anlegt, war ebenfalls über eine SQL-Injection angreifbar. (CVE-2024-45875) Ursprünglich war die Nutzung der Funktion nur durch einen Administrator vorgesehen, der über die Webanwendung einen neuen Benutzer-Account einrichtet. Im Hintergrund setzt das Programm einen Befehl in die Datenbank ab, in der das Konto angelegt wird. Da ein hypothetischer Angreifer jedoch die Möglichkeit hat, mit Hilfe dieser Schwachstelle direkt auf die Datenbank zuzugreifen, und eigenen SQL-Code einzuschleusen, kann er aus dieser Funktion “ausbrechen”. Das erlaubt ihm wiederum vollen Zugriff auf den gesamten Inhalt der Datenbank.
Im Verbund mit der nächstgenannten Sicherheitslücke ist dies sogar mit Hilfe eines beliebigen Benutzerkontos möglich und erfordert somit zur Ausnutzung keine administrativen Berechtigungen mehr.
Zugriff auf Admin-Komponenten
Nutzer, die nicht über entsprechende Freigaben verfügen, können auf administrative Komponenten der Webanwendung zugreifen, indem sie einfach die Adresse im Browser entsprechend anpassen. Hier ist also die Zugriffskontrolle nicht korrekt implementiert (CVE-2024-45877). Das erlaubt es jedem angemeldeten Benutzer, andere Benutzerkonten einzusehen, sowie bestehende Konten zu löschen oder neue anzulegen. Damit wäre es bei einem Angriff beispielsweise möglich, sämtliche Benutzer auszusperren. Auch die Manipulation von Daten ist möglich. Über das Kalkulationsmodul der Anwendung lassen sich auch bösartige Dateien einschleusen.
Unterschieben von fremdem Javascript-Code per XSS
Hier bestehen sogar zwei Sicherheitslücken (CVE-2024-45878 und CVE-2024-45879). Beide erlaubten es einem Angreifer, eigenen Javascript-Code in die Webanwendung zu schleusen. Da die Plattform Dateinamen an einer Stelle nicht validiert, und an einer anderen Stelle Javascript als Protokoll zulässt, ist es möglich, auch bösartige Skripte im Kontext der Webanwendung laufen zu lassen.
Fazit
Einige der Sicherheitslücken waren mehr als trivial zu finden und auszunutzen. Gerade weil TOPqw hoch sensible Daten verwaltet, hätten die Kollegen nicht damit gerechnet, solch eine Sicherheitslücke dort zu finden. Warum das nicht eher aufgefallen ist, scheint unbegreiflich. Glücklicherweise sind diese Schwachstellen im Rahmen des Penetrationstests aufgefallen, und nicht erst durch eine böswillige Ausnutzung durch Kriminelle – zumindest soweit wir wissen. „Hersteller sollten sich wirklich überlegen, ihre Produkte auch einmal bei einem Penetrationstest auf die Probe zu stellen – vor allem wenn es sich um Webanwendungen handelt, welche extern für Angreifer erreichbar sind. Das erspart einem langfristig eine Menge Ärger“, rät Analyst Majid Lakhnati.
Lobend erwähnen die beiden jedoch die Reaktion und die Kooperation durch baltic IT. So war etwa die eingangs erwähnte kritische Sicherheitslücke in TOPqw bereits nach zwei Tagen geschlossen. Auch die übrigen Schwachstellen wurden nach und nach behoben.
Der Veröffentlichungsprozess folgte den Regeln der Responsible Disclosure. Seit dem 25. Juli 2024 sind alle fünf gemeldeten Sicherheitslücken geschlossen, und die entsprechenden Updates sind an alle Produktionsumgebungen der TOPqw-Kunden ausgerollt.
Alle technischen Details zu den gefundenen Schwachstellen sowie die komplette Timeline finden sich im ausführlichen Blogpost von G DATA Advanced Analytics auf cyber.wtf.
