In der Welt der Informationstechnologie ist die Identifizierung von Schwachstellen und Sicherheitslücken von entscheidender Bedeutung, um die Integrität digitaler Systeme zu gewährleisten.

Daher möchte ich betonen, dass ich jede entdeckte Schwachstelle oder Sicherheitslücke verantwortungsbewusst an die jeweiligen Organisationen gemeldet habe.

Meine Herangehensweise an die Offenlegung von Schwachstellen folgt dem Prinzip der Responsible Disclosure. Das bedeutet, dass ich jegliche identifizierten Sicherheitsprobleme diskret und vertraulich an die betroffenen Organisationen weitergebe. Dies ermöglicht es der Organisation, die notwendigen Maßnahmen zu ergreifen, um die Sicherheitslücken zu schließen, bevor diese von bösartigen Akteuren ausgenutzt werden können.

Natürlich gibt es auch Fälle, bei denen die Betroffenen, selbst nach mehrmaliger Meldung überhaupt nicht reagieren oder Sicherheitslücken auch einfach nicht schließen. Solche Fälle könnten hier ggf. auch veröffentlicht werden. Das ist allerdings die Ausnahme und auch nur dann, wenn nicht aktiv personen bezogene Daten im Spiel sind.

Organisation: IONOS SE
Betroffene Systeme: ionos.de, logo-generator.ionos.com
Schwachstellenmeldung: 8. Dezember 2022 (fixed)

Die IONOS-Webanwendung war von einer reflektierten XSS-Schwachstelle betroffen, die es ermöglichte, Schadcode über einen URL-Abfrageparameter auszuspielen. Die Payload wurde im Browser unter Verwendung einer URL interpretiert und ausgeführt.

Durch die Ausführung der Payload mittels des Aufrufs eines entsprechenden Links wurde beispielsweise die Umleitung eines Opfers auf eine Phishing-Website ermöglicht oder die Ausführung von Applikationsfunktionen in dessen Kontext. Auch waren Session Cookies auslesbar.

Die Sicherheitslücke konnte in der Anwendung "logo-generator.ionos.com" ausfindig gemacht werden:

Interessant war hier, dass diese Anwendung direkt in der Haupseite unter "ionos.de" über ein iFrame eingebunden wurde. Über das eingebundene iFrame konnte so via "window.parent.location.href" die URL eines Angreifers auf der Hauptseite geladen werden.

In einem Proof of Concept wurde exemplarisch ein Login-Formular integriert, das nicht von IONOS stammte. Auf diese Weise hätten potenzielle Angreifer Zugangsdaten abfangen können:

Organisation: Land Rheinland-Pfalz
Betroffene Systeme: *.rlp.de
Schwachstellenmeldung: 11. März 2023 (fixed)

Eine Datenbankverwaltung (phpMyAdmin) war ungesichert und öffentlich abrufbar. Es konnten auf Datenbanken eines Datenbankservers ohne Zugangssicherung zugegriffen werden. Ein krimineller Angreifer hätte alle darin enthaltenen Daten lesen, oder verändern können. Die Möglichkeit neue Daten zu schreiben war ebenfalls gegeben.
 
Enthalten waren z.B.:

    - Zugangsdaten von Frontend User mit Passwörtern in Klartext.
    - Zugangsdaten von Backend User mit Passwörtern in MD5 (veraltetes Hashverfahren).
    - 13099 E-Mail Addressen in einer dmail Log.

Die Datenbanken wurden wahrscheinlich nicht in Produktion verwendet (zu letzt generiert Einträge waren nicht aktuell). Es wurde dennoch empfohlen unbedingt auch die darin gefundenen Passwörter zu änderen, da diese in den Liveinstanzen funktionierten.

Des weiteren wurde eine ungeschützte Seite innerhalb eines Adminbereichs (/admin/test/) entdeckt. Darüber konnten öffentlich zugänglich interne PDF Dokumente heruntergeladen werden. (z.B. eine Arbeitsanweißung wie die Einrichtung einer Remote Desktop Verbindung (via RDP) mit dem Desktop PC am Arbeitsplatz erfolgt.

Organisation: EDIT.org
Betroffene Systeme: edit.org
Schwachstellenmeldung: 14. Dezember 2021 (fixed)

Eine nohup.out Datei war im documentRoot abgelegt.

In diesem File waren 173,737 E-Mail Adressen von Kunden offen einsehbar.

Die Ausgaben eines mittels "nohup" aufgerufenen Programms werden automatisch in die Datei "nohup.out" umgeleitet. Diese Datei wird im Verzeichnis erstellt, von dem aus der Befehl ausgeführt wurde. Alternativ wäre es möglich gewesen, die Ausgabe in "/dev/null" zu lenken oder das File im Nachgang zu löschen.

Organisation: Küche&Co GmbH
Betroffene Systeme: kueche-co.de
Schwachstellenmeldung: 4. Mai 2022 (fixed)

Über einen öffentlich aufrufbaren Link konnte eine 50.8MB .tgz Datei ohne Zugangssicherung heruntergeladen werden: https://intranet.kueche-co.de/archive.tgz

Dieses Archiv beinhaltete eine Datei mit Kundendaten (Namen, Adressen, Email-Adressen und mehr) .

Side Story:
Diese Meldung sollte mein erstes Bug Bounty sein, wo tatsächlich eine Prämie in Form von Geld als "Dankeschön" angeboten wurde. Naja, eigentlich.

Organisation: Gemeinde Roggenburg
Betroffene Systeme: roggenburg.de
Schwachstellenmeldung: 24. Nov. 2023 (fixed)

Der "Zweckverband gemeindliche Datenverarbeitung" im Landkreis Neu-Ulm ist Ende 2023 Opfer eines Ransomware Angriff geworden. Mehrere Kommunen im Landkreis Neu-Ulm wurden dadurch teilweise lahmgelegt. Darunter auch die Gemeinde Roggenburg. Der BR berichtete über den Vorfall.

Ich habe mir in diesem Zuge die Webseite der Gemeinde Roggenburg angeschaut. Innerhalb einer Minute konnte ich eine SQL-Injection ausfindig machen und ja, das ging tatsächlich so schnell, da mein erster Take immer die Eingabeprüfung von Input-Feldern ist. SQL-Injection ist eine kritische Sicherheitlücke, die es einem Angreifer ermöglicht mit der zugrunde liegenden Datenbank frei zu interagieren. Sie ermöglicht also den Zugriff auf alle Informatinen die darin gespeichert werden.

Vorweg möchte ich direkt eine Lanze brechen: Das von der Gemeinde Roggenburg verwendete Content Management System betrachte ich als ausgesprochen sicher. Die von mir entdeckte Sicherheitslücke resultierte aus einer eigenentwickelten Komponente, die vom Dienstleister bereitgestellt wurde. Die Umsetzung und Implementierung entsprachen jedoch nicht den Standards, die das System vorgibt. Das konnte man z.B. beim Suchformular durch den fehlenden CSRF-Token erahnen.

Neos (das verwendete System), sollte nicht als klassisches CMS verstanden werden, sondern eher als Content Application Plattform. Entwickler können mithilfe von NodeTypes und Fusion ihre eigenen Inhaltselemente erstellen. Diese können dann von Redakteuren über das Backend zur Contentpflege genutzt werden. Die traditionelle Umsetzung von Elementen erfordert in technischer Hinsicht also keine Programmierung in PHP oder gar SQL.

Warum war eine SQL Injection möglich?

Hierzu muss man das System zunächst grob verstehen.

Neos basiert auf einem eigens entwickelten PHP-Framework namens Neos Flow. Das MVC-Paradigma in Neos lässt sich vereinfacht wie folgt erklären:

1. Controller: Verantwortlich für die eigene Logik.
2. Model: Abbildung der Geschäftslogik und einer Entität nach den Konzepten des Domain-Driven Design.
3. Repository: Dient als Schnittstelle zwischen der Geschäftslogik (dem Model) und dem Data Storage (z.B. MySQL). Das Repository ist der Ort, an dem die Logik für Datenbankabfragen in das persistente Framework übergeht - standardmäßig Doctrine 2 ORM.

Wer sich bereits mit DBAL auseinandergesetzt hat, wird sofort feststellen, dass durch die Verwendung von Prepared Statements SQL-Injection ausgeschlossen ist. Wenn also die Logik in Neos erweitert werden muss, um bestimmte Anforderungen zu erfüllen, wird PHP hinzugezogen. Meine Vermutung ist, dass eine entsprechende Anbindung an ein anderes System über Datenbankanfragen (ohne ORM) erforderlich war. Die nativen SQL-Abfragen werden im Controller an eine externe Datenbank durchgeführt, vermutlich, um auch Inhalte in die Suche einzubeziehen, die nicht als Node über ein Repository abrufbar sind.

Fatal wird es, wenn Anfrage-Parameter vom Client in einer Datenbankabfrage ohne Überprüfung in die Query übernommen und ausgeführt werden, was hier der Fall war. Bei einer Anfrage an eine externe Datenbank erfolgt üblicherweise eine Suche in einer oder mehreren Tabellen nach Inhalten, die dem Suchbegriff entsprechen. Durch eine SQL-Injection kann ein Angreifer jedoch die Anfrage manipulieren und dadurch Zugriff auf ALLE Tabellen sowie in bestimmten Fällen auch auf andere Datenbanken erhalten. Das ermöglicht den Zugriff auf äußerst sensible Informationen, einschließlich personenbezogener Daten, aber auch auf Zugangsdaten, Secrets, API Creds, Tokens oder andere Verbindungsdaten, die ebenfalls in der Datenbank gespeichert sind und für weiterführende Angriffe genutzt werden können.

Inhalte aus Tabellen wie Core_Conf_Exchange, Core_DeviceToken, APT_Appointments, ABS_AppConfiguration, Core_User, Core_UserAuthentications, IMS_ExternalUsers oder GDC_ExternalAPIConfig sind nicht vorgesehen, über eine Suchergebnisseite ausgegeben zu werden.

Meine Anfragen begrenzten sich bei der Ausforschung im übrigen nur auf die Ausgabe der Datenbank Struktur, nicht aber auf Datensätze aus Tabellen. Das wäre auch absolut unnötig für das Aufzeigen dieser Sicherheitslücke gewesen.

Meiner Meinung nach zählt das Content Management System (CMS), das von der Gemeinde Roggenburg eingesetzt wird, zu den besten und innovativsten, die mir bekannt sind. Aufgrund meiner Erfahrungen mit verschiedenen Systemen kann ich für mich behaupten, dass die Codebasis von Neos (bzw. Flow) im Vergleich zu gängigen Systemen wie Drupal oder TYPO3 besonders hochwertig und durchdacht wirkt. Hier wird nicht nur sorgfältig auf Standards geachtet, sondern auch kontinuierlich der neueste Stand der Technik verfolgt.

Das Content Repository, das auf Event Sourcing basiert und mit der Version 9 eingeführt wurde, halte ich für bahnbrechend. Die Sicherheitsbilanz von Neos lässt sich auch sehen: Im Laufe der Jahre wurden nur wenige Schwachstellen entdeckt, und selbst diese waren in der Regel nur mit hohen Privilegien ausnutzbar, sofern überhaupt exploitfähig. Daher ist es nicht verwunderlich, dass auch ich auf Neos setze – mein Blog z.B. basiert auf diesem System.

Eine vulnerable Third-Party Komponente, welche Sicherheitslücken eröffnet, wird bei jedem (!) System Türen für Angreifer öffnen. Ich untersuche nun seit drei Jahren immer wieder kommunale Webapplikationen und muss unter dem Strich feststellen, dass so gut wie nie das zugrundeliegende System an sich vulnerabel ist, sondern entweder Fehlkonfigurationen oder Eigenentwicklungen in Form von Erweiterungen, Plugins bzw. Extensions durch die jeweiligen Dienstleister, welche Sicherheitslücken eröffneten.

Open Source-Produkte sollten meiner Meinung nach immer bevorzugt werden. Durch den öffentlich einsehbaren Quellcode ist in der Regel gewährleistet, dass, abhängig von der Popularität, eine vielzahl an Entwickler:innen den Code überprüfen, was eine höhere Sicherheit bietet als bei einem geschlossenen System, das in den Händen von ein paar Entwickler:innen liegt. Systeme wie Neos, TYPO3 oder Drupal sowie Eigenentwicklungen auf Basis von Frameworks wie Neos Flow, Laravel oder Symfony können durchaus sicher betrieben werden. Der entscheidende Punkt liegt jedoch immer beim verantwortlichen Dienstleister, der auf Basis dieser Systeme Webapplikationen umsetzt und mit eigener Programmierung "ergänzt". Eine Kommune kann die Qualität in der Regel nicht selbst kontrollieren - klar. Daher ist es ratsam, produktive Systeme, die sensible Daten verarbeiten, entweder einem Penetrationstest oder einem Code-Audit von einem unabhängigen Dienstleister unterziehen zu lassen.

Auch wenn Sie hohe Ansprüche und Erwartungen an ein System haben, ist eine entsprechende Beachtung in der "eigenen" Entwicklung unerlässlich. Weder ein Standard noch eine ISO-Zertifizierung wird Sie vor einem erfolgreichen Angriff schützen, wenn sich durch Nachlässigkeit oder Unwissenheit Sicherheitslücken ergeben.

Achja. Sollte Ihnen jemand Wordpress andrehen wollen, dann verbannen Sie das Angebot bitte direkt in den Papierkorb.

Further publications have been interrupted for current reasons. As long as an ethical hacker has to fear legal consequences when responsibly disclosing security vulnerabilities, I will not be able to continue here. Finally reform the hacker paragraph ...