Résumé
Les chercheurs de Varonis ont parcouru une liste de 812 sous-domaines et ont détecté 689 instances Jira accessibles. Nous y avons repéré 3 774 tableaux de bord, 244 projets et 75 629 tickets publics contenant des adresses e-mail, des URL et des adresses IP.
Nous avons également déterminé que l’API REST Jira dévoile davantage d’informations que l’interface Web. Un administrateur peut ainsi estimer être tranquille alors que les attaquants ont accès à des données via l’API. Certaines des informations que nous avons trouvées ont été volontairement rendues accessibles au public (par exemple les tableaux de bord et tickets associés à des projets open source), mais d’autres contiennent des informations sensibles auxquelles l’administrateur Jira de l’entreprise concernée devrait bloquer l’accès. Remarque : ce problème n’est PAS une vulnérabilité de Jira. Les données sont exposées uniquement lorsqu’un client ne configure pas correctement les paramètres. Nous avons fait part à Atlassian de nos découvertes.Impact
Au premier abord, la visibilité d’URL et d’adresses e-mail peut sembler inoffensive, mais les adresses e-mail associées aux tickets Jira peuvent révéler l’identité des clients d’une entreprise. Certains des tickets Jira que nous avons détectés présentent quant à eux des bugs, des fonctionnalités de produits et des informations liées aux feuilles de route. Dans certains cas, un utilisateur de Jira peut volontairement exposer un tableau de bord ou un filtre. Malheureusement, notre recherche montre que les erreurs de configuration restent fréquentes. Nous avons par exemple constaté que le tableau de bord par défaut d’un transporteur, System (Système), disposait d’une URL accessible publiquement menant à des systèmes sensibles (serveurs de build, référentiel de code source, outils de feuille de route). Il s’agit du point de départ idéal pour lancer une attaque de phishing ou procéder à un déplacement latéral. L’instance Jira d’un prestataire de services bancaires que nous avons analysée exposait des dizaines d’adresses e-mail d’employés pouvant être utilisées pour usurper leur identité ou lancer une attaque de credential stuffing/par force brute contre les applications SaaS de la banque.Contexte
Jira est un outil populaire de gestion de tickets et de développement agile proposé par Atlassian. Il est disponible en deux versions : Jira Cloud et Jira server (sur site). Il contient des tableaux de bord qui aident les responsables de produit et les développeurs à suivre l’avancée de leurs projets. Ces tableaux de bord peuvent disposer de filtres. Tableaux de bord et filtres intègrent des paramètres permettant de déterminer qui peut les visualiser et les modifier. Voici un exemple de tableau de bord Jira (dont nous avons masqué certaines informations) qui n’est très probablement pas censé être accessible sur Internet :
Comment peut-on en arriver là ? Deux paramètres Jira sont souvent mal compris et mal configurés par les administrateurs :
- Public sharing (Partage public). Ce paramètre permet aux utilisateurs de partager leurs tableaux de bord et filtres avec tous les utilisateurs, y compris les utilisateurs anonymes.
- Modèle d’autorisations avec le groupe « public ». Certains administrateurs Jira partent du principe que l’option « public » signifie « ouvert à tous les membres de l’entreprise » alors qu’elle ouvre aussi les accès librement sur Internet.
Atlassian a mis à jour son interface utilisateur pour aider ses clients à ne plus faire cette grave erreur. En 2016, l’entreprise avait déjà modifié le nom de ce paramètre en le passant de Everyone (Tout le monde) à Public et ajouté un message d’avertissement :
Elle a également ajouté un paramètre global permettant aux administrateurs de désactiver entièrement le partage public. Ce paramètre est accessible depuis JIRA Admin > System > General Configuration > Edit Settings (Administration JIRA Admin > Système > Configuration générale > Modifier les paramètres). Il faut néanmoins savoir que la désactivation globale du partage public n’entraîne pas automatiquement la suppression des autorisations publiques accordées à des objets Jira précédemment. Vous devrez donc reconfigurer les paramètres de partage sur chaque tableau de bord.
Un problème ancien qui prend de nouvelles formes
Ce n’est pas la première fois qu’un rapport concernant les erreurs de configuration des autorisations Jira est publié, mais les résultats de nos chercheurs valent la peine qu’on s’y arrête. Tout d’abord, nous souhaitions mettre en lumière ce problème auprès des administrateurs Jira qui disposent peut-être encore d’instances mal configurées, dont les données sensibles sont exposées. Ensuite, notre équipe a également déterminé qu’il était possible d’exposer via l’API REST de Jira encore plus de données que via l’interface Web. Avec l’API REST, un attaquant peut, à l’aide d’un simple script, analyser le compte Jira d’une entreprise et en extraire rapidement les données sensibles. Voici un exemple de tableau de bord Jira consulté via l’interface Web. A priori, il n’y a pas grand-chose à voir :
Voici maintenant le même tableau de bord, accédé cette fois-ci depuis l’API REST :
La réponse de l’API dévoile l’identité du propriétaire, notamment son nom, son avatar et l’URL de sa page utilisateur.
Quels sont les risques ?
Qu’est-ce qu’un attaquant peut faire des informations révélées par les tableaux de bord Jira ? Reconnaissance. À partir du nom d’un projet, de ses propriétaires et de leurs avatars, un attaquant peut monter une campagne de phishing ciblée. Déplacement latéral. Nous avons constaté que certains tableaux de bord Jira contiennent des données sensibles sur d’autres outils et systèmes de l’entreprise (adresses IP internes, URL, identifiants, etc.). Armé des URL de systèmes connectés à Internet, un attaquant peut lancer une attaque par pulvérisation de mots de passe ou credential stuffing, ou encore exploiter des vulnérabilités connues de ces systèmes. Exfiltration. Dans les cas graves, un attaquant n’aura pas besoin d’utiliser les informations récupérées sur Jira pour passer sur des systèmes plus sensibles, car ces informations sont enregistrées directement dans le tableau de bord Jira.Quels volumes de données sont publics ?
À l’aide de l’API REST, notre équipe a découvert 689 sous-domaines Atlassian présentant des projets, filtres, tableaux de bord ou tickets publics. Lors de notre analyse des domaines des entreprises du Fortune 1000, nous avons bien souvent trouvé des instances du tableau de bord système n’exposant que son propriétaire. Dans certains cas, nous avons toutefois détecté des centaines de tickets exposés.- 812 sous-domaines Atlassian vérifiés
- 689 sites trouvés (84 %)
- Nombre moyen d’objets publics par compte :
- 87 filtres
- 6 tableaux de bord
- 12 projets
- 4 448 tickets
- Nombre total d’objets publics trouvés :
- 23 135 filtres
- 3 774 tableaux de bord
- 244 projets
- 75 629 tickets
- Informations potentiellement sensibles :
- 2 922 adresses e-mail
- 5 424 adresses IPv4
- 60 411 URL
Mitigation : comment auditer les paramètres Jira
Voici quelques mesures permettant de vous assurer que votre instance Jira est configurée exactement comme vous le souhaitez.- Suivez cet excellent guide d’Atlassian pour supprimer l’accès public.
- Vérifiez chaque autorisation publique sur la page des autorisations globales :
- Rendez-vous dans Settings -> System -> Global Permissions (Paramètres -> Système -> Autorisations globales).
- Assurez-vous qu’aucune autorisation n’est associée au groupe public dans la colonne Users / Groups (Utilisateurs/Groupes) si vous ne souhaitez pas que l’accès correspondant soit ouvert sur Internet.
- S’il y en a, cliquez sur Delete (Supprimer) pour la supprimer.
- Vérifiez chaque modèle d’autorisations public.
- Rendez-vous dans Settings -> Issues -> Permission Schemes (Paramètres -> Tickets -> Modèles d’autorisations).
- Vérifiez chaque modèle d’autorisations et supprimez l’accès public selon vos besoins.
- Veillez à ce qu’aucun groupe associé à l’avertissement Any logged in or anonymous user can browse this project (Tout utilisateur identifié ou anonyme peut parcourir ce projet) ne figure dans la colonne Granted (Octroyé).
- Si vous en voyez, cliquez sur Delete (Supprimer) pour supprimer le groupe/groupe public. Nous recommandons de retirer ce groupe de tous les projets.
Conclusion
Ce n’est pas pour rien si le risque « Contrôle d’accès inapproprié » est passé à la première place du Top 10 des risques de sécurité des applications Web établi par l’OWASP. Les entreprises doivent gérer des dizaines d’applications SaaS, chacune disposant de ses propres modèles d’autorisations et paramètres. Nombre d’entre elles sont interconnectées et accessibles depuis Internet, ce qui amplifie encore le risque. La moindre erreur de configuration peut rendre vos données accessibles à l’ensemble de votre entreprise ou pire, au reste du monde. Nous allons continuer à rechercher des erreurs de configuration SaaS et à partager nos découvertes pour aider les administrateurs à savoir ce qu’ils doivent vérifier pour limiter le risque pour leurs données dans le cloud. Nous ajoutons également en continu des fonctionnalités à DatAdvantage Cloud pour analyser automatiquement vos applications SaaS et détecter des erreurs de configuration fréquentes, mettre au jour les données sensibles exposées et vous alerter en cas de modification critique (par exemple le passage d’un paramètre de partage de privé à public).
Merci à Omri MAROM pour la version originale en anglais de ce Blog. Omri est un chercheur en sécurité basé à Tel Aviv. Il a ~7 ans d'expérience en cybersécurité, principalement axée sur les opérations offensives, le renseignement sur les menaces, la sécurité du Cloud et la sécurité des réseaux locaux. Pendant son temps libre, Omri aime regarder le football, jouer à la PlayStation et manger des pizzas.
