Shulou(Shulou.com)05/31 Report--

An example analysis of using the JIRA loophole to access the US military unclassified Internet protocol router network. In view of this problem, this article introduces the corresponding analysis and answer in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

The following is about the author's participation in the Hack the Pentagon vulnerability testing project of the U.S. Department of Defense (DoD), using the JIRA vulnerability CVE-2017-9506 to construct the SSRF attack surface to realize the access to the US military unclassified Internet Protocol Router Network (NIPRnet), and combined with other vulnerability techniques to obtain a series of sensitive information about the DoD intranet system. Due to the secret nature of the testing process and content, this article has not disclosed too many technical details and detailed scenes, only for learning and sharing, and hope that readers will forgive me more.

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

From the beginning-discover DoD's JIRA application site

When I participated in the U.S. Department of Defense (DoD) loophole testing project, I found that two special websites deployed the project tracking management tool JIRA. After a brief analysis, I didn't think there was a loophole that could be exploited, so I didn't dig any further.

Later, I found a post in Twitter that exploits JIRA vulnerabilities to implement SSRF attacks:

It means something like this:

JIRA users beware, JIRA vulnerability CVE-2017-9506 can be exploited by attackers to steal your intranet data. This is an open redirection vulnerability, but in some cases it can be exploited to redirect to the local link address of the internal JIRA system, resulting in the disclosure of some internal resource information, such as AWS keys.

JIRA vulnerability CVE-2017-9506 description

Dutch security research institute Dontpanic gives a general reason for the vulnerability of CVE-2017-9506: there is a component called IconUriServlet in the authentication and authorization plug-in Atlassian OAuth plugin included in JIRA, which is used to receive GET requests in the client with the parameter value consumerUri, 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 by the server and then returned to the client through JIRA. In this process, by constructing the request, the internal information of the server can be leaked and returned to the client in the response content.

The vulnerability verification method given by Dontpanic:

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

Replace the basepath with a link to the JIRA system website, and after visiting the above page, if the google.com page appears normally, it proves that the vulnerability exists in the JIRA system; if the page appears, the vulnerability does not exist. Please note that it is the website that requests testing after the consumerUri!

Test the vulnerabilities of DoD's JIRA application website

After carefully reading the instructions of CVE-2017-9506, I quickly turned to the two Defense Department websites I had previously discovered, eager to verify the feasibility of this vulnerability exploitation technology. I first tested one of the sites and found that it could jump out of the google page normally, and there must be a loophole!

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 relevant methods, please refer to the official description of AWS). To this end, I have constructed the following link to initiate the request:

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

I can't believe you can see the internal hostname! All right, let me see if I can 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 AWS official documentation, I use the following link to try again to get information including instance ID, private IP address and so on:

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

Very good, unexpectedly can respond successfully to get!

At this point, I thought it would be illustrative, so I simply wrote a vulnerability report and submitted it without further testing, but then the DoD project classifier classified the vulnerability as a medium-to-critical vulnerability, but I thought it was definitely a serious and high-risk vulnerability. After some communication, I applied to DoD for in-depth testing authorization to continue to test what the ultimate impact of this vulnerability would be.

In-depth testing-access to unclassified Internet Protocol Router Network (NIPRnet) and access to other sensitive information

Early reconnaissance and discovery

First of all, starting with the basic port detection, I found that the target system opened ports 21, 22, 80, 443 and 8080. With these port information, I can test the return of various error messages. Use this information to determine the deployment of the server and network in the target system, as follows: after initiating a request for port 8080 of the target system:

Secondly, I have done a request test on other protocols such as gopher file directory viewing protocol, DICT dictionary server protocol, FTP protocol, LDAP lightweight directory access protocol and so on. If the system returns the following response that does not support LDAP:

Comprehensive utilization discovery

While recording this information, I also thought of PortSwigger lead researcher James Kettle's research sharing "Cracking the Lens: Targeting HTTP's Hidden Attack-Surface" at the USA 2017 Black Hat Conference. James Kettle outlines the hidden attack surface of the HTTP service in the target system by constructing malicious HTTP requests and Header header information. finally, he uses this technology to 'disguise' as the internal IP identity of the U.S. Department of Defense. Successful intrusion access to DoD-restricted internal network systems and related resources. I remember that in Kettle's sharing, he also showed two DoD internal websites that he used for intrusion testing: (website information source defensivecarry.com)

Https://safe.amrdec.army.mil/safe/

Https://dots.dodiis.mil/

Combine these two DoD internal sites mentioned by James Kettle and use the two JIRA sites of DoD that I found to make a request to them in order to test whether it is possible to access the two DoD internal sites mentioned by James Kettle in this way. Finally, after I used one of the JIRA sites to initiate a request to the two DoD internal sites mentioned by James Kettle, one of them showed that the request timed out:

Another government warning message returned from US Goverment (USG) is as follows:

In the course of this test, I also found other DoD internal web services. Through this internal web service, I was able to successfully access the US military's non-secure Protocol routing Network (NIPRnet), which is used internally by DoD to handle less sensitive information than classified information. Because of the principle of confidentiality, I will not disclose the specific methods and channels in detail here.

Obtain internal sensitive information through response content judgment

After I used the second JIRA site to make a request to the two DoD internal sites mentioned by James Kettle, the response information returned was almost useless.

But in the end, after testing, I also found that the port opening of the DoD internal system can be judged by the response time. For example, when requesting port 22 from an internal system, the response time is 1000 milliseconds, while the request for port 21 is nearly 10000 milliseconds. Some port conditions can be guessed from this time difference. In addition, due to the lack of detailed error message response, I am unable to judge the specific protocols in the system, but I would like to emphasize that the focus of this article is: through the internal web server, I can access DoD's non-secure protocol routing network (NIPRnet)! I also used Burp's Collaborator plug-in to detect information disclosure during data exchange between the server and the requester after the web server request was initiated.

For example, the internal IP can be obtained from the 'XMurForwarded IP' in the request header. I used the Collaborator plug-in of Burp to query all the interactive internal IP. Although I can finally query the internal IP and related network service information, I can not implement AWS metadata retrieval on the AWS server.

Finally, after I submitted the two vulnerabilities involved to DoD, both of them were rated as Critical, so I thought of the two SSRF vulnerabilities I reported to DoD earlier this year to see if they could be exploited in depth in this way of SSRF.

Further utilization of JIRA SSRF

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

Other techniques of JIRA SSRF vulnerability exploitation

During my comprehensive testing of the above vulnerabilities, I found that in some cases, stack errors inexplicably occur and various sensitive information is disclosed, such as http:// or http://[::] with incomplete HTTP header information, such as database IP, database version, application plug-ins, operating system architecture, and other systems:

When stack errors occur, you can still continue to obtain and utilize in-depth information on the target website. For example, I found that sometimes the target website will point to other Altassian instances. For example, in a test, I found that there are confluence instances of Altassian deployed in a subdomain name of the target site. After testing, these instances are also affected by information disclosure vulnerabilities.

Summarize and sort out

The author describes the JIRA vulnerabilities found while participating in the U.S. Department of Defense vulnerability testing program, and briefly introduces the whole testing process of vulnerability exploitation. let's sort it out:

1 two of the DoD websites deployed with JIRA instances have authorization plug-in vulnerability CVE-2017-9506, which can be used by attackers to obtain internal resource information of the target website system and form a SSRF attack surface.

2 combined with the utilization method of CVE-2017-9506, I obtained the information of JIRA instance ID, private IP address, a series of error responses and so on from the vulnerable DoD website.

3 synthesize the two DoD websites mentioned by James Kettle, the chief researcher of PortSwigger, and use the CVE-2017-9506 request method to find that the requested DoD website has returned valid USG (government warning) information.

4 in the process of step 3, I realized the access to the DoD non-secure protocol routing network (NIPRnet) through one of the internal web services discovered, combined with the utilization method of CVE-2017-9506.

(5) combined with the utilization method of CVE-2017-9506, the SSRF attack is reproduced on the vulnerable DoD website, and the internal IP and network service enumeration are realized, as well as the acquisition of sensitive information in the case of subsequent stack errors.

This is the answer to the sample analysis question about using the JIRA loophole to access the US military unclassified Internet Protocol Router network. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.