Analyse d'un exemple d'utilisation de la vulnérabilité JIRA pour accéder au réseau de routeurs de protocole Internet non classifié de l'armée américaine

Ce qui suit décrit comment l'auteur a participé au projet de test public de la vulnérabilité Hack the Pentagon du Département américain de la Défense (DoD) et a utilisé la vulnérabilité JIRA CVE-2017-9506 pour construire une surface d'attaque SSRF et obtenir des résultats non classifiés. Accès Internet pour l'armée américaine. L'accès au réseau de routeurs de protocole (NIPRnet), combiné à d'autres techniques de vulnérabilité, a permis d'obtenir une série d'informations sensibles du système intranet du DoD. En raison de la nature confidentielle du processus et du contenu du test, cet article n'aborde que ce point sans divulguer trop de détails techniques et de scénarios détaillés. Il est uniquement destiné à l'apprentissage et au partage, et j'espère que les lecteurs me supporteront.

JIRA est un excellent outil logiciel de suivi et de gestion des problèmes développé par la société Atlassian en Australie. Il peut suivre et gérer divers types de problèmes, notamment les défauts, les tâches, les exigences, les améliorations, etc. De nombreuses entreprises renommées et organisations de logiciels open source utilisent JIRA car elle utilise la technologie J2EE et peut être déployée sur plusieurs plates-formes.

Commencer depuis le début - À la découverte du site Web de l'application JIRA du DoD

En participant au projet de tests publics de vulnérabilité du ministère américain de la Défense (DoD), j'ai trouvé deux sites Web spéciaux. J'ai déployé l'outil de gestion de suivi de projet JIRA. Après une analyse préliminaire, je pensais qu'il n'y avait aucune vulnérabilité exploitable, je n'ai donc pas continué à creuser plus profondément.

Plus tard, j'ai trouvé un post sur Twitter qui exploitait la vulnérabilité JIRA pour implémenter des attaques SSRF :

#🎜🎜 #

Cela signifie ceci :

Attention, utilisateurs de JIRA ! Les attaquants peuvent exploiter la vulnérabilité JIRA CVE-2017-9506 pour voler vos données intranet. Il s'agit d'une vulnérabilité de redirection ouverte, mais dans certains cas, elle peut être exploitée pour rediriger vers l'adresse de lien local du système JIRA interne, conduisant à la divulgation de certaines informations sur les ressources internes telles que les clés AWS.

Description de la vulnérabilité JIRA CVE-2017-9506

L'agence néerlandaise de recherche en sécurité Dontpanic a donné une estimation approximative de CVE-2017- 9506 Raison de la vulnérabilité : Il existe un composant appelé IconUriServlet dans le plugin Atlassian OAuth inclus dans JIRA. Il est utilisé pour recevoir des requêtes GET avec la valeur de paramètre consumerUri du client, mais le composant IconUriServlet peut également être utilisé pour créer des commandes exécutées par le client. serveur. Un autre type de requête HTTP GET. Cette requête est initiée par JIRA en tant que proxy indirect. Le serveur répond puis renvoie au client via JIRA. Au cours de ce processus, en construisant la requête, les informations internes du serveur peuvent être divulguées. et renvoyé dans le contenu de la réponse au client.

Méthode de vérification de vulnérabilité donnée par Dontpanic :

https://%basepath%/plugins/servlet/oauth/users/icon-uri?consumerUri= https ://google.com

Remplacez le chemin de base par le lien du site Web du système JIRA Après avoir accédé à la page ci-dessus, si la page google.com apparaît normalement, cela prouve que le système JIRA a. cette vulnérabilité ; si Si une page 404 apparaît lors de l'accès, la vulnérabilité n'existe pas. Notez que vous ajoutez la requête pour le site Web que vous souhaitez tester à la fin du consumerUri! ! !

Test de la vulnérabilité du site Web de l'application JIRA du DoD

Après avoir lu attentivement la description de CVE-2017-9506, j'ai eu l'impression d'avoir trouvé un trésor et je me suis rapidement retourné aux deux découvertes précédemment. Un site Internet du ministère de la Défense s'est empressé de vérifier la faisabilité de cette technologie d'exploitation des vulnérabilités. Après avoir testé l'un des sites Web, j'ai découvert que je pouvais accéder avec succès à la page Google, ce qui signifie qu'il doit y avoir une vulnérabilité dans le site Web !

https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://google.com

# 🎜🎜#

Selon la réglementation AWS, toute instance peut récupérer ses propres métadonnées d'instance en demandant l'adresse de métadonnées 169.254.169.254 définie par AWS Exemple (. les méthodes pertinentes peuvent être trouvées dans les instructions officielles d'AWS), pour lesquelles j'ai construit le lien suivant pour lancer une demande :

https://website.mil/plugins/servlet /oauth /users/icon-uri?consumerUri=http://169.254.169.254/latest/meta-data/local-hostname/

# 🎜🎜 #

Je peux effectivement voir le nom de l'hôte interne ! D'accord, laissez-moi essayer d'obtenir la clé AWS :

https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri= http://169.254 .169.254/latest/meta-data/iam/security-credential

Mais cela ne semble pas fonctionner. Après avoir lu attentivement la documentation officielle d'AWS, j'ai réutilisé le lien suivant pour obtenir l'ID de l'instance, l'adresse IP privée et d'autres informations :

https://website.mil/plugins/servlet/ oauth /users/icon-uri?consumerUri=http://169.254.169.254/latest/dynamic/instance-identity/document

Très bien, ils ont tous répondu avec succès L'obtenir!

À ce stade, j'ai pensé qu'il devrait être capable d'expliquer le problème, j'ai donc simplement rédigé un rapport de vulnérabilité et l'ai soumis sans tests supplémentaires. Cependant, après cela, le personnel de classification du projet du DoD a classé la vulnérabilité comme moyenne. vulnérabilité au risque, mais je pense qu'il s'agit certainement d'une vulnérabilité à risque élevé. Après avoir parlé avec le ministère de la Défense, j'ai demandé l'autorisation de procéder à des tests approfondis afin de tester l'impact ultime de cette vulnérabilité.

Tests approfondis - accès au réseau de routeurs de protocole Internet non confidentiel (NIPRnet) et obtention d'autres informations sensibles

Reconnaissance préliminaire découverte#🎜 🎜#

Tout d'abord, j'ai commencé par la détection de port de base et j'ai découvert que le système cible avait ouvert les ports 21, 22, 80, 443 et 8080. Avec ces informations sur le port, je peux tester diverses erreurs. Les informations sont renvoyées et l'état du déploiement du serveur et du réseau dans le système cible est jugé à l'aide de ces informations. Voici les informations de réponse après qu'une requête est adressée au port 8080 du système cible :

#🎜. 🎜#

#🎜🎜 #Deuxièmement, j'ai fait un test de requête sur d'autres protocoles tels que le protocole de visualisation du répertoire de fichiers Gopher, le protocole de serveur de dictionnaire DICT, le protocole FTP, le protocole d'accès au répertoire léger LDAP, etc. Si le système renvoie la réponse suivante qui ne prend pas en charge LDAP :

Comprehensive Utilization Discovery

Enregistrez-les En lisant les informations, j'ai pensé au partage de recherche "Cracking the Lens: Targeting HTTP's Hidden Attack-Surface" par James Kettle, chercheur en chef de PortSwigger, lors de la conférence Black Hat des États-Unis en 2017. James Kettle a construit une requête HTTP malveillante et des informations d'en-tête pour décrire. Il a découvert la surface d'attaque cachée du service HTTP dans le système cible. Finalement, il a utilisé cette technologie pour se « déguiser » en identité IP interne du ministère de la Défense des États-Unis, et a réussi à envahir et à accéder au réseau interne restreint du DoD. systèmes et ressources associées. Je me souviens que dans le partage de Kettle, il a également montré deux sites Web internes du DoD qu'il avait utilisés pour les tests d'intrusion : (Source d'informations sur le site Web défensivecarry.com)

https://safe.amrdec. army.mil/safe/

https://dots.dodiis.mil/

Combiner ces deux sites Web internes de James Kettle pour le DoD mentionné, j'ai utilisé les deux sites Web DoD JIRA que j'ai trouvés pour leur lancer des demandes. Le but est de tester si l'accès aux deux sites Web internes du DoD mentionnés par James Kettle peut être obtenu de cette manière. Finalement, après avoir utilisé l'un des sites JIRA pour faire une requête aux deux sites internes du DoD mentionnés par James Kettle, l'un d'eux a affiché un délai d'attente de requête :

# 🎜🎜#another One a renvoyé un message d'avertissement du gouvernement américain (USG), comme suit :

Lors de ce test, j'ai également découvert d'autres DoD Service de pages Web internes, grâce à ce service Web interne, j'ai pu accéder avec succès au réseau de routage du protocole de non-confidentialité (NIPRnet) de l'armée américaine, qui est utilisé en interne par le DoD pour traiter des informations sensibles inférieures au niveau secret. En raison du principe de confidentialité, je ne divulguerai pas ici en détail les méthodes et méthodes spécifiques.

Acquérir des informations sensibles internes en jugeant le contenu de la réponse

Après avoir utilisé le deuxième site Web JIRA pour lancer des requêtes vers les deux sites Web internes du DoD mentionnés par James Kettle, Les informations de réponse renvoyées sont fondamentalement inutiles.

Après les tests, j'ai finalement découvert que l'ouverture des ports système internes du DoD peut être évaluée en fonction du temps de réponse. Par exemple, lors d'une demande du port 22 au système interne, la réponse prend 1 000 millisecondes, tandis que lors d'une demande du port 21, la réponse prend près de 10 000 millisecondes. À partir de ce décalage horaire, certaines conditions du port peuvent être devinées. De plus, en raison du manque de réponse détaillée aux messages d'erreur, je ne peux pas porter de jugement sur le protocole spécifique du système, mais je tiens à souligner que l'objectif de cet article est le suivant : via le serveur Web interne, je peux accéder aux informations du DoD. protocole de routage non confidentiel Net (NIPRnet) ! J'ai également utilisé le plug-in Collaborator de Burp pour détecter les fuites d'informations dans l'échange de données entre le serveur et le demandeur après le lancement de la requête vers le serveur Web.

Par exemple, l'adresse IP interne peut être obtenue à partir du 'X-Forwarded-For' dans l'en-tête de la requête. J'ai utilisé le plug-in Collaborator de Burp pour interroger toutes les adresses IP internes interactives, bien qu'à la fin je l'ai fait. a pu interroger l'adresse IP interne et les informations du service réseau associé, mais la récupération des métadonnées AWS ne peut pas être effectuée sur le serveur Web.

En fin de compte, après avoir soumis les deux vulnérabilités impliquées au DoD, les deux vulnérabilités ont été jugées critiques. À partir de là, j'ai pensé aux deux SSRF que j'ai signalés au DoD au début de cette année. , je veux voir si les vulnérabilités ci-dessus peuvent être exploitées en profondeur en utilisant cette méthode SSRF.

Utilisation approfondie de JIRA SSRF

Les deux vulnérabilités SSRF que j'ai signalées au début de l'année sont qu'un certain filtre d'application Web peut être utilisé pour lancer une demande de connexion HTTP à une adresse IP spécifique Par exemple, il peut soumettre la méthode de requête CONNECT IP énumère les services d'application dans le système cible. En outre, il peut également lancer des informations de requête vérifiées vers l'adresse IP interne ou l'adresse IP externe du système cible en modifiant les informations d'en-tête de l'hôte, par exemple. comme armywebsite.mil@internal_IP. Lorsque j'ai testé cette méthode SSRF sur ces deux sites Web JIRA, j'ai découvert que dans l'environnement de requête qui provoquait auparavant des délais d'attente, des erreurs SSL et d'autres réponses, la méthode Blind SSRF pouvait également être utilisée pour énumérer la détection des services IP et réseau internes. Par conséquent, l’exploitation de la vulnérabilité SSRF à ce stade a finalement été classée comme risque moyen par le DoD.

Autres techniques pour exploiter les vulnérabilités de JIRA SSRF

Au cours de mes tests complets des vulnérabilités ci-dessus, j'ai constaté que dans certains cas, des erreurs de pile se produiraient inexplicablement et seraient divulguées Diverses informations sensibles , comme l'utilisation d'informations d'en-tête HTTP incomplètes http:// ou http://[::]. Les informations sensibles divulguées lors de cette erreur de pile incluent l'adresse IP de la base de données, la version de la base de données, les plug-ins d'application et l'architecture du système d'exploitation.

Lorsqu'une erreur de pile se produit, vous pouvez toujours continuer à obtenir des informations détaillées à partir du site Web cible. Par exemple, j'ai constaté que parfois la cible. Le site Web pointera vers d'autres instances d'Altassian. Par exemple, lors d'un test, j'ai découvert que les instances de confluence d'Altassian étaient déployées dans un sous-domaine du site cible. Les tests ont prouvé que ces instances sont également affectées par des vulnérabilités de fuite d'informations.

Résumé et tri

L'auteur a décrit les vulnérabilités JIRA découvertes lors de sa participation au projet de test public des vulnérabilités du ministère américain de la Défense et a brièvement présenté l'ensemble du processus de test d'exploitation des vulnérabilités. On va régler le problème :

1 Deux des sites Web du DoD déployés avec des instances JIRA ont une vulnérabilité de plug-in d'autorisation CVE-2017-9506. Un attaquant peut utiliser cette vulnérabilité pour obtenir des informations internes. informations sur les ressources du système du site Web cible. , et peut former une surface d'attaque SSRF

2 En combinaison avec la méthode d'exploitation CVE-2017-9506, j'ai obtenu l'ID d'instance JIRA, l'adresse IP privée, une série ; des réponses aux erreurs et d'autres informations provenant du site Web vulnérable du DoD ;

3 Le chercheur en chef intégré de PortSwigger, James Kettle, a partagé les deux sites Web du DoD mentionnés, en utilisant la méthode de requête CVE-2017-9506, il a été constaté que le site Web demandé Le site Web du DoD a renvoyé des informations USG (Government Warning) valides ;# 🎜🎜#

4 Dans la troisième étape, j'ai obtenu l'accès au réseau de routage du protocole de non-confidentialité du DoD (NIPRnet) via un service Web interne que j'ai découvert et combiné avec la méthode d'exploitation CVE-2017-9506 ;# 🎜🎜#

5 Combinée à la méthode d'exploitation CVE-2017-9506, l'attaque SSRF a été reproduite sur le site Web vulnérable du DoD, réalisant l'énumération interne des services IP et réseau et obtenant informations sensibles en cas d’erreurs de pile ultérieures.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!