Blind SSRF dans les outils auto-hébergés : une surface d'attaque oubliée

Introduction

Il existe une catégorie de vulnérabilités que les équipes DevOps tendent à sous-estimer dans leurs déploiements internes : les failles SSRF (Server-Side Request Forgery), en particulier dans les outils qu’elles opèrent elles-mêmes. Outils Kanban, forges logicielles, systèmes de notification, plateformes de monitoring : ces applications émettent quotidiennement des requêtes HTTP sortantes dans le cadre de leur fonctionnement normal. Chacune de ces requêtes, si elle peut être orientée par un utilisateur, constitue un vecteur d’attaque potentiel.

Lors de l’audit de sécurité de notre infrastructure interne chez AstioLab, nous avons identifié une vulnérabilité blind SSRF dans Planka, un outil de gestion de projets Kanban open source que nous utilisons en production. Cette découverte, qui a fait l’objet d’une responsible disclosure à l’équipe Planka et référencée sous l’identifiant GHSA-c7mq-8hrx-524h, nous a conduit à réfléchir plus largement aux problèmes liés à cette classe de vulnérabilité.

Cet article s’adresse à vous si vous auto-hébergez vos outils. L’objectif n’est pas de fournir un guide d’exploitation, mais de comprendre le mécanisme, d’identifier les surfaces à risque dans vos déploiements et d’appliquer des mesures de protection efficaces.

SSRF et Blind SSRF : rappel du concept

Qu’est-ce que le SSRF ?

Une attaque SSRF (Server-Side Request Forgery, ou falsification de requête côté serveur) consiste à forcer une application à émettre des requêtes HTTP au nom de l’attaquant, vers des ressources qu’il ne pourrait pas atteindre directement.

Le principe est simple : si une application accepte une URL fournie par un utilisateur et émet une requête vers cette URL depuis son propre réseau, l’attaquant peut substituer une URL légitime par une cible interne.

SSRF classique vs Blind SSRF

Dans une SSRF classique, l’application renvoie le contenu de la réponse HTTP à l’attaquant, ce qui permet une exfiltration directe de données. C’est le cas typique des parseurs de flux RSS ou des générateurs de prévisualisations qui affichent un retour visuel.

Dans une Blind SSRF, la réponse n’est jamais renvoyée à l’attaquant. Ce qu’il peut néanmoins obtenir :

• Reconnaissance de ports (port scanning) : en mesurant les délais de réponse ou en observant les erreurs, il peut déterminer si un port est ouvert ou fermé sur un hôte interne.
• Détection hors-scope (OOB) : en utilisant un serveur de callback (Burp Collaborator, interactsh), il peut confirmer qu’une requête a bien été émise en observant les connexions DNS ou HTTP entrantes sur son infrastructure.
• Interaction involontaire : même sans lire la réponse, envoyer une requête HTTP à un service interne peut avoir des effets de bord : déclencher une action, créer une entrée dans des logs d’audit, ou interagir avec des services non authentifiés.

Avec un score CVSS de 5.4 (Médium), la blind SSRF est moins spectaculaire qu’une RCE ou une injection SQL, mais elle constitue un maillon solide dans une chaîne d’attaque plus large, particulièrement dans les environnements cloud.

Pourquoi les outils auto-hébergés sont particulièrement exposés

Les outils auto-hébergés sont conçus pour s’intégrer. Cette intégration passe systématiquement par des requêtes HTTP sortantes initiées par le serveur.

Les vecteurs les plus courants :

Le paradoxe de ces outils : ils sont souvent déployés sur un réseau interne précisément pour bénéficier de sa segmentation et de sa sécurité périmétrique. Mais leurs fonctionnalités d’intégration leur confèrent la capacité d’atteindre ce même réseau depuis l’intérieur. Un utilisateur malveillant (ou un compte compromis) peut ainsi utiliser l’outil comme relais involontaire vers l’infrastructure qu’il est censé protéger.

Retour d’expérience : la découverte dans Planka

Présentation

Planka est un outil de gestion de projets Kanban open source (React / Node.js / PostgreSQL), positionné comme alternative auto-hébergeable à Trello. Avec plus de 11 700 étoiles GitHub et 8 millions de pulls Docker, c’est un outil largement adopté par les équipes techniques soucieuses de la maîtrise de leurs données.

Les quatre surfaces d’attaque

En auditant notre déploiement, nous avons identifié quatre vecteurs distincts permettant à un utilisateur authentifié d’orienter des requêtes HTTP depuis le serveur Planka vers des cibles arbitraires :

1. Webhooks

Planka permet la configuration de webhooks pour notifier des systèmes tiers lors d’événements (création de carte, commentaire, déplacement). L’URL de destination est entièrement contrôlée par l’utilisateur, sans validation des plages d’adresses IP.

2. Système de notification Apprise

Apprise est une bibliothèque de notifications compatible avec plus de 100 providers (Slack, Discord, Telegram, e-mail…). Chaque provider est configuré via une URL. Sans restriction, n’importe quelle URL peut être fournie, y compris une cible interne.

3. Récupération de favicon pour les pièces jointes de type lien

Lorsqu’un utilisateur attache une URL à une carte Planka, l’application récupère le favicon du site côté serveur. Si l’URL pointe vers un hôte interne, c’est le serveur Planka qui effectue la requête, de manière transparente pour le reste de l’équipe.

4. Configuration SMTP via l’interface web

La v2.0.0 a migré la configuration du serveur d’envoi d’e-mails des variables d’environnement vers l’interface d’administration de l’application. Cette surface d’attaque est couverte par le correctif introduit dans la même version, mais reste un vecteur actif si le proxy est désactivé ou mal configuré.

Impact concret

Dans un déploiement sans protection réseau spécifique, ces vecteurs permettent de confirmer qu’un port interne est ouvert ou filtré (par analyse des délais de réponse), d’interagir avec des services non authentifiés sur le réseau interne, et de tenter d’atteindre des endpoints sensibles comme le service de métadonnées cloud.

La nature blind de la vulnérabilité est une limite importante : l’attaquant ne peut pas lire directement le corps des réponses HTTP. L’exploitation avancée, comme la récupération de credentials IAM (Identity and Access Management) depuis un endpoint IMDS (Instance Metadata Service d’AWS), nécessite de chaîner cette vulnérabilité avec d’autres techniques ou de trouver un canal de réponse indirect. L’impact direct reste principalement la reconnaissance réseau et l’interaction avec des services de confiance accessibles depuis le serveur.

Timeline de divulgation

Aucune CVE n’a été assignée à ce jour.

Le correctif

La correction introduit un proxy Squid interne qui fait transiter l’intégralité du trafic HTTP sortant de l’application. Des variables d’environnement permettent de le configurer précisément :

# docker-compose.yml - Planka v2.0.x
environment:
  # Option 1 : utiliser un proxy externe existant
  OUTGOING_PROXY: 'http://votre-proxy:3128'

  # Option 2 : configurer le Squid interne (activé par défaut dans Docker)
  # OUTGOING_BLOCKED_IPS est prioritaire sur OUTGOING_ALLOWED_HOSTS
  OUTGOING_BLOCKED_IPS: '10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254.169.254/32'
  OUTGOING_BLOCKED_HOSTS: 'localhost,postgres,redis'
  OUTGOING_ALLOWED_HOSTS: 'smtp.votre-fournisseur.com,api.service-tiers.com'

La v2.0.3 a également corrigé un contournement : dans les déploiements utilisant le mode host network Docker, le proxy Squid interne était accessible depuis des hôtes externes. Il n’accepte désormais les connexions qu’en provenance du serveur lui-même.

Si vous utilisez Planka : mettez à jour vers la version 2.0.3 minimum et configurez OUTGOING_BLOCKED_IPS et OUTGOING_ALLOWED_HOSTS en fonction de votre topologie réseau.

Modélisation des menaces pour les déploiements cloud

L’impact réel d’une blind SSRF dépend fortement du contexte de déploiement. Voici une analyse pour les environnements les plus courants en France.

AWS : le risque IMDS

Le service de métadonnées d’instance AWS est accessible par convention à l’adresse 169.254.169.254 depuis tout processus s’exécutant sur la VM.

• IMDSv1 (non sécurisé) : une simple requête HTTP GET permet d’accéder aux métadonnées d’instance, dont les credentials IAM temporaires. Combinée à une SSRF non-blind (ou à un canal de réponse indirect), cette exposition peut mener à la compromission du rôle IAM de l’instance.

• IMDSv2 (sécurisé) : requiert d’abord un appel PUT avec le header X-aws-ec2-metadata-token-ttl-seconds pour obtenir un token de session. Ce mécanisme réduit significativement le risque pour les SSRF simples reposant sur des requêtes GET, car la plupart des bibliothèques HTTP n’émettent pas de PUT implicites dans ce contexte. Toutefois, une SSRF offrant un contrôle total sur la méthode HTTP et les headers reste capable de contourner cette protection.

Recommandation pour AWS : appliquer l’IMDSv2 sur toutes les instances hébergeant des outils auto-hébergés.

# Appliquer IMDSv2 sur une instance existante
aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxxxxxxxxx \
  --http-tokens required \
  --http-endpoint enabled

OVHcloud : risques réseau interne

OVHcloud n’expose pas de service de métadonnées HTTP sur 169.254.169.254 de la même façon qu’AWS. Les structures de paths et les credentials exposés diffèrent. Le risque principal est la topologie réseau vRack : dans cette configuration, les services internes (bases de données, caches, API privées) sont accessibles depuis toutes les instances du réseau privé. Une blind SSRF permet de les scanner et d’interagir avec eux, notamment avec des services qui accordent leur confiance aux requêtes venant du réseau interne.

Scaleway : spécificités

Scaleway expose un service de métadonnées d’instance à la même adresse 169.254.169.254, mais avec une structure de paths et un modèle de credentials distincts de ceux d’AWS. L’exposition n’est pas identique. Le niveau de risque dépend des métadonnées effectivement disponibles et de la configuration de l’instance.

Le réseau interne : dénominateur commun

Indépendamment du cloud provider, le réseau interne est systématiquement la première surface à risque :

• Services non authentifiés accessibles uniquement depuis l’intranet (Redis sans auth, bases de données, interfaces d’administration)
• Autres outils auto-hébergés sur le même réseau
• Agents de monitoring et démons de gestion
• Services de CI/CD internes (Jenkins, Woodpecker, Concourse)
• Instances de bases de données avec accès direct depuis le réseau applicatif

Quels autres outils surveiller ?

Cette surface d’attaque touche tout outil auto-hébergé exposant des fonctionnalités d’intégration. Ce n’est pas une liste d’outils actuellement vulnérables, mais une invitation à auditer vos propres configurations :

• GitLab CE : les webhooks de projets permettent de configurer des URLs de destination. GitLab dispose d’une politique de protection SSRF configurable : vérifiez que Admin > Settings > Network > Outbound requests bloque bien les adresses privées dans vos déploiements.
• Gitea / Forgejo : même vecteur via les webhooks. Le paramètre [webhook] dans app.ini permet de restreindre les adresses autorisées (ALLOWED_HOST_LIST).
• Nextcloud : de nombreuses applications intégrées récupèrent des ressources distantes (partage de lien, prévisualisations, imports). Le trafic sortant doit être restreint au niveau réseau pour les déploiements en environnement sensible.
• Mattermost : les intégrations d’outgoing webhooks et les slash commands peuvent pointer vers des URLs internes.
• Rocket.Chat : même vecteur via les webhooks sortants et les intégrations OAuth.

La règle générale : tout outil qui permet à un utilisateur de configurer une URL vers laquelle le serveur émettra une requête est un candidat blind SSRF potentiel. Auditez ces points de configuration lors de chaque déploiement.

Durcissement

Ces mesures s’appuient sur l’OWASP SSRF Prevention Cheat Sheet et notre retour d’expérience terrain.

1. Approche par liste blanche (recommandée)

Définir explicitement les hôtes et plages IP que l’application est autorisée à contacter en sortie. Tout le reste est bloqué par défaut. C’est l’approche la plus robuste et la plus facile à auditer.

# Principe : n'autoriser que ce qui est strictement nécessaire
OUTGOING_ALLOWED_HOSTS: 'smtp.sendgrid.net,api.github.com,hooks.slack.com'

2. Validation côté serveur avec résolution DNS

Avant d’émettre une requête vers une URL fournie par un utilisateur, l’application doit :

1. Analyser l’URL et en extraire l’hôte
2. Résoudre le DNS pour obtenir l’adresse IP finale
3. Vérifier que cette IP n’appartient pas à des plages privées (RFC 1918, loopback 127.0.0.0/8, link-local 169.254.0.0/16)
4. Ne pas suivre les redirections sans revalider la destination finale

La résolution DNS avant vérification est critique pour deux raisons. Premièrement, un attaquant contrôlant un domaine peut configurer une entrée DNS pointant vers 169.254.169.254 : la validation du hostname seul ne suffit pas. Deuxièmement, il faut se prémunir du DNS rebinding : la résolution effectuée au moment de la validation peut renvoyer une IP publique légitime, tandis qu’une seconde résolution au moment de l’exécution renvoie une IP privée. La bonne pratique consiste à résoudre l’IP une seule fois, la valider, puis l’utiliser directement pour la connexion, sans résoudre à nouveau.

3. Proxy sortant dédié

Faire transiter tout le trafic HTTP sortant de l’application par un proxy (Squid, Tinyproxy) qui applique les règles d’autorisation de façon centralisée, avec journalisation des accès. C’est exactement l’approche retenue par Planka v2.0. Le proxy constitue également un point d’audit précieux pour détecter des tentatives d’exploitation.

4. Segmentation réseau (défense en profondeur)

Au niveau infrastructure, restreindre les flux sortants des conteneurs ou VMs hébergeant les outils auto-hébergés :

# iptables : bloquer le trafic sortant vers les plages privées depuis un conteneur
# (chaîne FORWARD, valable pour les conteneurs en mode bridge)
iptables -I FORWARD -s <IP_CONTENEUR>/32 -d 10.0.0.0/8 -j DROP
iptables -I FORWARD -s <IP_CONTENEUR>/32 -d 172.16.0.0/12 -j DROP
iptables -I FORWARD -s <IP_CONTENEUR>/32 -d 192.168.0.0/16 -j DROP
iptables -I FORWARD -s <IP_CONTENEUR>/32 -d 169.254.169.254/32 -j DROP

Note : la chaîne FORWARD est contournée en mode --network=host. Si vos conteneurs utilisent ce mode (comme le montrait le contournement corrigé dans Planka v2.0.3), appliquez les règles sur la chaîne OUTPUT ou isolez ces conteneurs dans un réseau dédié.

Pour les déploiements Kubernetes, les NetworkPolicy permettent de définir ces restrictions déclarativement.

5. IMDSv2 obligatoire sur toutes les instances cloud

Appliquer IMDSv2 réduit significativement le risque SSRF sur les endpoints de métadonnées pour les vecteurs exploitant des requêtes GET simples. Ne laissez aucune instance en IMDSv1, notamment les instances hébergeant des outils à forte surface d’intégration.

6. Audit des permissions utilisateurs

Limiter qui peut configurer des webhooks, des intégrations SMTP et des URLs de notification dans vos outils. Ces fonctionnalités doivent être réservées aux administrateurs, pas aux utilisateurs standards. Dans Planka, la configuration SMTP et les webhooks système nécessitent des droits d’administrateur, mais les webhooks de board peuvent être configurés par les membres : tenez-en compte dans votre modèle de permissions.

Conclusion

L’auto-hébergement d’outils est un choix légitime, particulièrement en France, où la localisation des données, la conformité RGPD et la souveraineté numérique sont des préoccupations concrètes. Mais cet auto-hébergement transfère la responsabilité de sécurité vers les équipes qui opèrent ces outils.

La blind SSRF touche structurellement les outils conçus pour s’interfacer avec des services externes, soit la quasi-totalité des outils modernes auto-hébergés. Son impact direct reste limité, mais elle constitue une brique de reconnaissance et d’interaction réseau que les attaquants savent exploiter dans des chaînes d’attaque plus complexes.

Les mesures de durcissement existent, sont documentées et restent simples à appliquer. Ce qui manque souvent, c’est leur application systématique aux outils internes, lesquels bénéficient d’une confiance implicite que les attaquants ont appris à exploiter.

Auditez vos déploiements. Vérifiez vos configurations de webhooks et d’intégrations. Appliquez la segmentation réseau. Et si vous n’êtes pas sûrs de votre exposition, c’est exactement pour ça qu’on est là.

Votre infrastructure est-elle exposée ?

Chez AstioLab, nous accompagnons les équipes dans la sécurisation de leurs environnements auto-hébergés. Audit de configuration, modélisation des menaces, mise en place de segmentation réseau et de politiques de trafic sortant : nous intervenons sur l’ensemble de la chaîne.

Vous avez un doute sur votre exposition ou souhaitez auditer vos outils internes ? Contactez-nous.

Suivez-nous

Cet article vous a plu ?

Rejoignez-nous sur nos différents réseaux sociaux pour suivre notre actualité ! Nous y partageons nos nouveautés, nos réalisations, ainsi que des retours d’expérience sur les projets que nous menons au quotidien.

Vous pouvez également suivre notre blog via notre flux RSS, afin de ne manquer aucune publication. De nouveaux articles seront publiés régulièrement, avec pour objectif de vous présenter nos réalisations, de promouvoir les bonnes pratiques de l’ingénierie logicielle, et de décrypter l’actualité technique et numérique.