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

This article is about how to use Jira's mail server connectivity test function to find its CSRF vulnerability, Xiaobian thinks it is quite practical, so share it with everyone to learn, I hope you can gain something after reading this article, don't say much, follow Xiaobian to see it.

Last October, Tenable researchers discovered a Cross-Site Request Forgery Vulnerability (CSRF)-CVE-2019-20099 in version 8.4.1 of Jira, which allows targeted Jira services to connect to arbitrary internal hosts. The following is the specific discovery process of CVE-2019-20099 vulnerability.

Anti-CSRF strategy deployed by Jira

Cross-site request forgery (CSRF) attacks can be used to impersonate someone else's identity without authorization. To prevent such attacks, Jira deploys CSRF tokens in an HttpOnly Cookie on the client side, so for an operation request to perform a state change, the Jira server checks whether the token matches the CSRF Cookie and the token in the CSRF parameter, so that it is difficult for an attacker to reuse cookies to launch a CSRF attack. In addition, the Referer header information can also verify the domain name and port consistency with the Jira server, preventing the same-origin policy from bypassing the operation.

The following is an example POST request I made to the Jira server, from which I found the vulnerability. The CSRF cookie and CSRF parameters are Atlassian.xsrf.token and atl_token respectively, and the Referer header information matching the IP and port of the Jira server is also included. After many tests, I found that the Jira server does not always verify the values of these confirmatory information.

vulnerabilities

Here we take the Jira architecture mail service in the intranet as an example for testing. When deploying POP3 mail service in Jira, the administrator needs to submit complete mail service configuration information, such as server name, host address, port number, user credentials, etc. There are two buttons at the bottom, one is to create a new mail service request, and the other is to test the connectivity of the current mail service. Note that since this is an intranet, the mail server host address here is the intranet address.

The mail connectivity test operation causes the Jira server to connect to a given POP3 mail server address, which involves a password exchange process. When I tested the test request, I found that neither the Referer header nor the CSRF parameter check was performed, so if a CSRF attack was to be performed on the request, the only thing required was to reuse the administrator Cookie currently logged into the Jira system.

To test this request, I set up an intranet POP3 mail server to receive authenticated connections from the Jira server, and an intranet Web server to host CSRF script-related Web pages. The purpose is to simulate that Jira system administrator clicks on a malicious link and is reused by session cookies, requesting Jira server to initiate connectivity tests against my mail server. The following is the CSRF script that triggers the Jira server to initiate a test mail service connectivity request:

The following is the Wireshark package diagram of the connectivity test performed on the scheduled mail service 172.16.68.229 after the CSRF script runs:

Thus, after victim 172.16.68.1 sends a POST request to Jira server 172.16.68.248, a connectivity test against the default mail server 172.16.68.229:110 is initiated, which is a password credential exchange verification process, and if the password credential verification does not pass, the connection is terminated. However, with this script, I was able to get the Jira server to connect to my own hosts and ports.

The POP3 mail server connection authentication request needs to set the username and password information in the parameters of the POST request. When the request achieves a successful handshake, these parameters will be sent to the specified host and port, which also provides a mechanism. Attackers can send messages or commands to the mail server host through this channel to achieve host monitoring.

Exploit vulnerabilities to perform intranet host probing discovery

The XMLHttpRequest object has a readyState attribute, which is used with the onreadystatechange event. The readyState attribute contains different state representation values between 0 and 4, as follows:

Every time the readyState property value changes, the onreadystatechange event is called to handle it. For this reason, I added the alert method to the state property change of XMLHttpRequest in the above script, so that I can be alerted every time the state changes. The goal is to observe the difference in state changes when requesting connections to different hosts and port numbers. I added the following state transition tracking code to the script above:

When the Jira server attempts to connect to an IP address that does not exist on the intranet, the state attribute of its XMLHttpRequest request will change from 1 to 4, thus calling the onreadystatechange event, and only when the connection is terminated, the original POST request will get the corresponding response. This process will take about 3 seconds (about 3000 milliseconds) to complete.

PoC

Finally I wrote a PoC script to let the Jira server perform intranet host probing with CSRF operation to test mail server connectivity. Of course, I set the mail server address to an intranet IP address and the request port is 110. After running the PoC script, it can be found that those host IPs that take more than 3000 milliseconds are non-existent intranet IP addresses, and only a small number of time-consuming IPs are IP addresses, as follows:

To verify these findings, I ran another scan with nmap and found the same result:

As you can see in the picture below where I captured the packet with Wireshark, the PoC script tells the Jira server to connect to the specified IP host port, and it can also fill in any message in the user field that was previously used for credential exchange to send to the connected specified IP host.

This is a CSRF vulnerability in Jira's server-side mail server functionality, which I exploited to perform scanning probes of intranet hosts and ports. The scenario can be used to construct malicious links for Jira administrators to confuse them to click and execute, so as to realize host port enumeration detection for their intranet.

The above is how to use Jira's mail server connectivity test function to discover its CSRF vulnerability. Xiaobian believes that some knowledge points may be seen or used in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.