Analysis of an example of using JIRA vulnerability to access the US military's unclassified Internet Protocol router network

The following describes the author's participation in the U.S. Department of Defense (DoD) Hack the Pentagon vulnerability public testing project, using the JIRA vulnerability CVE-2017-9506 to construct an SSRF attack surface and achieving unclassified Internet protocol routers for the U.S. military. Network (NIPRnet) access, and combined with other vulnerability techniques, obtained a series of sensitive information of the DoD intranet system. Due to the confidential nature of the test process and content, this article only touches on this point without disclosing too many technical details and detailed scenarios. It is only for learning and sharing, and I hope readers will bear with me.

JIRA is an excellent issue tracking and management software tool developed by Atlassian Company in Australia. It can track and manage various types of issues, including defects, tasks, requirements, improvements, etc. Many well-known companies and open source software organizations are using JIRA because it uses J2EE technology and can be deployed across platforms.

Let’s start from the beginning - Discovering DoD’s JIRA application website

When participating in the vulnerability public testing project of the US Department of Defense (DoD), I found that there were two special websites that deployed project tracking After a preliminary analysis of the management tool JIRA, I believed that there were no exploitable vulnerabilities, so I did not continue to dig deeper.

Later, I found a post on Twitter that exploited JIRA vulnerabilities to implement SSRF attacks:

##It It means this:

Be careful, JIRA users! Attackers can exploit JIRA vulnerability CVE-2017-9506 to steal your intranet data. This is an open redirect vulnerability, but in some cases, it can be exploited to redirect to the local link address of the internal JIRA system, leading to the disclosure of certain internal resource information such as AWS keys.

JIRA vulnerability CVE-2017-9506 description

The Dutch security research organization Dontpanic gave the approximate cause of the CVE-2017-9506 vulnerability: JIRA contains There is a component called IconUriServlet in the authentication and authorization plug-in Atlassian OAuth plugin, which is used to receive GET requests with parameter value consumerUri from the client, but the IconUriServlet component can also be used to create another HTTP GET request executed by the server. This kind of request initiated by JIRA as an indirect proxy is responded to by the server and then returned to the client via JIRA. During this process, by constructing the request, the internal information of the server can be leaked and returned to the client in the response content.

Vulnerability verification method given by Dontpanic:

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

Replace the basepath with the JIRA system website link. After accessing the above page, if the google.com page appears normally, it proves that the vulnerability exists in the JIRA system; if a 404 page appears when accessing, the vulnerability is not exist. Note that you add the request for the website you want to test at the end of the consumerUri! ! !

Testing DoD’s JIRA application website vulnerability

After carefully reading the description of CVE-2017-9506, I felt like I had found a treasure and quickly turned to the two Department of Defense websites I had discovered before. , eager to verify the feasibility of this vulnerability exploitation technology. After testing one of the websites, I found that I could successfully jump to the Google page, which means there must be a vulnerability in the website!

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

According to AWS regulations, any instance can retrieve its own instance metadata example by requesting the metadata address 169.254.169.254 set by AWS (for related methods, please refer to AWS official instructions). To this end, I constructed the following link to initiate a request:

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

Can actually see the internal host name! Okay, let me try to get the AWS key:

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

But it doesn’t seem to work. After carefully reading the official AWS documentation, I reused the following link to obtain the instance ID, private IP address and other information:

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

Very good, I can get the response successfully!

At this point, I thought it should be able to explain the problem, so I simply wrote a vulnerability report and submitted it without further testing. But later, the DoD project classification personnel classified the vulnerability as a medium-risk vulnerability, but I Think this is definitely a serious high-risk vulnerability. After speaking with the Department of Defense, I requested authorization for in-depth testing to test the ultimate impact of this vulnerability.

In-depth testing - achieving access to the Non-confidential Internet Protocol Router Network (NIPRnet) and obtaining other sensitive information

Preliminary reconnaissance discovery

First, I started with basic port detection and found that the target system had opened ports 21, 22, 80, 443, and 8080. With these port information, I could test the return of various error messages and judge the target through this information. The server and network deployment in the system, as shown below, is the response information after a request is made to port 8080 of the target system:

Secondly, I checked the protocol and DICT dictionary in the gopher file directory Server protocol, FTP protocol, LDAP lightweight directory access protocol and other protocols were tested for requests. For example, the system returned the following response that does not support LDAP:

Comprehensive utilization discovery

When recording this information, I thought of PortSwigger again Chief researcher James Kettle shared his research "Cracking the Lens: Targeting HTTP's Hidden Attack-Surface" at the USA 2017 Black Hat Conference. James Kettle constructed malicious HTTP requests and Header header information to outline the hiding of HTTP services in the target system. Attack surface, in the end, he used this technology to 'disguise' as an internal IP identity of the US Department of Defense, and successfully invaded and accessed DoD's restricted internal network systems and related resources. I remember that in Kettle’s sharing, he also showed two DoD internal websites that he had used for intrusion testing: (Website information source defensivecarry.com)

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

https://dots.dodiis.mil/

Combine these two DoD internal websites mentioned by James Kettle, use I found two DoD JIRA websites and initiated requests to them. The purpose was to test whether access to the two DoD internal websites mentioned by James Kettle could be achieved in this way. Finally, after I used one of the JIRA sites to make a request to the two DoD internal sites mentioned by James Kettle, one of them showed a request timeout:

The other returned US Government (USG) government warning information, as follows:

#During this test process, I also discovered other DoD internal web services. Through this internal web service, I actually It was able to successfully access the US military's Non-confidential Protocol Routing Network (NIPRnet), which is used internally by the DoD to handle sensitive information lower than the classified level. Due to the principle of confidentiality, I will not disclose the specific methods and methods in detail here.

Acquire internal sensitive information by judging the response content

After I used the second JIRA website to initiate requests to the two DoD internal websites mentioned by James Kettle, the response information returned was basically Nothing much to offer.

After testing, I finally found that the opening of DoD internal system ports can be evaluated based on response time. For example, when requesting port 22 from the internal system, the response takes 1,000 milliseconds, while when requesting port 21, the response takes nearly 10,000 milliseconds. From this time difference, some port conditions can be guessed. In addition, due to the lack of detailed error message response, I cannot make a judgment on the specific protocol in the system, but I want to emphasize that the focus of this article is: through the internal web server, I can access the DoD's non-confidential protocol routing Net (NIPRnet)! I also used Burp's Collaborator plug-in to detect information leakage during the data exchange between the server and the requester after the request to the web server was initiated.

For example, the internal IP can be obtained from the 'X-Forwarded-For' in the request header. I used Burp's Collaborator plug-in to query all interactive internal IPs, although I was able to query the internal IP and related Network service information, but AWS metadata retrieval cannot be achieved on the web server.

In the end, after I submitted the two vulnerabilities involved to DoD, both vulnerabilities were rated as critical. From this, I thought of the two SSRF vulnerabilities I reported to DoD at the beginning of this year. I want to see if the above vulnerability can be exploited in depth using this SSRF method.

In-depth utilization of JIRA SSRF

The two SSRF vulnerabilities I reported at the beginning of the year are that a certain web application filter can be used to initiate an HTTP connection request to a specific IP address, for example, by submitting a CONNECT IP request. , to enumerate the application services in the target system; in addition, it can also initiate verified request information to the internal IP or external IP of the target system by changing the host header information, such as militarywebsite.mil@internal_IP. When I tested this SSRF method on these two JIRA websites, I found that in the request environment that previously prompted timeouts, SSL errors, and other responses, the Blind SSRF method could also be used to enumerate internal IP and network services. detection. Therefore, the SSRF vulnerability exploit at this point was eventually rated as medium risk by DoD.

Other techniques for exploiting JIRA SSRF vulnerabilities

During my comprehensive testing of the above vulnerabilities, I found that in some cases, stack errors would inexplicably occur and leak various sensitive information. , for example, using incomplete HTTP header information http:// or http://[::]. Sensitive information leaked during this stack error includes database IP, database version, application plug-ins, operating system architecture and other systems:

When a stack error occurs, you can still continue to obtain in-depth information from the target website. For example, I found that sometimes the target website will point to other Altassian instances, such as a certain time During the test, I found that Altassian's confluence instances were deployed in a subdomain name of the target site. Testing proved that these instances were also affected by the information leakage vulnerability.

Summary and review

The author describes the JIRA vulnerabilities discovered while participating in the U.S. Department of Defense vulnerability public testing project, and briefly introduces the entire vulnerability exploitation testing process. Let’s sort it out together:

1 Two of the DoD websites with JIRA instances deployed have the authorization plug-in vulnerability CVE-2017-9506. An attacker can use this vulnerability to obtain internal resource information of the target website system and form an SSRF attack surface. ;

2 Combined with the CVE-2017-9506 exploitation method, I obtained the JIRA instance ID, private IP address, a series of error responses and other information from the vulnerable DoD website;

3 Comprehensive PortSwigger chief researcher James Kettle shared the two DoD websites mentioned. Using the CVE-2017-9506 request method, it was found that the requested DoD website returned valid USG (Government Warning) information;

4 In step 3 of the process , I achieved access to the DoD Non-Confidentiality Protocol Routing Network (NIPRnet) through an internal web service I discovered, combined with the CVE-2017-9506 exploit method;

5 Combined with the CVE-2017-9506 exploit This method reproduced the SSRF attack on the vulnerable DoD website, implemented internal IP and network service enumeration, and obtained sensitive information in the event of subsequent stack errors.

The above is the detailed content of Analysis of an example of using JIRA vulnerability to access the US military's unclassified Internet Protocol router network. For more information, please follow other related articles on the PHP Chinese website!