There is a proxy in your Atlassian Product!

You might not know it but the Atlassian OAuth plugin is part of most Atlassian products such as Jira and Confluence. Until recently it had a vulnerability that allowed the unauthenticated execution of HTTP GET requests from the server. You can do all kinds of interesting things with it, like accessing resources on the internal network or spoofing pages with a valid TLS connection.

In this blog post I will describe the vulnerability, explain how it works, how to test for it and why it is a bad thing TM.

The vulnerability

As part of my research for Atlasscan I sometimes browse the Atlassian JIRA in search for security related issues and see if I can test for them. Last weekend I stumbled upon OAuth-344 , which is the vulnerability we're talking about. It sounded interesting so I decided to have a look.

It is nice that the Atlassian OAuth plugin is open source, so you can examine the commits that fixed the issue. There was an IconUriServlet that accepted a GET request and took the value from the consumerUri parameter and used it to create another HTTP GET request, this time executed from the server. The response from the request was then streamed back across the original request. That is proxy functionality alright!

Knowing that the functionality exists is one thing, but you also need to know which URL to call. A part can be derived from the source code, the other part from the documentation .

How to Test for the vulnerability

So in order to test if the vulnerability is present you need to form an URL like so:

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

                

If you execute this request in a browser (and replace %basepath% with your Atlassian product base path :-) and are greeted with a Google page you now know which URL to block :-) If however you get a 404 all is well because the servlet no longer exists in newer versions of the plugin.

Why is this a bad thing TM?

Well first of all, because the server executes an HTTP request with an URL of your choice and returns the results, you can access any resource the server has access to.

Often the server resides on an internal network and if you know or guess the name of any http resources on that network you can access them. For example a vulnerable Jira server is accessible from the internet, but an internal Confluence is only available on the internal network. You could access it with an URL like this:

                
https://jira.company.com/plugins/servlet/oauth/users/icon-uri?consumerUri=https://confluence.company.com/

                

Secondly you can use this feature to phish for credentials by accessing a spoofed login page through this URL. The TLS lock is green, domain name checks out, but you may be looking at code from a whole different domain. Also you can use this to serve untrustworthy content using a trusted domain (think ads and worse).

Conclusion

I think this vulnerability has not received the attention it deserves. The administrators I have talked to so far were unaware of it. This kind of makes sense because it never featured on the Atlassian security page and CVE-2017-9506 listed only the OAuth component, not the products.

So, if you find your Atlassian product vulnerable please inform your administrator and ask him to block the URL or upgrade to a later version of your product.

According to the Atlassian Jira the following versions are vulnerable:

• Bamboo < 6.0.0
• Confluence < 6.1.3
• Jira < 7.3.5
• Bitbucket < 4.14.4
• Crowd < 2.11.2
• Crucible & Fisheye < 4.3.2