Im Folgenden wird beschrieben, wie der Autor am öffentlichen Testprojekt „Hack the Pentagon“ des US-Verteidigungsministeriums (DoD) teilnahm und die JIRA-Schwachstelle CVE-2017-9506 nutzte, um eine SSRF-Angriffsoberfläche zu erstellen und das nicht vertrauliche Internet der US-Armee zu implementieren Durch den Zugriff auf das Protocol Router Network (NIPRnet) und in Kombination mit anderen Schwachstellentechniken wurden eine Reihe vertraulicher Informationen über das DoD-Intranetsystem abgerufen. Aufgrund der Vertraulichkeit des Testprozesses und -inhalts geht dieser Artikel nur auf diesen Punkt ein, ohne zu viele technische Details und detaillierte Szenarien preiszugeben. Er dient nur zum Lernen und Teilen, und ich hoffe, dass die Leser Verständnis haben.
JIRA ist ein hervorragendes Softwaretool zur Problemverfolgung und -verwaltung, das von der Atlassian Company in Australien entwickelt wurde. Es kann verschiedene Arten von Problemen verfolgen und verwalten, darunter Fehler, Aufgaben, Anforderungen, Verbesserungen usw. Viele namhafte Unternehmen und Open-Source-Softwareorganisationen nutzen JIRA, da es die J2EE-Technologie nutzt und plattformübergreifend eingesetzt werden kann.
Während meiner Teilnahme am öffentlichen Schwachstellentestprojekt des US-Verteidigungsministeriums (DoD) stellte ich nach einer vorläufigen Analyse fest, dass zwei spezielle Websites das Projektverfolgungsmanagementtool JIRA implementierten Letztendlich dachte ich, dass es keine ausnutzbare Sicherheitslücke gebe, also habe ich nicht weiter gegraben.
Später habe ich einen Beitrag von Twitter gefunden, der JIRA-Schwachstellen ausnutzt, um SSRF-Angriffe zu implementieren:
Es bedeutet Folgendes:
Seien Sie vorsichtig, JIRA-Benutzer! Angreifer können die JIRA-Schwachstelle CVE-2017-9506 ausnutzen, um Ihre Intranetdaten zu stehlen. Dabei handelt es sich um eine offene Redirect-Schwachstelle, die jedoch in manchen Fällen ausgenutzt werden kann, um zur lokalen Linkadresse des internen JIRA-Systems umzuleiten, was zur Offenlegung bestimmter interner Ressourceninformationen wie AWS-Schlüssel führt.
Die niederländische Sicherheitsforschungsorganisation Dontpanic gab die ungefähre Ursache von CVE-2017-9506 an: Es gibt eine Komponente namens IconUriServlet im Atlassian OAuth-Plugin, das in JIRA enthalten ist, wie es üblich ist Empfangen Sie GET-Anfragen mit dem Parameterwert „consumerUri“ vom Client, aber die IconUriServlet-Komponente kann auch zum Erstellen einer anderen HTTP-GET-Anfrage verwendet werden, die vom Server ausgeführt wird. Diese Anfrage wird von JIRA als indirekter Proxy initiiert und vom Server ausgeführt und dann über JIRA an den Client zurückgegeben. Während dieses Prozesses können durch die Erstellung der Anfrage interne Informationen auf dem Server verloren gehen und im Antwortinhalt an den Client zurückgegeben werden.
Von Dontpanic bereitgestellte Methode zur Überprüfung der Sicherheitslücke:
https://%basepath%/plugins/servlet/oauth/users/icon-uri?consumerUri=https://google.com
Ersetzen Sie Basepath durch die JIRA-System-Website Wenn nach dem Zugriff auf die obige Seite die Seite google.com normal angezeigt wird, ist die Sicherheitslücke im JIRA-System vorhanden. Wenn beim Zugriff eine 404-Seite angezeigt wird, besteht die Sicherheitslücke nicht. Beachten Sie, dass Sie die Anfrage für die Website, die Sie testen möchten, am Ende des ConsumerUri hinzufügen! ! !
Nachdem ich die Beschreibung von CVE-2017-9506 sorgfältig gelesen hatte, hatte ich das Gefühl, einen Schatz gefunden zu haben, und wandte mich schnell den beiden zuvor entdeckten Websites des Verteidigungsministeriums zu, um dies unbedingt zu überprüfen Machbarkeit der Technologie zur Ausnutzung von Sicherheitslücken. Nachdem ich eine der Websites getestet hatte, stellte ich fest, dass ich erfolgreich zur Google-Seite springen konnte, was bedeutet, dass auf der Website eine Sicherheitslücke vorliegen muss!
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://google.com
Gemäß den AWS-Vorschriften kann jede Instanz angefordert werden Über Die von AWS festgelegte Metadatenadresse lautet 169.254.169.254, um das Metadatenbeispiel seiner eigenen Instanz abzurufen (zugehörige Methoden finden Sie in den offiziellen Anweisungen von AWS. Zu diesem Zweck habe ich den folgenden Link erstellt, um eine Anfrage zu initiieren:
).https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/meta-data/local-hostname/
I kann tatsächlich den internen Hostnamen sehen! Okay, lass mich versuchen, den AWS-Schlüssel zu bekommen:
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest /meta-data/ iam/security-credential
Aber es scheint nicht zu funktionieren. Nachdem ich die offizielle AWS-Dokumentation sorgfältig gelesen hatte, habe ich den folgenden Link erneut verwendet, um die Instanz-ID, die private IP-Adresse und andere Informationen zu erhalten:
https://website.mil/plugins/servlet/oauth/users/icon-uri?consumerUri = http://169.254.169.254/latest/dynamic/instance-identity/document
Es ist sehr gut, es kann erfolgreich durch Antwort erhalten werden!
Zu diesem Zeitpunkt dachte ich, dass es das Problem erklären könnte, also habe ich einfach einen Schwachstellenbericht geschrieben und ihn ohne weitere Tests eingereicht. Danach stufte das DoD-Projektklassifizierungspersonal die Schwachstelle jedoch als Schwachstelle mit mittlerem Risiko ein. Aber ich denke, dass dies definitiv eine ernsthafte Schwachstelle mit hohem Risiko ist. Nachdem ich mit dem Verteidigungsministerium gesprochen hatte, beantragte ich die Genehmigung für eingehende Tests, um die endgültigen Auswirkungen dieser Sicherheitslücke zu testen.
Zuerst begann ich mit der grundlegenden Porterkennung und fand das Ziel Das System hat die Ports 21, 22, 80, 443 und 8080 geöffnet. Mit diesen Portinformationen kann ich die Rückgabe verschiedener Fehlermeldungen testen und diese Informationen verwenden, um die Server- und Netzwerkbereitstellung im Zielsystem zu bestimmen Der 8080-Port des Zielsystems lautet wie folgt: Antwortinformationen:
Zweitens habe ich einen Anforderungstest für andere Protokolle durchgeführt, z. B. das Gopher-Dateiverzeichnis-Anzeigeprotokoll, das DICT-Wörterbuchserverprotokoll, das FTP-Protokoll, das LDAP-Lightweight-Verzeichniszugriffsprotokoll usw. Das System hat beispielsweise die folgende Antwort zurückgegeben, die LDAP nicht unterstützt:
Während ich diese Informationen aufzeichnete, dachte ich an die Forschungsergebnisse des PortSwigger-Chefforschers James Kettle, der „Cracking“ beim USA 2017 Black Hat teilte „Conference the Lens: Targeting HTTP's Hidden Attack-Surface“ konstruierte James Kettle bösartige HTTP-Anfragen und Header-Header-Informationen, um die verborgene Angriffsfläche des HTTP-Dienstes im Zielsystem zu skizzieren. Am Ende nutzte er diese Technologie, um die zu „verhüllen“. Die interne IP-Identität des US-Verteidigungsministeriums ist erfolgreich in die eingeschränkten internen Netzwerksysteme und zugehörigen Ressourcen des Verteidigungsministeriums eingedrungen und hat darauf zugegriffen. Ich erinnere mich, dass Kettle in seiner Mitteilung auch zwei interne Websites des Verteidigungsministeriums zeigte, die er für Einbruchstests verwendet hatte: (Website-Informationsquelle defensivecarry.com)
https://safe.amrdec.army.mil/safe /
https ://dots.dodiis.mil/
Kombinierte die beiden von James Kettle erwähnten internen DoD-Websites und nutzte die beiden DoD-JIRA-Websites, die ich gefunden habe, um Anfragen an sie zu stellen, um zu testen, ob es möglich ist, darauf zuzugreifen die beiden von James Kettle erwähnten internen Websites des Verteidigungsministeriums auf diese Weise? Nachdem ich schließlich eine der JIRA-Websites verwendet hatte, um eine Anfrage an die beiden von James Kettle erwähnten internen Websites des Verteidigungsministeriums zu initiieren, zeigte eine von ihnen an, dass die Anfrage abgelaufen war:
Die andere gab eine Warnmeldung der Regierung aus den USA zurück Regierung (USG), wie folgt:
Während dieses Testprozesses habe ich auch andere interne Webdienste des Verteidigungsministeriums entdeckt. Über diesen internen Webdienst konnte ich erfolgreich auf das Non-Confidentiality Protocol Routing Network (NIPRnet) zugreifen ). Dieses Netzwerksystem wird vom DoD intern kontrolliert, um weniger vertrauliche als vertrauliche Informationen zu verarbeiten. Aufgrund des Grundsatzes der Vertraulichkeit werde ich hier nicht im Detail auf die konkreten Methoden und Methoden eingehen.
Nachdem ich die zweite JIRA-Website verwendet hatte, um Anfragen an die beiden von James Kettle erwähnten internen Websites des Verteidigungsministeriums zu initiieren, waren die zurückgegebenen Antwortinformationen im Grunde nutzlos.
Nach dem Testen habe ich schließlich herausgefunden, dass das Öffnen von DoD-internen Systemports anhand der Reaktionszeit bewertet werden kann. Wenn beispielsweise Port 22 vom internen System angefordert wird, dauert die Antwort 1.000 Millisekunden, während die Antwort bei Anforderung von Port 21 fast 10.000 Millisekunden dauert. Basierend auf dieser Zeitdifferenz können einige Portbedingungen erraten werden. Darüber hinaus kann ich aufgrund des Fehlens einer detaillierten Antwort auf Fehlermeldungen kein Urteil über das spezifische Protokoll im System abgeben, möchte jedoch betonen, dass der Schwerpunkt dieses Artikels darauf liegt, dass ich über den internen Webserver auf die DoDs zugreifen kann Nicht vertrauliches Protokoll Routing Net (NIPRnet)! Ich habe auch das Collaborator-Plug-in von Burp verwendet, um Informationslecks im Datenaustausch zwischen dem Server und dem Anforderer zu erkennen, nachdem die Anfrage an den Webserver initiiert wurde.
Zum Beispiel kann die interne IP aus dem „X-Forwarded-For“ im Anforderungsheader abgerufen werden. Ich habe das Collaborator-Plugin verwendet, um alle interaktiven internen IPs abzufragen Netzwerkdienstinformationen am Ende, Der AWS-Metadatenabruf kann jedoch nicht auf dem Webserver implementiert werden.
Nachdem ich die beiden betreffenden Schwachstellen dem Verteidigungsministerium vorgelegt hatte, wurden beide Schwachstellen als kritisch eingestuft. Da fielen mir die beiden SSRF-Schwachstellen ein, die ich Anfang dieses Jahres dem Verteidigungsministerium gemeldet hatte und die ich mir ansehen wollte Kann die Sicherheitsanfälligkeit mit dieser SSRF-Methode umfassend ausgenutzt werden?
Die beiden SSRF-Schwachstellen, die ich Anfang des Jahres gemeldet habe, bestehen darin, dass ein bestimmter Webanwendungsfilter verwendet werden kann, um eine HTTP-Verbindungsanforderung für eine bestimmte IP-Adresse zu initiieren kann durch Senden einer CONNECT-IP-Anfrage innerhalb des Systems aufgelistet werden. Darüber hinaus können Sie auch verifizierte Anfrageinformationen an die interne IP oder externe IP des Zielsystems initiieren, indem Sie die Host-Header-Informationen ändern, z. B. „militärwebsite.mil@“. internal_IP. Als ich diese SSRF-Methode auf diesen beiden JIRA-Websites getestet habe, stellte ich fest, dass die Blind-SSRF-Methode in der Anforderungsumgebung, die zuvor zu Zeitüberschreitungen, SSL-Fehlern und anderen Antworten führte, auch zur Aufzählung interner IP- und Netzwerkdienste verwendet werden konnte. Daher wurde der SSRF-Schwachstellen-Exploit zu diesem Zeitpunkt vom Verteidigungsministerium letztendlich als mittleres Risiko eingestuft.
Während meiner umfassenden Tests der oben genannten Schwachstellen habe ich festgestellt, dass in einigen Fällen Stapelfehler unerklärlicherweise auftreten und verschiedene vertrauliche Informationen verloren gehen, z. B. die Verwendung unvollständiger HTTP-Header-Informationen http:// oder http://[::]. Zu den vertraulichen Informationen, die während dieses Stack-Fehlers durchgesickert sind, gehören Datenbank-IP, Datenbankversion, Anwendungs-Plug-Ins, Betriebssystemarchitektur und andere Systeme:
Ein Stack-Fehler ist aufgetreten. Sie können weiterhin abrufen Detaillierte Informationen von der Zielwebsite. Ich habe beispielsweise festgestellt, dass die Zielwebsite manchmal auf andere Altassian-Instanzen verweist. In einem Test habe ich beispielsweise festgestellt, dass eine Confluence-Instanz von Altassian in einem Subdomainnamen des Ziels bereitgestellt wurde Tests haben gezeigt, dass diese Instanzen auch von Schwachstellen bei der Offenlegung von Informationen betroffen sind.
Der Autor beschrieb die JIRA-Schwachstelle, die bei der Teilnahme am öffentlichen Schwachstellentestprojekt des US-Verteidigungsministeriums entdeckt wurde, und stellte kurz den gesamten Schwachstellen-Ausnutzungstestprozess vor:
1 Zwei davon Bereitstellungen von DoD-Websites mit JIRA-Instanzen weisen eine Autorisierungs-Plug-in-Schwachstelle CVE-2017-9506 auf. Angreifer können diese Schwachstelle nutzen, um interne Ressourceninformationen des Ziel-Website-Systems zu erhalten und eine SSRF-Angriffsoberfläche zu bilden -9506-Ausnutzungsmethode: Wir haben Informationen wie die JIRA-Instanz-ID, die private IP-Adresse und eine Reihe von Fehlerantworten von der anfälligen DoD-Website erhalten.
3 Integrierter PortSwigger-Chefforscher James Kettle teilte die beiden erwähnten DoD-Websites mit CVE-2017-9506-Anfragemethode und festgestellt, dass die angeforderte DoD-Website gültige USG-Informationen (Regierungswarnung) zurückgegeben hat.
4 Im dritten Schritt habe ich einen von mir entdeckten internen Webdienst in Kombination mit dem CVE-2017-9506-Exploit verwendet Methode, um eine Nicht-DoD-Erkennung zu erreichen.
5 In Kombination mit der CVE-2017-9506-Exploit-Methode wurde der SSRF-Angriff auf der anfälligen DoD-Website und der internen IP reproduziert und Netzwerkdienstaufzählung sowie nachfolgende Stapelfehler vertraulicher Informationen wurden erreicht.
Das obige ist der detaillierte Inhalt vonAnalyse eines Beispiels für die Nutzung der JIRA-Schwachstelle für den Zugriff auf das nicht klassifizierte Internet Protocol-Router-Netzwerk des US-Militärs. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
