Part of of my job at Surevine is to improve security; superficially that should go without saying, but what it actually turns into is re-engineering operations and architecture – this means adoption of OpenVPN, of Amazon VPC, and any other new technologies which allow us to maintain appropriate control over our assets whilst making the developers more productive, improve how we work, and pursue recognition for all that.
But having created new security hotness, one has to retrofit some of the technology to which we are wedded long term, and such technology includes Atlassian’s JIRA issue and project tracker; and it’s in the process of retrofitting that surprises occur, and security people don’t like surprises.
One such surprise was this: where formerly we’d installed JIRA on a DMZ network, in reinstalling it we chose to set it up directly connected to the Internet, trusting to our enabling a requirement for authentication to keep its data safe. It’s no big deal but like many companies we have data, projects, bugs, fixes, and we prefer not to hang all of our issues out in public for all to see when there is no actual functional requirement for the same.
JIRA seems to have other ideas, however; a search engine stumbled across our JIRA installation, and when I next reviewed the HTTP access logs it had spidered quite a lot of surprising content, including pages naming projects, engineers, products, etc; this was not a security disaster for us but it was a surprise given the search engine lacked any login credentials.
It turns out that JIRA’s QuickSearch URL is spiderable, eg:
https://jirahost/secure/QuickSearch.jspa
…and shares all sorts of meta-information about the JIRA installation and users without requiring the hassle of logging in; if you have a supposedly private JIRA installation which you administrate, spider it for yourself and see what you can get.[1]
The results aren’t horrifying – you get the kind of data that you might see on a public site like Atlassian’s own – so it’s not an information protection problem unless you habitually put really sensitive information into project names or usernames; however it provides more than enough leverage to enhance a social engineering attack where you phone up and pretend to know enough about a company that they share other information with you.
Atlassian have known about this issue since 2010, in a ticket logged by one Marc De Boeck:
JIRA filters exposed to the Internet
We received complaints from one of our (external) customers saying that his name was found on the Internet via googling for his name. The hit was found via a JIRA-link on our internal JIRA-system. When investigating, we found that it was caused by the fact that he had shared filters with restriction “Anyone”.
This is not a logical behaviour from JIRA: we don’t allow anonymous access to our JIRA, so we assume that nothing is exposed to the Internet. People may for example put information in the title of the filter that should not be exposed to others. As an administrator we don’t have the possibility to block this. We can’t even change the filters created by others. The best solution in my opinion, is to modify the “Global Permission”:
…and the followup comments on that page make for fascinating reading.
However, for the moment there is no fix and I believe that it’s not terribly highly prioritised by Atlassian.
Workarounds: one could fecklessly install a robots.txt but that only inhibits search engines rather than human beings from accessing the data. Instead we’ve reinstated HTTP Authentication on the server, which makes it less friendly. Alas.
However we share this experience and observations in the hope that matters will improve.
—
[1] Don’t spider a server that you don’t own. That would be rude.
Written by: Alec Muffett
