CVE-2024-56353
May 12, 2025
- Anwendung/Komponente: JetBrains TeamCity
- Betroffene Version: < 2024.12
- Score (CVSS 3.1): 6.5 Medium
- Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
- CWEs:
- CVE: CVE-2024-56353
Im Rahmen eine näheren Analyse von JetBrains TeamCity konnte ich eine Schwachstelle finden.
Beschreibung
TeamCity unterstützt das Erstellen von Backups. Um Backups erstellen zu können, benötigt
ein Nutzer die Berechtigung Change backup settings and control backup process. Die Backupdatei
wird standardmäßig in <TeamCity Data Directory>/backup gespeichert, kann aber in der
backup-config.xml konfiguriert werden.
Die Datenbankdatei beinhaltet wohl einen (kompletten) Datenbankdump mit Hashes von Benutzerpasswörtern sowie die “Remember Me”-Cookies. Mithilfe der “Remember Me” Cookies ist es möglich, sich als andere Nutzer anzumelden, wenn diese die “Remember Me”-Funktion verwenden.
Die Hashes wären dagegen einem Offline-Brute-Force Angriff ausgesetzt. Damit liegt es allein an der Komplexität des Passwortes, ob diese in endlicher Zeit knackbar ist oder nicht.
PoC: Accountübernahme mittels “Remember Me”
Man meldet sich als Nicht-Admin an TeamCity an. Der Nutzer hat die Rechte Change backup settings and control backup process. Man
erstellt ein Backup mit dem Backup scope “Basic”:
Anschließend kann die Backupdatei z.B. über das “History” Tab heruntergeladen werden.
Nachdem man die ZIP-Datei geöffnet und ggf. entpackt hat, sucht man nach dem Ordnet database_dump. Dort findet man die
Datei remember_me:
Das RememberMe cookie ist ein zusammengesetzter Wert aus den Tabellenspalten USER_KEY und SECURE, der wie folgt als Cookie
im Browser gespeichert wird:
<USER_KEY>#<SECURE>
Legt man sich ein Cookie mit dem Namen RememberMe an und schreibt dort als Value <USER_KEY>#<SECURE>, wird man als User
eingeloggt, der diesem Wert gehört.
PoC: Zugriff auf gehashte Nutzerpasswörter
Im selben Datenbank-Dump gibt es eine Datei namens user:
Diese Datei beinhaltet Passworthashes der Nutzer:
Diese können nun z.B. mittels Hashcat oder JtH gecrackt werden, falls die Komplexität niedrig genug ist. Sollte das Passwort geknackt werden, kann man sich als Nutzer anmelden.
Lessons Learned
Grundsätzlich sollte bei allen Exportfunktionalitäten geprüft werden, welche Daten exportiert werden und ob diese exportiert werden müssen – vor allem bei Backupdateien.
Für ein Backup ist es z.B. nicht erforderlich, Cookies zu exportieren. Sollte es notwendig sein ein Backup wieder einzuspielen, so muss der Nutzer im Worst-Case sich erneut wieder anmelden.
Werden sensible Daten exportiert – und dazu gehören Nutzerdaten definitiv (vor allem, wenn weitere sensitive Daten wie E-Mail-Adressen enthalten sind), sollte die Backupdatei mit einem Anwendungsschlüssel (symmetrisch) verschlüsselt werden. Nur die Anwendung sollte diesen Schlüssel kennen, sodass kein anderer Nutzer (auch nicht der Anwendungsadmin) diese Datei öffnen kann.
Es besteht kein Grund, wieso ein Nutzer einen Einblick in Datenbank-Dumps bekommen soll. Das käme einem Read-Only Zugriff auf die betroffene Datenbank gleich. Dafür gibt es aber DB-Admins, die sich um sowas kümmern.
Hinweis
Alle Tests wurden auf der eigenen, lokalen Instanz (mittels Docker) durchgeführt sowie mit eigenen, erstellten Test-Nutzerdaten.
Jetbrains hat schnell, konstruktiv und professionell reagiert.
Timeline
- Meldung am 13.09.2024 an JetBrains
- Rückmeldung am 13.09.2024
- Fehler behoben und Nachtest am 29.10.2024
- Test beendet am 19.11.2024
- Patch veröffentlicht am 05.12.2024
- CVE-Eintrag am 20.12.2024 mit CVE-2024-56353
- Release des Blog-Eintrages: 12.05.2025