4.9 KiB
4.9 KiB
INCIDENT REPORT – CREDENTIAL EXPOSURE
Datum: 2026-02-22
Klassifikation: SICHERHEITSVORFALL (intern)
1. Zusammenfassung
Im Rahmen der systematischen Sicherheitsanalyse (STEP 4.4 – Klartext-Credentials entfernen) wurde ein produktives E-Mail-Passwort im Klartext in einer Konfigurationsdatei des Projekts entdeckt.
2. Betroffene Komponente
- Datei:
aza_email_config.json - Modul: AZA E-Mail (aza_email.py)
- Feld:
passwordimaccounts-Array - Betroffener Account: Produktiver Mail-Account (Details bewusst nicht aufgeführt)
3. Entdeckung
- Entdeckt durch: Automatisierte Security Gap-Analyse (STEP 3) und bestätigt bei der Implementierung von STEP 4.4
- Entdeckungsdatum: 2026-02-22
- Entdeckungsmethode: Grep-Suche nach
password,secret,tokenin allen JSON/YAML/Config-Dateien des Projekts
4. Risikoanalyse
Worst-Case-Szenarien
| Szenario | Risiko | Schwere |
|---|---|---|
| Unbefugter Zugriff auf das Dateisystem | Passwort-Exfiltration | HOCH |
| Account-Übernahme (Mail) | Lesen/Senden von E-Mails im Namen des Kontoinhabers | HOCH |
| Mail-Missbrauch | Spam, Phishing, Social Engineering über legitimen Account | HOCH |
| Laterale Bewegung | Falls Passwort wiederverwendet: Zugriff auf weitere Systeme | KRITISCH |
| Datenschutzverletzung | Zugriff auf medizinische Kommunikation (Patientendaten) | KRITISCH |
| Backup-/Export-Exposition | Passwort in Backups, Cloud-Syncs oder Transfers vorhanden | MITTEL |
Besondere Faktoren
- Medizinischer Kontext: E-Mail-Account einer Arztpraxis – potenziell Patientendaten in Mails (DSG/DSGVO-relevant)
- Expositionsdauer: Unbekannt. Das Passwort war seit der Erstellung der Konfigurationsdatei im Klartext gespeichert.
- Zugriffskreis: Alle Personen/Systeme mit Lesezugriff auf das Projektverzeichnis, Backups oder Transfers dieser Datei.
5. Sofortmassnahmen
| Nr | Massnahme | Status | Verantwortlich |
|---|---|---|---|
| 1 | Passwort aus Konfigurationsdatei entfernt | ERLEDIGT (STEP 4.4) | Security Engineer |
| 2 | Code umgestellt auf ENV-basierte Credentials | ERLEDIGT (STEP 4.4) | Security Engineer |
| 3 | Migrationswarnung implementiert | ERLEDIGT (STEP 4.4) | Security Engineer |
| 4 | Passwort beim Mail-Provider rotieren | OFFEN – DRINGEND | Projektinhaber |
| 5 | Prüfung ob Account kompromittiert wurde | OFFEN | Projektinhaber |
6. Empfohlene Folgeaktionen
Sofort (innerhalb 24h)
- Passwort beim Mail-Provider ändern (neues, starkes Passwort, mindestens 16 Zeichen, keine Wiederverwendung)
- 2FA aktivieren, falls der Mail-Provider dies unterstützt
- Login-Protokolle prüfen: Gibt es unbekannte Zugriffe auf den betroffenen Mail-Account?
Kurzfristig (innerhalb 1 Woche)
- Passwort-Wiederverwendung prüfen: Wurde dasselbe Passwort für andere Dienste/Systeme verwendet? Falls ja: dort ebenfalls rotieren.
- Backups durchsuchen: Prüfen, ob Kopien der Datei
aza_email_config.jsonin Backups, Cloud-Speicher, USB-Sticks, E-Mail-Anhängen oder anderen Transfers vorhanden sind. Falls ja: Passwort dort ebenfalls als exponiert betrachten. - Projekt-Kopien prüfen: Alle
backup *-Ordner und Kopien des Projektverzeichnisses auf Klartext-Passwörter durchsuchen.
Mittelfristig (Empfehlung)
- Secret-Scanning in CI/CD-Pipeline einführen (z.B. git-secrets, truffleHog, GitHub Secret Scanning), um zukünftige Klartext-Credentials automatisch zu erkennen.
- OS-Keychain-Integration evaluieren (Windows Credential Manager), um Passwörter sicher und benutzerfreundlich zu speichern.
7. Lessons Learned
Ursache
Das Passwort wurde direkt im GUI-Dialog eingegeben und ohne Schutzmassnahmen in eine JSON-Datei auf der Festplatte geschrieben. Es gab keine Trennung zwischen Konfiguration und Credentials.
Präventionsmassnahmen (implementiert)
- Credentials werden NIE mehr in Dateien geschrieben
(
_strip_passwords()insave_email_config()) - Credentials kommen ausschliesslich aus ENV-Variablen
(
AZA_EMAIL_PASSWORD_0,_1, ...) - Migrationswarnung bei bestehenden Klartext-Passwörtern in der Config
- Klartext-Passwörter in JSON werden ignoriert (kein Auto-Migrate)
Präventionsmassnahmen (empfohlen, nicht implementiert)
- Secret-Scanning in CI/CD
- Pre-Commit-Hooks für Secret-Detection
- OS-Keychain als sicherer Credential-Store
- Regelmässige Audits der Konfigurationsdateien
8. Referenzen
- STEP 3 – GAP-Analyse: Lücke #28 identifiziert
- STEP 4.4 – Implementierung der Credential-Entfernung
- STEP 4.4 Handover:
/security/handovers/STEP_4_4_CREDENTIALS.md
Erstellt: 2026-02-22 im Rahmen des AZA/MedWork Security & Compliance Projects Klassifikation: Intern – Nicht zur externen Weitergabe bestimmt