Staatsministerium für Digitales – Datenleck erlaubt Zugriff auf über 223.000 Datensätze

Mit „Online sicher unterwegs – das hat sich das Staatsministerium für Digitales auf die Fahne geschrieben.“ brüstet sich das bayerische Staatsministerum für Digitales, unter einem Foto vom euphorisch lächelnden Innenminister Joachim Herrmann, welcher stolz die „Nummer gegen Kummer“ für Opfer von Cyberkriminalität präsentiert. Dabei dürfte das Lächeln in Anbetracht der – alleine in den letzten Monaten – aufgedeckten Schwachstellen der Regierung, mittlerweile etwas abgeklungen sein. In den vergangenen Monaten habe ich mehrmals meine Bedenken in Sachen Digitalisierung geäußert und anhand realer Beispiele demonstriert, wie brandgefährlich das krampfhafte „Digitalisieren“ unserer Regierung werden kann. Nun bin ich erneut auf mehrere kritische Schwachstellen innerhalb der Webpräsenzen unserer Regierung gestoßen. Ausgerechnet das Bayerische Staatsministerum für Digitales war mit unter den diesmaligen Kandidaten und wurde von mir – vor gut einer Woche – über ein erhebliches Sicherheitsproblem informiert. Auch in diesem Fall ging die Sicherheitsmeldung natürlich auch an das „Cyber Emergency Response Team“ (CERT) des bayerischen Landesamt für Sicherheit in der Informationstechnik (LSI).

Irgendwie ist es ja schon eine Ironie des Schicksals. Ausgerechnet das Staatsministerum, welches sich „Online sicher unterwegs“ auf die Fahne geschrieben hat, wurde nun mit der bitteren Realität und quasi der eigenen Unsicherheit – wenn nicht sogar als Inkompetenz zu bezeichnen – konfrontiert. Eine kleine Unachtsamkeit der verantwortlichen Entwickler im Staatsministerium, entpuppte sich dort nämlich als mittelschwere Katastrophe und erlaubte mir – recht einfach – den Zugang zu über 223.000 Datensätzen. Darunter auffindbar, waren auch tausende vertrauliche „Kundendaten“. Und das Ganze dann mit minimalem Aufwand und innerhalb von wenigen Minuten realisiert. Also ein weiteres „Schmankerl“ aus der Serie „Bayerisches Totalversagen“ in Sachen IT-Sicherheit. Und dieses Mal sogar aus dem Hauptquartier der Söder’schen „High-Tech Agenda“.

Mit diesem Artikel möchte ich etwas näher auf die entdeckte Problematik eingehen und andere Betreiber, sowie Administratoren und Entwickler über die potentiellen Auswirkungen von „sicherheitsrelevanten Kleinigkeiten“ informieren. Denn es reicht – wie in der Einleitung erwähnt – bereits eine kleine Unachtsamtkeit, um eine wahre Katastrophe zu provozieren. Bei diesem „Write-Up“ werde ich auch wieder versuchen, die Details so einfach und verständlich zu halten, dass sie auch unversierte Leser nachvollziehen können. Steinigt mich also bitte nicht – liebe Nerds da draußen – wenn es hier nicht allzu peinlich genau mit Begrifflichkeiten einhergeht.

Kommentare im Quelltext sind ein absoluter „Eyecatcher“ für Angreifer

Was ursprünglich als hilfreiches Mittel für Entwickler diente und auch immer noch sehr gerne und hilfreich eingesetzt wird, kann unter Umständen für richtig Ärger sorgen. Nämlich dann, wenn es öffentlich sichtbar zum Einsatz kommt und dabei dient, veralteten Code vom Rendern auszuschließen oder vorübergehend ein paar Elemente zu deaktivieren. Für Leser die nun nur Bahnhof verstehen und nicht wissen, worum es dabei geht, hier eine vereinfachte Erklärung (sehr stark vereinfacht):

In Programmiersprachen gibt es für Entwickler die Möglichkeit, Kommentare zum Code einzufügen. Diese dienen dazu, den jeweilig geschriebenen Code mit kurzen Stichworten zu beschreiben, Programmcode sauber aufzuteilen, die Versionsinformationen zu hinterlegen oder andere Infos in die betroffene Datei zu packen. Auch lässt sich dadurch Programmcode von der Verarbeitung ausnehmen, so dass man beispielsweise beim Einfügen von neuem Programmcode, den alten Programmcode (als Backup) in der Datei lassen kann.

Nun ist zwar HTML eigentlich gar keine Programmiersprache – worauf ich nun jedoch nicht genauer eingehen werde – aber es bietet sich auch dort und in vielen weiteren „Codes“ die Möglichkeit, Einzelne Zeilen oder Elemente im Code entsprechend auszukommentieren. So werden die auskommentierten Zeilen zwar nicht auf der dargestellten (gerenderten) Website angezeigt, aber sie sind im Quellcode der Website sichtbar bzw. lesbar – also auch für potentielle Angreifer. Hier ein kleines Beispiel:

<!-- Ich wäre auf der Website unsichtbar, aber sichtbar im Quelltext. -->
<p>Ich wäre auf der Website und auch im Quelltext sichtbar.</p>

Nun fragen Sie sich sicherlich, wie solche auskommentierten Bereiche denn für den Betreiber der Website oder dessen Besucher gefährlich werden könnten. Immerhin werden diese Kommentare ja nicht gerendert / verarbeitet.

Natürlich sind auskommentierte Stellen im ersten Moment ungefährlich. Allerdings sind sie – wie schon erwähnt – für potentielle Angreifer ein absoluter Eyecatcher. Denn Kommentare im Quelltext verraten oft mehr, als den Betreibern eigentlich lieb sein sollte. Zum Beispiel nutzen viele Entwickler von Erweiterungen (Komponenten, Plugins, Themes, …) für diverse Webanwendungen, die Möglichkeit für Kommentare im Quelltext, um dort den Namen der Erweiterung, inklusive der Versionsnummer zu hinterlegen. Eine Vorgehensweise die ich aus sicherheitsrelevanter Sicht, absolut nicht nachvollziehen kann. Denn außer potentiellen Angreifern, hat niemand einen Nutzen an diesen Informationen. Und wenn beispielsweise eine bestimmte Version einer Erweiterung, bekannte Sicherheitslücken aufweist (wie beispielsweise kürzlich beim StMGP), hat ein Angreifer praktisch einen direkten Hinweis auf mögliche Hintertüren im System.

Grundsätzlich ist es deshalb empfehlenswert, entsprechend „informative“ oder gar „verräterische“ Kommentare aus dem Quelltext zu beseitigen. Man muss dabei aber nicht einmal zwingend auf die Kommentare im „Source“ verzichten, denn es gibt hierzu andere Möglichkeiten. Zum Beispiel kann das Entfernen der Kommentare auch mit entsprechenden Funktionen der Webanwendung realisiert werden, welche den Quelltext vor der Ausgabe entsprechend filtern und Kommentare beseitigen. Und eine solche Funktion wäre auch im Fall des bayerischen Staatsministeriums für Digitales durchaus hilfreich gewesen. Wieso das der Fall ist, verrate ich nun.

Staatsregierung demonstriert, wie man es nicht machen sollte – Kommentare im Quellcode führten zur Schatztruhe

Wussten Sie bereits, dass die Bayerische Staatsregierung einen Webshop betreibt? Ja, es hat auch mich ein wenig irritiert. Aber es ist tatsächlich der Fall. Unter der Domain „bestellen.bayern.de“ betreibt die Staatsregierung Bayerns einen „Publikationsshop“, in dem man viele nützliche Artikel bestellen kann. Ja, okay… der Begriff „nützlich“ kann tatäschlich in blanken Sarkasmus eingeordnet werden, aber ich möchte ja nicht zu unverblümt klingen. Man kann nämlich im Webshop der Bayerischen Staatsregierung so töfte Sachen kaufen, wie beispielsweise Plakate mit „Hygiene-Regeln“ für die unfassbar (un)tödliche Corona-Pandemie. Also ein Produkt das im Moment sehr gefragt sein dürfte. Und wenn man es genau betrachtet, sogar einen Interessenskonflikt darstellen dürfte, was die Corona-Maßnahmen in Bayern betrifft. Aber dazu vielleicht an anderer Stelle mehr. Hier geht es ja um die Sicherheitsproblematik und ich möchte nicht zu sehr ins „pandemische Nirvana“ abdriften.

Der Webshop unserer bayerischen Staatsregierung bietet neben den Artikeln, auch weitere interessante Dinge an. Nämliche beispielsweise so praktische Kommentare im Quelltext, die einem Angreifer durchaus schmackhaft erscheinen dürften. Hier ein Screenshot vom Quelltext des Shops:

Wie man in der Grafik direkt erkennen kann, nutzt die bayerische Staatsregierung eine Webanwendung zur Analyse der Besucher und Nutzer, sowie deren Verhalten. In dem Fall ist es die Software „Matomo“ (ursprünglicher Name „Piwik“), welche sehr weit verbreitet ist und ein hervorragendes Mittel zur Analyse von Webstatistiken darstellt. Natürlich ist das absolut nicht schlimm und wird wahrscheinlich auch ziemlich gängig bei der Regierung sein (auch ich nutze Matomo). Allerdings führte mich das auskommentierte Snippet ziemlich schnell zu einem wahren „Schatz“. Denn wenn man feststellt, dass sich im Quellcode der Website zwei Schnipsel Code befinden, welche beide zum eigentlich gleichen „Tracking-Tool“ führen, man dann etwas logisch denkt und die beiden URLs vergleicht, kommt man sehr schnell auf die Idee, dass man beim Staatsministerium etwas unsauber gearbeitet hat. Der Gedanke hat sich dann auch direkt bestätigt, als ich diesem nachgegangen bin.

Das auskommentierte Code-Snippet war also ein Überbleibsel aus der Vergangenheit. Offenbar hat man eine ursprüngliche Piwik-Installation, mit einer neuen Matomo-Installation ersetzt und dabei die ursprüngliche Einbindung in den Webshop, lediglich auskommentiert. Allzu lange kann dies allerdings nicht her sein, aber dazu komme ich noch. Neugierig wie ich bin, musste ich natürlich einen kurzen Blick auf die entsprechende URL in dem sichtbar auskommentierten Schnipsel werfen. Denn meist führen solche auskommentierten Zeilen dann auch zu veralteten Systemen und vergessenen Bereichen, die dann erfahrungsgemäß auch diverse Sicherheitslücken aufweisen.

Ich steuerte also die URL „https://webalytics.bayern.de/“ an, welche mir der Kommentar im Quelltext verraten hatte und stieß dabei – natürlich völlig „unerwartet“ – auf die Anmeldeseite des oben genannten Analyse-Tools. Im ersten Moment natürlich kein Problem. Allerdings wurde es dann noch zum Problem. Und dieses Problem hatte es durchaus in sich.

Vom Kommentar im Quelltext, über fehlerhafte Konfiguration des Servers, direkt zu Zugangsdaten – Jackpot!

Eine Sache die ich leider immer wieder feststellen muss und deshalb auch immer wieder explizit erwähne, kann Betreibern von Webseiten sehr schnell zum Verhängnis werden. Es geht dabei um „Spielwiesen“ von Programmierern und ähnliche Testumgebungen, die schlichtweg auf einem „Live-System“ nichts verloren haben. Schon gar nicht, wenn diese Bereiche komplett ungesichert und von Jedermann zugänglich sind. Dies durfte nun auch das Staatsministerium für Digitales feststellen. Denn innerhalb des Webshops unter „bestellen.bayern.de“ fand ich dann auch – binnen weniger Sekunden – versteckte Inhalte, die dort eigentlich nicht wirklich sein sollten.

Meine Erfahrungen aus über 15 Jahren in der Branche, sind beim Aufdecken von Schwachstellen immer sehr hilfreich. So weiß ich zum Beispiel, dass es eine typische Vorgehensweise vieler Entwickler ist, Erweiterungen – wie beispielsweise ein eingebundenes Analyse-Tool – zunächst testweise in einen Unterordner der Website zu legen oder einen speziellen Unterordner anzulegen, in dem man eine kleine „Spielwiese“ betreibt. Damit sind Dateien gemeint, die zum Testen der jeweils eingebundenen Erweiterungen dienen sollen. Üblicherweise nutzen die Entwickler dabei Unterordner mit entsprechenden Namen, wie beispielsweise „test“ oder auch „demo“, mit ähnlichen Namen für die jeweiligen Dateien in solchen Ordnern. Und so in etwa war dies auch im Shop der bayerischen Staatsregierung der Fall. Dort stieß ich nämlich recht schnell auf den Unterordner „piwik“, welcher ungeschützt war und damit quasi für die Öffentlichkeit zugänglich. Beim Aufruf der URL „https://bestellen.bayern.de/piwik/“ bekam ich allerdings keinen Inhalt präsentiert, sondern eine „403er“ Rückmeldung, was mich darauf schließen ließ, dass dort kein „Index“ hinterlegt, der Ordner aber zugänglich ist und daher sehr wahrscheinlich andere Dateien darin liegen könnten. Denn wer lässt schon einen leeren Ordner unnötig auf dem Server liegen. Ein kurzer Check der „üblichen Verdächtigen“ ließ mich dann allerdings recht schnell, mit offenem Mund am Rechner sitzend verweilen. Erneut war ich erstaunt darüber, was sich auf den Webservern der Regierung so alles abspielt.

Source Code Disclosure mit Zugangsdaten und Wegweiser – Es wird interessant

Irgendwie hatte ich es ja bereits geahnt, dass der erwähnte Unterordner vielleicht die ein oder andere Überraschung zum Vorschein bringen würde. Allerdings hätte ich nicht damit gerechnet, dass ich diese Überraschung dann auch direkt zum Download angeboten bekommen würde. Der kurze Check der „üblichen Verdächtigen“ brachte mich nämlich zu einer Datei namens „test.php“ im Unterordner „piwik“. Und diese Datei war nicht nur für die Öffentlichkeit erreichbar, sondern wurde mir vom Server auch direkt zum Download angeboten. „Wie praktisch“ würde sich wahrscheinlich jeder Angreifer in solch einer Situation denken. Für mich war damit klar, dass beim Konfigurieren des Servers dort, wieder „Spezialisten“ am Werk waren.

Da mich natürlich brennend interessierte, was für Downloads man im Webshop der bayerischen Staatsregierung angeboten bekommt, speicherte ich die Datei ab und warf einen Blick hinein. Und ich muss sagen, dass der Inhalt nicht gerade enttäuschend war. Für einen Angreifer wäre es mit Sicherheit ein Grund zur Freude gewesen.

Wie man sehr gut erkennen kann, war der Entwickler aus dem bayerischen Staatsministerium für Digitales so freundlich, die API-Zugangsdaten aus der „Spielwiese“ zum Download anzubieten. Und dabei hat er sogar die Möglichkeiten des Kommentierens innerhalb des Programmcodes, recht ordentlich benutzt. Ein Angreifer bekommt dadurch – neben den Zugangsdaten – auch direkt eine Anleitung geliefert, wo und wie er diese einsetzen kann. Ab diesem Moment war mir dann auch klar, dass es nicht bei dieser kleinen Überraschung bleiben wird und ich vermutlich auf größere Probleme stoßen könnte. Ich entwickelte dann bereits eine gewisse Vorahnung, aufgrund der zuvor festgestellten „Eigenschaften“ des besagten Webshops.

Und nun? Das sind API-Zugangsdaten zu Besucherzahlen – Ist doch harmlos?!

Ja, man könnte vielleicht im ersten Moment denken, dass solche API-Zugangsdaten recht harmlos wären. Immerhin hätte ein Angreifer dadurch ja lediglich die Möglichkeit, sich die Statistik für die jeweilige Website anzusehen. Und ja, die Besucherzahlen sind nicht wirklich als vertrauliche Daten einzustufen. Allerdings gibt es da – und jetzt wird es interessant – nicht nur die Besucherzahlen zu holen. Solche Webanwendungen zur Analyse der Besucher und deren Seitenaufrufe, sind mittlerweile sehr komplexe Systeme mit unzähligen Funktionen für die Auswertung der Daten. Und diese Funktionen kann man als Angreifer teilweise schon fast als eine Art „Keylogger“ betrachten. Nämlich dann, wenn man sich die aufgezeichneten Daten im Detail ansieht und sich anschließend die Gegebenheiten und Eigenschaften des Shops zu Nutze macht.

Die in der entdeckten Datei hinterlegten API-Zugangsdaten konnte ich mittels einer kurzen Abfrage der API als echt und aktiv bestätigen, wie man im Bild gut erkennen kann. Es hätte ja auch sein können, dass es lediglich veraltete Zugangsdaten waren, die nach dem Testen entfernt wurden, was dann praktisch ein „Falscher Alarm“ gewesen wäre. Aber nein, die Zugangsdaten waren tatsächlich aktuell und auch (aus-)nutzbar. Die Informationen zu den Besucherzahlen (wie im Bild sichtbar) sind aber tatsächlich nicht das angekündigte „Schmankerl“. Das kam dann erst bei genauerer Betrachtung. Und weil der Entwickler die Möglichkeit für Kommentare im Code scheinbar recht gerne benutzt, war in der „test.php“ Datei auch gleich die URL zur Dokumentation der eingesetzten Webanwendung (Piwik/Matomo) hinterlegt. Ich kenne die API von Matomo selbst recht gut, deshalb war mir der Umfang in dem Moment bereits klar. Ein Blick in die Dokumentation dürfte aber auch dem Leser verraten, dass mit der API tatsächlich auch noch so einige „Schmankerl“ abgefragt werden können, die man nicht unbedingt vermuten würde.

Vertrauliche Informationen und Bestelldaten über GET-Requests – Eine ziemlich schlechte Idee

Vielleicht fragt sich der ein oder andere Leser nun, was denn genau das größte Problem bei der Sache war und wie man über sowas wie „Matomo“ an sensible Daten kommt. Die Überschrift von diesem Absatz dürfte diesbezüglich bereits ein „Ooooooh shit…“ bei den aufmerksamen Lesern hervorgerufen haben, welche sich mit der Materie beschäftigen. Und ja, es ist wahrhaftig richtig „shit“, wozu die bisher genannten Umstände führen können.

Der Webshop unserer bayerischen Staatsregierung ist nämlich so programmiert, dass er Befehle und Daten über GET-Requests entgegen nimmt. Dies tut der Shop – wie ich feststellen konnte – auch bei den jeweiligen Bestelldaten. Für die unversierten Leser kurz erklärt:

Bei GET-Requests werden über die URL (die Adresse in der Browserzeile) die jeweiligen Parameter mitgeliefert, welche die Webanwendung dann benutzt, um die gewünschte Seite zu öffnen oder die jeweiligen Daten zu laden/speichern. Um das etwas verständlicher zu machen, ein kleines Beispiel mittels Google. Wenn Sie Google aufrufen und eine Suche starten, dann sehen Sie in der Adresszeile des Webbrowsers, hinten hinaus ein „/search“, gefolgt von einem Fragezeichen „?“ und dann mehrere Parameter, getrennt mit einem „&“ Zeichen. Diese Parameter sind dann jeweils nochmal durch ein „=“ Zeichen von ihrem „Parameter-Inhalt“ getrennt. Mit den Parametern bekommt die Webanwendung – also in dem Fall der Shop – die jeweiligen Befehle/Informationen geliefert, um die Anfrage (Request) zu verarbeiten. Bei Google finden Sie demnach den Parameter „q“ als Abkürzung für „query“ (also praktisch den angefragten Suchbegriff) und hinter dem „=“ dann den Inhalt des Parameters, also die eingegebene Suchanfrage. Das ist zwar eine völlig normale Sache. Allerdings wird dies im Shop der bayerischen Staatsregierung zum Problem.

Wie bereits erwähnt, ist der Shop so programmiert, dass auch Bestelldaten per GET-Request übergeben werden. Und genau dies wird zu einer unangenehmen Tatsache, wenn man Analyse-Tools wie zum Beispiel „Matomo“ einsetzt und ein Angreifer auf die API dieses Tools zugreifen kann. Bedient man sich nämlich der umfangreichen Funktionen der API und startet eine Abfrage der verfügbaren Methode „Actions.getPageUrls“, so erhält man eine Auflistung aller im Shop aufgerufenen URLs, welche vom Analyse-Tool zu Zwecken der Auswertung gespeichert wurden. In dem Fall dann auch noch die vollständigen URLs, inklusive der jeweiligen GET-Parameter. Bedient man sich dann auch noch der Möglichkeiten der API, den Zeitraum für die abgerufenen Daten festzulegen (zum Beispiel jährlich für die letzten 10 Einheiten) und das Format der ausgegebenen Daten als „csv“ zu definieren, bekommt man eine ziemlich umfangreiche CSV-Datei, mit allen im Shop aufgerufenen URLs der letzten 10 Jahre, direkt zum Download angeboten.

Um meine Annahmen bestätigen und die Sachlage besser einschätzen zu können – also bevor ich das CERT unnötig in Alarm versetzen würde – testete ich den Abruf und analysierte grob die ausgegebenen Informationen. Und da wurde ich dann tatsächlich nicht enttäuscht. Alleine diese eine Abfrage lieferte eine über 300 MB große CSV-Datei. Insgesamt waren in dieser Datei dann rund 223.000 Zeilen mit Details zu den aufgerufenen Seiten zu finden. Und beim Überfliegen dieser Daten musste ich dann feststellen, dass sich darunter auch einige Tausend Zeilen mit detaillierten Kunden- bzw. Bestelldaten aus dem Shop befinden. Dazu hier ein kleiner Auszug:

Ich denke das dürfte nun die Frage nach dem „Problem“ beantworten. Denn wie man im obigen Screenshot sehr gut sehen kann, ist die Kombination aus Bestelldaten oder anderen sensiblen Informationen (zum Beispiel Zugangsdaten) in GET-Requests, dazu einem Analytik-Tool wie Matomo und einem zusätzlichem Source Code Disclosure Problemchen mit API-Zugangsdaten, keine besonders empfehlenswerte Kombi. Ob im Fall der Bayerischen Staatsregierung auch noch mehr zu holen gewesen wäre, kann ich nicht sagen. Mir hatte die Liste mit tausenden Userdaten bereits gereicht, um direkt mit dem „Alarm“ an die betroffenen Stellen fortzufahren.

Anschließende Sicherheitsmeldung an das CERT im Landesamt für Sicherheit in der Informationstechnik (LSI)

Da die Angelegenheit sich nach Prüfung der Sachlage als tatsächlich „größeres Problem“ erwies, verfasste ich – wie so oft – eine entsprechende Sicherheitsmeldung an die betroffenen Stellen, sowie an das Cyber Emergency Response Team (CERT) des bayerischen Landesamts für Sicherheit in der Informationstechnik. Dort reagierte man am Folgetag und bestätigte den Eingang der Sicherheitsmeldung. Zwar wie immer etwas sehr kompakt (ich kenne das vom CERT im Bundesamt etwas ausführlicher und persönlicher), aber als kurze Rückmeldung natürlich ausreichend. Immerhin bin ich ja auch nicht auf Romane oder Brieffreundschaften aus, sondern reduziere das Ganze aufs Wesentliche. Ich bin an der Stelle wieder so frei und veröffentliche die Rückmeldung aus dem CERT, um direkt – wie im kürzlich geschriebenen Artikel erwähnt – die Legitimität meiner Behauptungen zu unterstreichen.

Wie ich kurze Zeit nach der Rückmeldung aus dem CERT feststellen konnte, hat man sich der Sache auch direkt angenommen. Die im Unterverzeichnis des Publikationsshops entdeckte Datei mit den Zugangsdaten, wurde entfernt und auch die API-Zugangsdaten selbst wurden gelöscht, so dass kein Abruf mehr möglich war. Demnach hat sich mein spontaner „Einsatz“ auch in diesem Fall wieder gelohnt und für ein kleines Stück mehr Sicherheit gesorgt.

Staffel-Finale? Was Sie in der nächsten Folge „The Walking Data“ erwartet

Die Problematik scheint also behoben. Eine weitere Rückmeldung hierzu gab es bisher nicht. Allerdings scheine ich mittlerweile ein „heißes Thema“ in der bayerischen Staatsregierung geworden zu sein. Zumindest lässt dies ein Blick in meine eigene „Analytik-Software“ vermuten. Und es würde mich auch nicht wundern, denn nur wenige Tage nach dieser Sicherheitsmeldung, ging erneut eine Meldung an das gleiche CERT, die dann auch noch als „Eilsache“ behandelt werden musste. Dabei gab es ein ähnliches Problem, welches allerdings noch eine gehörige Stufe höher in Sachen „Katastrophe“ einzuordnen war. Details zu diesem Fall, gibt es dann in einem späteren Artikel. Man ahnt es aber schon… Die Serie geht also weiter.

Wer den späteren Bericht dazu und auch weitere Artikel von mir nicht mehr verpassen möchte, kann sich für meinen Newsletter registrieren.