Cet article, publié par Quarkslab, décrit une compromission d’une instance Confluence hébergée sur une machine virtuelle EC2 dans un compte AWS lors d’un engagement Red Team. Bien que l’équipe ait compromis la machine hébergeant Confluence, elle n’avait pas d’accès applicatif direct mais a pu interagir avec la base de données sous-jacente.
L’article détaille comment l’équipe a exploré la structure de la base de données Confluence et les mécanismes de génération de tokens API. Plusieurs méthodes ont été envisagées pour obtenir un accès privilégié sans utiliser de identifiants valides, notamment en modifiant des mots de passe d’utilisateurs, en créant de nouveaux comptes administrateurs, ou en générant des tokens API.
L’équipe a finalement réussi à générer un token API en étudiant le processus de génération de tokens et en exploitant les relations entre différentes tables de la base de données. Ce token a permis d’accéder à l’API REST de Confluence pour extraire des données sensibles sans perturber le système ou éveiller les soupçons.
L’article illustre l’importance de la sécurité des bases de données et des mécanismes d’authentification, soulignant les risques associés à des configurations de sécurité insuffisantes. Il met en lumière comment des recherches approfondies et une compréhension des systèmes peuvent mener à des compromis réussis dans des environnements complexes.
Ce document est une publication de recherche technique visant à démontrer les capacités d’exploitation d’une équipe Red Team et à sensibiliser sur les vulnérabilités potentielles dans les systèmes Confluence.
🔗 Source originale : https://blog.quarkslab.com/a-story-about-confluence-and-tokens.html