Eray Mitrani works for Nokia Deepfield where they are providing network analytics and DDoS-protections. He is also a security researcher in the Detectify Crowdsource community. In the following guest blog, he goes through the process of finding and submitting his first module to Detectify Crowdsource, which is an authorization bypass.
Detectify Crowdsource is our platform where external security researchers can submit web vulnerability findings to us. If we can validate the finding, we build security checks into the Detectify automated scanner and make it available to all our customers. For each customer profile finding generated, we pay the security researcher a financial kickback.
Barely a year has passed since I started teaching myself how to hack and mostly by iterating things other people have already done. Sometimes it is possible to get something to work without necessarily understanding all the reasons as to why it works. This write up is going to be about that sort of discovery which led to my first module on Detectify.
How it all began
It all started with Orange Tsai’s awesome research where he talks about a path normalization issue he found on Uber’s internal Jira instance in order to bypass their OneLogin.
Path normalization is part of how a URL is parsed server side. https://example.com/a/../b might for example actually be treated as https://example.com/b in some places, while kept in full in others. This difference often lead to authorization issues.
I was very interested in looking into Jira because it is a ubiquitous software, which means that one original find can lead to numerous bounties across many bug bounty programs. One example of this is CVE-2017-9506 where the SSRF affected many vendors and was easy to discover with a simple GET-request. I did some research using Shodan to see if people were still running old versions of the software and I found around 5% of the domains were still unpatched. That’s when I decided to see if I could build on the past research in order to contribute some modules to Detectify Crowdsource.
Keeping track with a recon folder
With that motivation in mind, I went to my recon folder where I keep track of all my bug bounty targets. Having this allows me to quickly look for newly published vulnerabilities in old targets I’ve already tested. As different hackers will have access to different private programs, it is always a good idea to quickly look for easily automated tasks there. I personally like to keep a .txt record of all active hosts on a target and directory structure in a different folder. This allows me to both track changes to past targets and look for new vulnerabilities I have picked up. For example, if there is a new Cisco vulnerability I can look for all subdomains that include the word “vpn” or in this case I did a `grep -r –include=*.txt “jira”` which gave me all subdomains that have the string jira in it.
I started looking at different versions of Jira deployed across bug bounty programs. Most up-to-date Jira instances nowadays will redirect you to Atlassian ID to login however I found one that would redirect you to login.jsp (their old login) regardless of which path you tried to visit under “/secure”.
Applying Orange Tsai’s technique
I knew Orange’s trick potentially allowed us to bypass redirects to login page like the case with OneLogin and Uber described in the article linked above. That’s why I tried it to access sensitive endpoints on Jira like /browse, ManageFilters.jspa and Dashboard.jspa. I couldn’t find any dashboards like his example but I was able to list all filters that were shared with “everyone” which includes unauthenticated users. This revealed employee emails, tickets that were being worked on and the company priorities.
Delving into the main issue
The main issue here is that the admin relied on the login redirect to hide filters and dashboards shared with everyone or wasn’t aware that sharing with everyone includes unauthenticated users as well. Also by default all email addresses are public information so by being able see filters and dashboards one can also get valid company email addresses. You can see the default setting looks like:
Recommended actions
If your Jira instance is not sitting behind a VPN, the best thing you can do is to avoid setting any permissions to “everyone” while setting up a new dashboard or shared filter as that would permit unauthenticated users as well. I would also suggest adjusting the “User email visibility” setting from “Public” to show to logged in users only.
Why it works is still a mystery
At this point I thought this would make an easy module to implement for Detectify as you only need two GET-requests to check for it. At first you should try to list the filters via the regular path and if that doesn’t work you can try the same thing with Orange’s `/status/..;/` trick. I was pretty confident that’s why this worked. However, after submitting the module to Detectify and discussing it with them, I realized /..;/ is actually not needed. I am still a bit unsure why /status/ is let through, but I would assume it has something to do with it the status-endpoint being accessible for unauthenticated users on most Jira-instances. In the end I think this serves as a great example on finding interesting things before fully understanding them.
Eray Mitrani
Twitter: @ErayMitrani
With Detectify you can check your website against this finding, and 1000+ other vulnerabilities submitted by the Detectify Crowdsource community, as well as our in-house research. Sign up today for a 14-day free trial, no credit card required.