Gefunden: Ein klassischer, aber kritischer Sicherheitsfehler
In dieser Webserie berichten wir über reale Sicherheitsprobleme, die durch unsere Hacker Attack Simulation aufgedeckt wurden. Ziel ist es, typische Schwachstellen sichtbar zu machen, ihre Auswirkungen zu erklären und zu zeigen, warum kontinuierliche Sicherheitsüberprüfungen unverzichtbar sind.
In einem aktuellen Fall analysierten wir die Infrastruktur eines Betreibers von VR-Chat-Apps. Dabei stießen wir auf ein besonders kritisches Problem:
Der Private Key einer OpenSSL-Verschlüsselung war direkt im WebRoot des Servers abgelegt.
Da sich das WebRoot in der Regel im öffentlich zugänglichen Bereich eines Webservers befand, konnte dieser Private Key ohne Authentifizierung von überall aus dem Internet abgerufen werden. Mit dem Pfad /server.key wurde der Schlüssel direkt heruntergeladen.
Warum das so gefährlich ist
Ein Private Key ist das Herzstück jeder TLS/SSL-Verschlüsselung. Gerät er in falsche Hände, sind die Folgen gravierend:
Verschlüsselte Verbindungen können entschlüsselt werden
Angreifer können sich als legitimer Server ausgeben
Man-in-the-Middle-Angriffe werden möglich
Vertrauen in die gesamte Plattform wird untergraben
Kurz gesagt: Der Schlüssel gilt als kompromittiert, und jede darauf basierende Verschlüsselung ist nicht mehr sicher.
Wie kommt es zu solchen Fehlern?
Solche Fehler entstehen häufig durch eine Fehlkonfiguration bei der Einrichtung von HTTPS, automatisches Deployment ohne Überprüfung, Backup- oder Restore Prozesse, die sensible Daten ins Webroot schreiben. Gerade in dynamischen Umgebungen mit schnellen Release-Zyklen können solche Fehler leicht übersehen werden.
Unsere Simulation prüft Systeme aus der Perspektive eines realen Angreifers. Öffentliche Pfade, Fehlkonfigurationen und sensible Dateien im WebRoot gehören dabei zu den ersten Prüfungen. In diesem Fall konnte die Schwachstelle frühzeitig identifiziert werden, bevor ein tatsächlicher Missbrauch bekannt wurde.
In den nächsten Beiträgen dieser Serie zeigen wir weitere Beispiele aus unserer Hacker Attack Simulation und erklären, wie sich solche Risiken effektiv vermeiden lassen. Bleiben Sie dran.
Die Nutzer eines RSS-Reader können Ihre Software hiermit füttern: https://www.hackerattack.de/blog/feed.xml
