CVE-2019-3396

🔎 Informations principales :

• Produit affecté : Confluence Server & Data Center

• Versions affectées : de 6.0.0 à 6.15.4

• Sévérité : Critique (CVSS ~9.8)

• Cause :

  • Confluence dispose du plugin Widget Connector (utilisé pour intégrer des vidéos et du contenu externe comme YouTube, Vimeo...).

  • Cette fonctionnalité ne contrôle pas correctement les entrées utilisateur, ce qui mène à une Server-Side Template Injection (SSTI).

  • Un attaquant peut envoyer un payload malveillant → Confluence effectue le rendu avec le moteur de templates Velocity → exécution de code sur le serveur.

1. Installation et démarrage du site

• Installez une version vulnérable, par exemple la 6.9.0 :

https://www.atlassian.com/software/confluence/downloads/binary/atlassian-confluence-6.9.0.zip

• Suivez les étapes de configuration comme indiqué :

https://nguyendt.hashnode.dev/confluence-cve-2019-3396

• Une fois l’installation terminée, on obtient l’interface suivante :

2. Recherche du point vulnérable et débogage

2.1 Recherche du point vulnérable

• Selon le POC, la fonctionnalité vulnérable se trouve dans Widget Connector (utilisé pour intégrer des vidéos et du contenu externe comme YouTube, Vimeo...)
• Cherchons cette fonctionnalité :

1. Cliquez sur Other macros

2. Recherchez l’outil de résolution Widget Connector

3. Saisissez le lien, remplissez les informations demandées, puis cliquez sur Preview

2.2 Configuration pour le débogage

• Comme la description mentionne Widget Connector, essayons de le chercher dans le dossier source de Confluence

• Ouvrez le fichier .jar avec Intellij IDEA
• Placez des points d’arrêt aux endroits qui traitent la résolution du lien, puis lancez le débogage.

Déroulement du débogage

• Lancez le débogage et placez un point d’arrêt dans com.atlassian.confluence.extra.widgetconnector.WidgetMacro.class
• Ici, on voit les paramètres
• Appel de la classe DefaultRenderManager.class

• Ici, la méthode getEmbeddedHtml() est utilisée
• Retourne le code HTML permettant d’intégrer (embed) du contenu externe (vidéo, widget, document…) à partir d’une URL insérée par l’utilisateur dans une page Confluence
• Elle appelle ensuite YoutubeRenderer

• Entrez dans la classe YoutubeRenderer
• Au niveau de cette méthode : getEmbeddedHtml(String url, Map<String, String> params)
• url → le lien YouTube d’origine saisi par l’utilisateur
• params → une map contenant les paramètres de configuration pour le rendu (par exemple : largeur, hauteur, template utilisé pour le rendu, etc.).

• On continue avec les appels à getEmbedUrl(), setDefaultParam() et DefaultVelocityRenderService.render()
• Concentrons-nous sur setDefaultParam()

• Si _template n’existe pas → le template par défaut youtube.vm est assigné. => On peut donc ajouter soi-même _template au programme

• Passons maintenant à DefaultVelocityRenderService.render()

1. Objectif de la méthode

   • Reçoit url + les paramètres params.

   • Utilise le template Velocity (.vm) pour générer le HTML intégré (iframe, embed, …).

2. Détermination du template

   • Si params contient _template → utilise ce template.

   • Sinon → utilise le template par défaut embed.vm.

3. Crée le contexte par défaut avec MacroUtils.defaultVelocityContext().

• Ajoute tous les paramètres de params dans le contexte :

  • Si la clé est tweetHtml → le HTML est conservé tel quel.

  • Sinon → encodage sécurisé avec GeneralUtil.htmlEncode().

• Ajoute urlHtml, width, height au contexte (s’ils sont vides, valeurs par défaut 400 × 300).

• Appel de VelocityUtils.getRenderedTemplate()

• Passons maintenant à la classe VelocityUtils
• Plus haut, getRenderedTemplate et getRenderedTemplateWithoutSwallowingErrors() sont appelées

• Ensuite, getTemplate() est appelée

• Ici, templateName correspond au _template mentionné plus haut.

• Puis VelocityEngine.Template() est appelée

• Dans la classe VelocityEngine, RunimeInstance.getTemplate() est ensuite appelée

RuntimeInstance (noyau Velocity) C’est le « cœur » de Velocity Engine. Il s’occupe de :

• Initialiser le moteur (init)

• Gérer la configuration, les macros, le parser, les directives, les gestionnaires d’événements…

• Et surtout : gérer les ressources via ResourceManager

→ Autrement dit, RuntimeInstance ne charge pas lui-même les ressources, mais délègue cette tâche à resourceManager.

• Ensuite, CompatibleVelocityResourceManager.getResource() est appelée

ConfigurableResourceManager (personnalisé par Confluence) C’est une implémentation de l’interface ResourceManager. Il est responsable de :

• Gérer les resource loaders (file loader, classpath loader, URL loader…).

• Gérer le globalCache (cache des templates selon resourceKey).

• Charger/actualiser le template (fichier .vm) lorsque RuntimeInstance le demande.

try {
    this.refreshResource(resource, encoding);
} catch (ResourceNotFoundException var7) {
    this.globalCache.remove(resourceKey);
    return this.getResource(resourceName, resourceType, encoding);
}

• Lorsqu’une ressource est dans le cache, elle n’est pas renvoyée immédiatement : refreshResource(...) est appelé.

• refreshResource compare la date de dernière modification sur le disque avec celle du cache.

• Si le fichier a changé → la ressource en cache est invalidée → rechargée depuis le disque → le cache est mis à jour.