• 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.

• 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.

👉 Vous n’avez donc pas besoin de modifier resourceKey manuellement. Le mécanisme de refresh garantit que lorsque le template change, le cache est également mis à jour.

Ajoutez _template et renvoyez la requête

• On voit la liste des instances de ResourceLoader (objets déjà initialisés) dans Velocity

• Ici, nous ne nous intéressons qu’à FileResourceLoader et ClasspathResourceLoader

1. Avec FileResourceLoader

StringUtils.normalizePath() est appelé pour bloquer les traversées de chemin (path traversal)

• Le contenu de normalizePath est visible sur l’image

• Essayez de lire le fichier /WEB-INF/web.xml et vous verrez que le fichier est chargé avec succès.

• Mais il reste impossible de sortir du répertoire de Confluence car /../ est bloqué.
• Continuons avec ClasspathResourceLoader

2. ClasspathResourceLoader

• Suivi jusqu’à ClassUtils.getResourceAsStream

• Il appelle findResource() de /org/apache/catalina/loader/WebappClassLoaderBase.class

• Il appelle ensuite super.findResource(), qui retourne une URL ; l’objet peut donc être récupéré.

• url.openStream() est appelé pour récupérer les données

• Enfin, les données sont injectées dans le rendu Velocity.

• Si, dans un cas réel, vous ne connaissez pas le chemin exact, vous pouvez utiliser le schéma de fichier (file) de Java pour obtenir la liste des répertoires.

Avec connexion sortante (outbound)

Payload exécuté

• $runtime.exec("id") → exécute la commande système "id" sur Ubuntu.
• Ouvrez un service FTP avec la commande :

Exécution :