Covid-Center & andere Webseiten: Bedienen Sie sich!

Vor einigen Wochen haben wir hier auf DNIP über die Problematik offen zugänglicher Git-Verzeichnisse im Webserver (und die zur Information der Seitenbetreiber notwendigen Odyssee) geschrieben. In der Zwischenzeit ist die Zahl der von diesem Problem betroffenen Webserver auf unter 600 gesunken (und man kann nur hoffen, dass die übrigen Betreiber sich zumindest vergewissert haben, dass sie auf diese Weise keine kritischen Daten preisgeben).

Unser Artikel hat aber auch das Interesse von Security-Forschern an weiteren potentiell heiklen Dateien und Verzeichnissen geweckt, welche unachtsame Betreiber über den Webserver allenfalls offenlegen können). Und diese Suche hat zumindest in einem Fall zu schlagzeilen-würdigen Erkenntnissen geführt, es ging einmal mehr um um den Themenkomplex Covid.

Entwickler­­werkzeuge auf dem produktiv genutzten Webserver

Symfony ist eine verbreitete Entwicklungs- und Laufzeit-Umgebung für mit PHP entwickelten Websites. Darin enthalten ist mit dem “Symfony Profiler” auch eine Profiler-Komponente, welche normalerweise während der Entwicklungs- und Testphase dazu verwendet werden kann, das Verhalten der Website im Detail zu untersuchen um so zum Beispiel Performance-Probleme frühzeitig zu erkennen. Diese Komponente ist ausdrücklich nicht für den Einsatz auf dem produktiven Webserver vorgesehen.

Never enable the profiler in production environments as it will lead to major security vulnerabilities in your project.

https://symfony.com/doc/current/profiler.html

Schon die Anleitung macht also deutlich, dass die Komponente nur für vom Internet abgetrennte Entwicklungsumgebungen gedacht ist (also Umgebungen in denen Transparenz und Detailinformationen wichtiger sind als Sicherheit bei Zugriffen durch Dritte). Einer der Gründe dafür ist, dass über dieses Werkzeug auch ein Blick in die Konfiguration und die sicherheitsrelevanten Daten der Website möglich ist.

Der konkrete Inhalt des Info-Screens hängt natürlich von der jeweiligen Webseite ab, in unserem Beispiel sind drei (mit dem AWS-Key sogar vier) für Angreifer interessante Werte enthalten:

• APP_SECRET wird von Symfony für die Verschlüsselung von Informationen auf der Webseite verwendet. Wie schon der Name sagt, sollte dieser Schüssel geheim bleiben, da Angreifer ansonsten Daten manipulieren oder eigenen Programm-Code im Kontext der Webseite ausführen können.
• DATABASE_URL enthält die Login-Daten der durch die Website verwendeten Datenbank. Wie schon beim Problem der offen zugänglichen Konfiguration hängt die Ausnutzbarkeit davon ab, ob die Datenbank übers Internet zugänglich ist. Gegebenenfalls hat ein Angreifer hiermit direkt Zugriff auf sämtliche relevanten Daten einer Website
• Die Informationen in MAILER_DSN schlussendlich erlauben die Übernahme eines zur Website gehörenden Email-Accounts, zumindest zum Versenden von Emails mit dem Absender der Website. Und da bei Email-Accounts das Email-Server-Passwort fürs Versenden von Emails meist dasselbe ist wie fürs Empfangen, können vermutlich auch alle eingehenden Mails mitgelesen werden.

Zum Zeitpunkt der Untersuchung gab es in .ch rund 5 Mio Domains/Subdomains, in rund 300 davon war das oben beschriebene Entwickler-Werkzeug auf dem produktiven Webserver installiert und übers Internet erreichbar. Bei den meisten dieser 300 konnten die Login-Daten der Datenbank eingesehen werden, bei rund 50 auch diejenigen des Email-Accounts.

300 betroffene Sites von insgesamt 5 Millionen ist erfreulich wenig, insgesamt ist dies also in .ch kein grosses Problem. Die betroffenen Sites (darunter auch die eine oder andere Gemeinde) dürften das spätestens im Ernstfall anders sehen, und insbesondere für die sich darunter befindenden Cybersecurity-Consulting-Firma ist es mehr als nur ein bisschen peinlich…

Zugangsdaten pfannenfertig zum Abholen

Eine Website besteht heute typischerweise aus verschiedenen technischen Komponenten, nebem dem Webserver selbst sind das zum Beispiel Datenbanken, Email-Server, Cloud-Speicher bei Amazon/AWS etc. Für den Zugriff auf diese Komponenten werden Login-Daten und Zugriffsschlüssel benötigt, die natürlich “irgendwo” auf dem Server gespeichert werden müssen. Als Quasi-Standard für die Ablage dieser Schlüssel hat es sich etabliert, eine Textdatei namens .env ins Hauptverzeichnis zu legen welche genau diese Daten enthält. Bei entsprechendem Zugriffsschutz ist das grundsätzlich kein Problem (bzw. kein grösseres als wenn diese Datei irgendwo auf dem Server liegen würde). Die zum Schutz notwendige Konfiguration des Webservers kennen wir bereits von den Git-Verzeichnissen her:

Anders sieht es natürlich aus, wenn genau dieser Zugriffsschutz fehlt, denn dann gibt man interessierten Angreifern nicht nur quasi den Hausschlüssel in die Hände sondern auch gleich noch den Zugangscode zum eBanking und den Autoschlüssel.

Auch hier führte das Absuchen der 5 Mio .ch-Domains/Subdomains zu einigen interessanten Erkenntnissen:

• Bei rund 1500 Domains wurde eine übers Internet zugängliche .env-Datei gefunden
• Bei 300 davon enthielt sie sensible Zugangsdaten welche nicht für die Öffentlichkeit bestimmt waren
• Darunter waren auch zwei Systeme bei welchen ein Missbrauch der Informationen definitiv für Schlagzeilen gesorgt hätte:
  • Ein Finanzberatungsunternehmen mit dem Zugangsdaten zum Email-Account des CEO
    
  • Zugang zur Datenbank eines vorarlbergischen Covid-Testcenter, welches unter anderem auch die medizinische Auswertung von privat betriebenen Testcentern in Zürich und der Ostschweiz vornahm. In der Datenbank fanden sich über eine Million Datensätze über Corona-Tests von Menschen in Österreich und der Schweiz welche sich zwischen Dezember 2020 und November 2022 testen liessen. Da es sich bei Corona-Test-Ergebnissen um besonders schützenswerte Personendaten handelt, und diese im konkreten Fall unter Umständen sogar im Ausland verarbeitet wurden, wurde hier das Datenschutzgesetz vermutlich gleich mehrfach verletzt. Die Hintergründe dazu und die Stellungnahme des betroffenen Test-Centers hat Watson in einem eigenen Artikel aufgearbeitet. Der die Lücke untersuchende Sicherheits-Forscher hat umgehend BAG, NCSC und EDÖB informiert, das BAG hat in einem ersten Schritt dafür gesorgt dass die Datenbank nicht mehr öffentlich übers Internet erreichbar ist. Weitere Abklärungen sind noch am Laufen.
    
    Das betroffene Testcenter hat übrigens bereits Anfang Jahr schon mal für Schlagzeilen gesorgt, da Patienten die in Österreich analysierten Tests selber bezahlen mussten (während die Kosten für CH-Tests über die Krankenkasse abgerechnet werden können).
    
• Auch auf der Trefferliste zu finden war eine Domain des BAG. Bei dieser handelte es sich nach Angaben des BAG um die Testinfrastruktur für das Covid-Zertifikat, das produktive Umfeld sei nicht zugänglich gewesen.
• Hier ist uns ein Fehler unterlaufen, korrekt ist: Im .env-File des oben erwähnten Testcenters waren API-Keys (also quasi Login-Daten) für das Ausstellen von Covid-Zertifikaten enthalten. Diese API-Keys waren nach Angaben des BAG aber nur für die Test-Infrastruktur gültig, echte Covid-Zertifikate hätten sich damit nicht erstellen lassen.

Fazit

Alle gefundenen Schwachstellen wurden laufend dem NCSC gemeldet, um eine zeitnahe Information der betroffenen Betreiber sicherzustellen. Und auch wenn die Zahl der Schwachstellen insgesamt sehr klein ist, zeigt der Fall des österreichischen Corona-Labors doch sehr deutlich, dass der Unterschied zwischen einer sicheren und einer unsicheren Website manchmal nur aus wenigen Text-Zeilen besteht. Und dass es sich daher lohnt, genügend Zeit und Geld in die Sicherheit zu investieren um nicht aus lauter Leichtsinn (“uns kann schon nix passieren”) böse Überraschungen zu erleben. Gerade bei Gesundheitsdaten ist Datensicherheit zentral.