· Rexoma Team · IT-Sicherheit · 5 min read
Zugangsdaten im Klartext: Wie Heap-Dumps, Logs und Konfigdateien zum Datenleck werden
Beim Reisebuchungssystem Amadeus lagen Passagierdaten offen, weil ein ungeschützter Heap-Dump Zugangsdaten im Klartext enthielt. Das Muster dahinter findet sich in fast jedem KMU – und lässt sich mit sauberem Secrets-Management abstellen.
Bei Amadeus, einem der größten Reisebuchungssysteme der Welt, waren Passagierdaten einsehbar. Ursache war laut heise kein ausgeklügelter Hackerangriff, sondern ein ungeschützter Heap-Dump – ein Speicherabbild einer Anwendung –, in dem Zugangsdaten im Klartext standen. Genau dieses Problem gibt es in kleinerem Maßstab in vielen mittelständischen Betrieben: Passwörter und API-Schlüssel liegen dort, wo niemand sie vermutet. Wer Zugangsdaten im Klartext findet und beseitigt, schließt eine der einfachsten Türen für Angreifer.
Warum Klartext-Zugangsdaten so gefährlich sind
Eine Firewall, MFA und aktuelle Patches helfen wenig, wenn das Datenbankpasswort in einer Datei steht, die jemand herunterladen kann. Angreifer müssen dann nichts knacken – sie melden sich einfach an. Solche Zugriffe sehen in den Logs aus wie normale Anmeldungen und fallen deshalb oft lange nicht auf.
Das Tückische: Kaum jemand legt Passwörter absichtlich offen ab. Sie landen dort als Nebenprodukt von Fehlersuche, Bequemlichkeit oder Standardeinstellungen.
Typische Fundorte in KMU
Aus unseren Sicherheitsaudits kennen wir diese Stellen besonders gut:
- Speicherabbilder und Crash-Dumps: Java-Anwendungen, Windows-Dienste oder Datenbanken schreiben bei Abstürzen ihren Arbeitsspeicher auf die Platte. Darin steht alles, was die Anwendung gerade im Speicher hatte – inklusive Passwörtern, Sitzungs-Tokens und Kundendaten.
- Log-Dateien: Debug-Logging, das „nur kurz” für die Fehlersuche eingeschaltet wurde, protokolliert oft vollständige Anfragen samt Authentifizierungs-Headern.
- Konfigurationsdateien:
.env-Dateien,config.php,appsettings.jsonoder Docker-Compose-Dateien mit eingetragenen Datenbankpasswörtern. - Skripte: Backup- oder Wartungsskripte, in denen das Admin-Passwort direkt im Code steht.
- Git-Repositories: Einmal eingecheckte Zugangsdaten bleiben in der Versionshistorie, auch wenn die Datei später korrigiert wurde.
- Netzlaufwerke und Wikis: Die Excel-Liste „Passwörter_IT.xlsx” oder die Confluence-Seite mit allen Router-Zugängen.
- Tickets und Chats: Zugangsdaten, die per E-Mail, Teams oder im Ticketsystem an den Dienstleister geschickt wurden.
Wie Angreifer diese Daten finden
Öffentlich erreichbare Webserver werden ständig automatisiert nach Pfaden wie /.env, /.git/ oder /heapdump abgesucht. Bei Spring-Boot-Anwendungen etwa ist ein falsch konfigurierter Actuator-Endpunkt ein bekannter Weg, an Heap-Dumps zu kommen. Im internen Netz durchsuchen Angreifer nach dem ersten Einbruch Freigaben und Laufwerke gezielt nach Begriffen wie „password”, „passwort” oder „secret”. Infostealer-Malware sammelt zusätzlich alles ein, was auf dem befallenen Rechner liegt – mehr dazu in unserem Artikel zu Infostealern.
Was Secrets-Management eigentlich bedeutet
Secrets-Management heißt: Zugangsdaten für Systeme und Anwendungen werden an einer zentralen, geschützten Stelle verwaltet – nicht verteilt über Dateien, Skripte und Postfächer. Dazu gehören drei Grundsätze:
- Zentral speichern: Passwörter für Menschen gehören in einen Passwortmanager wie Bitwarden bzw. Vaultwarden, Zugangsdaten für Anwendungen in einen Secrets-Speicher (z. B. HashiCorp Vault, OpenBao, Docker Secrets oder den Schlüsseltresor der Cloud-Plattform).
- Minimal berechtigen: Jede Anwendung bekommt ein eigenes Konto mit genau den Rechten, die sie braucht. Das Webshop-Konto muss die Buchhaltungsdatenbank nicht lesen können.
- Regelmäßig wechseln: Zugangsdaten werden rotiert – spätestens dann, wenn ein Mitarbeiter oder Dienstleister ausscheidet oder ein Leck vermutet wird.
Für ein KMU mit 20 Mitarbeitern muss das kein Großprojekt sein. Ein sauber eingerichteter Passwortmanager und Umgebungsvariablen statt fest eingetragener Passwörter lösen bereits einen großen Teil des Problems.
Praxis: In fünf Schritten Klartext-Zugangsdaten beseitigen
Schritt 1: Bestandsaufnahme mit Suchwerkzeugen
Durchsuchen Sie Server, Freigaben und Repositories gezielt. Bewährte Open-Source-Werkzeuge sind gitleaks und TruffleHog für Git-Repositories sowie einfache Suchen mit grep -riE "passw|secret|api_key|token" auf Linux-Servern. Auf Windows-Freigaben hilft eine Suche nach Dateinamen wie *passw*, *.env, *.kdbx oder *zugang*. Rechnen Sie mit Treffern – das ist der Normalfall.
Schritt 2: Dumps und Debug-Logs aufräumen
- Prüfen Sie, wo Ihre Anwendungen Crash- und Heap-Dumps ablegen, und löschen Sie alte Abbilder.
- Schalten Sie Debug-Logging in Produktivsystemen ab und setzen Sie Aufbewahrungsfristen für Logs.
- Stellen Sie sicher, dass Diagnose-Endpunkte (Actuator,
phpinfo(), Status-Seiten) nicht aus dem Internet erreichbar sind. - Legen Sie Dump-Verzeichnisse so an, dass nur Administratoren lesen dürfen.
Schritt 3: Webserver gegen versehentliche Freigabe absichern
Sperren Sie im Webserver den Zugriff auf .env, .git, Backup-Dateien (*.bak, *.sql, *.zip) und Konfigurationsverzeichnisse. Testen Sie das anschließend von außen. Viele dieser Fehler sind klassische Fehlkonfigurationen, die sich mit wenigen Zeilen Konfiguration beheben lassen.
Schritt 4: Gefundene Zugangsdaten sofort ändern
Ein Passwort, das einmal im Klartext lag, gilt als kompromittiert – auch wenn Sie keinen Missbrauch sehen. Ändern Sie es, bevor Sie die Datei löschen. Bei Git-Repositories reicht Löschen nicht, weil die Historie erhalten bleibt. Hier hilft nur: Zugangsdaten rotieren und die Historie gegebenenfalls bereinigen. Für API-Schlüssel gilt dasselbe.
Schritt 5: Neue Regeln verankern
- Zugangsdaten werden nie per E-Mail, Chat oder Ticket verschickt, sondern über den Passwortmanager geteilt.
- Anwendungen lesen Secrets aus Umgebungsvariablen oder einem Secrets-Speicher, nicht aus Quellcode.
- Ein Pre-Commit-Hook mit gitleaks verhindert, dass neue Zugangsdaten in Repositories landen.
- Admin-Konten werden getrennt und abgesichert, wie in unserem Beitrag zu Privileged Access Management beschrieben.
Datenschutz: Ein offener Dump kann meldepflichtig sein
Ein Heap-Dump oder Log enthält meist nicht nur Passwörter, sondern auch personenbezogene Daten von Kunden oder Mitarbeitern. War so eine Datei öffentlich abrufbar, kann das eine Datenschutzverletzung im Sinne der DSGVO sein – mit Meldepflicht innerhalb von 72 Stunden. Für ostdeutsche KMU ist dafür in Sachsen die Sächsische Datenschutz- und Transparenzbeauftragte zuständig. Dokumentieren Sie deshalb jeden Fund: Was lag wo, seit wann, und war es von außen erreichbar?
Unterstützung beim Secrets-Management in Dresden
Sie suchen Unterstützung in Dresden? Rexoma hilft KMU dabei, Zugangsdaten im Klartext aufzuspüren und dauerhaft sauber zu verwalten. Wir durchsuchen im Rahmen eines IT-Sicherheitsaudits Ihre Server, Freigaben und Repositories, sichern Webserver und Linux-Systeme ab und richten einen Passwortmanager sowie einen Secrets-Speicher passend zur Größe Ihres Betriebs ein. Betriebe in Dresden und ganz Sachsen betreuen wir auch vor Ort. Sprechen Sie uns an.
FAQ: Zugangsdaten im Klartext
Was ist ein Heap-Dump und warum enthält er Passwörter?
Ein Heap-Dump ist ein Abbild des Arbeitsspeichers einer laufenden Anwendung, das meist zur Fehlersuche erstellt wird. Da Anwendungen Passwörter, Tokens und Datensätze während der Verarbeitung im Speicher halten, stehen diese Daten im Dump unverschlüsselt drin.
Reicht es, eine Datei mit Passwörtern zu löschen?
Nein. Wer nicht ausschließen kann, dass die Datei gelesen wurde, muss die Zugangsdaten ändern. Bei Git-Repositories, Backups und Snapshots bleibt die gelöschte Datei außerdem oft noch erhalten.
Brauchen kleine Betriebe ein Werkzeug wie HashiCorp Vault?
Meist nicht sofort. Für viele KMU genügen ein zentraler Passwortmanager für Mitarbeiter und Umgebungsvariablen bzw. Docker Secrets für Anwendungen. Ein eigener Secrets-Speicher lohnt sich, sobald mehrere Server und selbst entwickelte Anwendungen im Spiel sind.
Wie finde ich heraus, ob bei mir Zugangsdaten offenliegen?
Mit Suchwerkzeugen wie gitleaks oder TruffleHog, gezielten Dateisuchen auf Servern und Freigaben sowie einem Test, ob Pfade wie /.env oder /.git/ auf Ihren Webservern von außen erreichbar sind. Ein externes Sicherheitsaudit deckt diese Punkte systematisch ab.
Rexoma IT