
Misconfigured Jira instances exposed data of hundreds of Fortune 500 companies - logicbomb_1
https://medium.com/@logicbomb_1/one-misconfig-jira-to-leak-them-all-including-nasa-and-hundreds-of-fortune-500-companies-a70957ef03c7
======
mik3y
This issue arises because, if the site allows any public sharing, the "create
filter" UI gives team members the option to share a new filter with
"Everyone", which sounds like an org-local scope but is in fact a public/non-
logged-in scope. The org-level scope is called, "Open", and is not part of
this UI. Sigh.

To prevent this issue as a site admin on Jira cloud, go to:

    
    
        Jira Settings -> System -> General Configuration
    

and disable "Allow users to share dashboards and filters with the public."
This doesn't affect existing filters, which you have to manually fix.

In true Jira fashion, if you try to reassign a filter _after_ flipping this
setting, it will deny the operation and ask you to edit the ACL, which there
is no convenient admin UI to do.

Jira is a disaster of UX.

~~~
wpietri
I admit I have mostly avoided using it, so a question:

> Jira is a disaster of UX.

Jira is trying to be all things to all people. It seems to me to be based on a
sort of shared illusion, namely that when people talk about work getting done
they are talking about the same thing, when in fact they're often talking
about wildly different processes, different philosophies. I think that sort of
illusion guarantees a UX mess, because it's trying to cover up/accommodate too
many different things. Is Jira a UX disaster because of just that? Or is it
bad on top of that?

And I worry that makes no sense, so by analogy let's imagine that somebody
sold a "transport solution". This sounds great, because transportation is a
universal need. But in reality transport solutions include shoes, scooters,
bikes, motorcycles, cars, buses, trains, and airplanes. So this "transport
solution" comes with a great mess of wheels, gears, shafts, etc, etc, plus
reams of Ikea-style instructions for putting pieces together. It's universal,
but also guaranteed to be a pain in the ass for any actual specific use.

~~~
mik3y
Don’t mean to create a pile-on, but since you asked, yeah I should explain my
barb:

    
    
        Is Jira a UX disaster because of just that?
        Or is it bad on top of that?
    

My opinion - it’s both.

The product has a ton of permutations, as you said, which makes stuff like
this happen: Customers who never in the world imagined public issue tracking,
suddenly bit by a feature they didn’t even know existed. Conversely I’m sure
there are shops, who love this feature, for whom the distinction between
“Everyone” and “Open” was always obvious. I don’t envy the team building /
supporting the product across all that; I don’t know how I’d do it.

But there are also endemic, continuously-poor design choices large and small.
Unannounced and hard to disable major changes to the UI are the standard, and
large. I’ll give you one example of the small: Recently, unannounced, the
issue comment UI started auto-correcting the _capitalization_ of Atlassian
product names in the comment box. Type “JIRA”, get “Jira”. In _my_ words in
_my_ issue tracker. (Yes, it was the js app, not the browser). It just always
seems so user hostile.

Net net, to me it’s an aging hydra of a product with ongoing missteps. I’d
take good design and limited features over what you get here, at least with
out heavy investment and expertise.

~~~
ownagefool
I tend to agree Jira is a bit of a mess, but the responsbility needs to be
shared with the users.

\- Why buy a complicated mess? \- Why let a random Scrum Master / Product
Owner manage it? \- Why don't we think we need to protect an IT system we buy
like an IT system?

Many of the reasons engineers hate Jira are specifically related it being a
complicated mess that is hard to use and admin. So if management would listen
to engineer about IT systems, maybe this wouldn't happen?

Another possibility is we actually did a risk assessment and what we put in
Jira isn't of sufficent risk for us to care, so actually IT doesn't need to be
involved because we're not super worried about it leaking.

There are likely worlds of both involved.

My own pet hate is just that it's too slow and often configured in a
convoluted way that makes me spend too much time in it.

------
iamleppert
JIRA is for people who like to do more planning of work than actual real work.
See also: meeting moths.

It’s commonly used by technical managers who have no skills to contribute but
need to justify themselves as important so they will spend countless hours
setting up complex workflows, tweaking forms and starring at pointless
“burndown” charts describing work they have absolutely no clue about.

JIRA also generates an enormous amount of automated email which is further
exploited by these folks to advertise to others in the company that they are
doing work.

When you interview some place, pay attention if they have a culture ruled by
JIRA. If they do, and you like to get real work done, do not work there. It
may be possible some use JIRA as a tool but the risk is far too high to take.

~~~
Macuyiko
I wish I could upvote you twice. Exactly describes my experience and it is
soul sucking. It gets so bad that the work-planners actually succeed in
creating faux importance and are valued more (and value themselves more) than
the actual workers.

~~~
JasonBlack555
I upvoted on your behalf !

------
binarymax
<insert joke about how nobody wants to suffer through anyone else’s Jira
anyway>

Seriously though, this isn’t good. Not because of this hack specifically but
because of the greater problem of which this is a symptom. Software these days
is really hard to configure and get right, so lots of big companies just
offshore things like this as they don’t want to deal with it with FTEs. Then
the budget for maintenance gets deprioritized and cut as a whole for all these
little systems that keep projects humming along. Probably just as many
misconfigured wikis, git servers, etc through a rats nest of different VPNs
and providers. It gets really expensive really fast to host these things right
and in a way where accessibility for valid folks is still reasonable.

------
blunte
I think we are at the point of risk where the volume of discoverable
information is so great that the parties at "risk" are needles in the
haystack. There may be some analytical value in combing the available data,
but if a specific target were interesting, they are probably already
compromised.

In a way, it is to say that few organizations have especially interesting
information. The few that do can be compromised with social approaches. So
exposures such as these are becoming less and less embarrassing. Every
organization is dysfunctional to some degree, and every org has some
communications that (especially taken out of context) might raise eyebrows;
but that is life, and that is what happens when you gather numbers of people
in one place.

Point is, stories like these are useful for adding to a corporate checklist of
exposure safety, but they aren't worth much else (unless of course the org
holds secrets that could hugely disrupt the world).

~~~
dredmorbius
This very much depends on specific threats, opponents, risks, and the
interactions of these: your (perceived, actual) threat model.

Some years back as a member of a third-party services provider I had to sit
through the e-learning session of a very large financial services provider.
The course (tediously boring, natch) established three tiers of information
importance, with the highest being _not_ consumer information, but the
organisation's own marketing and product plans.

Which is precisely what you're going to find in a Jira or equivalent project
planning trove.

The risks of a lawful competitor running across this are ... reasonably low in
many, though not all cases (see the Waymo smart car case for risks involved),
though there are certainly cases of corporate espionage.

And petty criminals are somewhat unlikely to see much use from this.

But, to draw from recent HN posts: the ability to specificaly target
developers to drop malicious payloads, for foreign governments to exfiltrate
technologies or identify individuals to target for enhanced surveillance, to
blackmail, to thwart or confuse plans, etc., all exist.

Information _of itself_ is not power, but information with both the impunity
to acquire it and the ability to act on it most certainly is.

And that's where Jira-class risks are significant.

------
hbcondo714
The author of this Medium post also posted about this back in January[1] so
the issue hasn't been resolved since then?

[1] [https://medium.com/@logicbomb_1/bugbounty-nasa-internal-
user...](https://medium.com/@logicbomb_1/bugbounty-nasa-internal-user-and-
project-details-are-out-2f2e3580421b)

~~~
d2mw
Don't worry about it, I'm sure it's in the backlog

~~~
bearer_token
You joke, but looks like:

[https://jira.atlassian.com/browse/JRACLOUD-18076](https://jira.atlassian.com/browse/JRACLOUD-18076)

[https://jira.atlassian.com/browse/JRACLOUD-36896](https://jira.atlassian.com/browse/JRACLOUD-36896)

~~~
kps
> Created: 24/Jul/2009 5:42 AM

------
kirby9066
This issue was originally published back in 2016.

[https://medium.flatstack.com/misconfig-in-jira-for-
accessing...](https://medium.flatstack.com/misconfig-in-jira-for-accessing-
internal-information-of-any-company-2f54827a1cc5)

------
sadness2
Worse is that these are cached by Google so any admin seeking to clean up this
mess sure has their work cut out for them.

~~~
Moter8
You can ask for cache deletion at
[https://www.google.com/webmasters/tools/removals?pli=1](https://www.google.com/webmasters/tools/removals?pli=1),
I've just done it yesterday and today the caches are marked as
deleted/refreshed.

------
lucb1e
TL;DR:

> by default the visibility is set to “All users” and “Everyone” respectively,
> which instead of sharing with everyone of the organizations (which people
> think and interpret), it share them publically [sic]

To test if you are vulnerable, check whether you can publicly load one of
these URIs on your domain:

    
    
        https://jira.example.com/secure/popups/UserPickerBrowser.jspa
        https://jira.example.com/secure/ManageFilters.jspa?filterView=popular
        https://jira.example.com/secure/ConfigurePortalPages!default.jspa?view=popular
    

To find these sites, Google one of these queries:

    
    
        inurl:/UserPickerBrowser.jspa -intitle:Login -intitle:Log
        inurl:/ManageFilters.jspa?filterView=popular AND ( intext:All users OR intext:Shared with the public OR intext:Public )

~~~
Karunamon
It gets worse. You can modify those permissions, but every single Jira page
that involves a permission check (and they get pretty granular) involves a
nontrivial query to the user DB (which might, itself, involve a query to a
backend like LDAP) to determine if you can do a thing or, critically, see the
UI element to do the thing.

Best guidance when I was running Jiras were to restrict access at the network
if at all possible, and don't use permissions any more than strictly necessary
unless you like 5-10 seconds per page load. In other words, if only your
developers need to see your Jira, don't grant only your developer group
permissions, set it to "everyone" and lock everyone else out at the firewall.

~~~
vultour
We run massive JIRA instances with very granular permissions using multiple
custom authorization backends (LDAP/Kerberos/in-house stuff), and it doesn't
seem to add much of a delay.

~~~
Karunamon
Hm. Perhaps they took some time and worked on the performance then. It was
ungodly slow a couple years back, and relaxing permissions led to a
_significant_ performance boost.

~~~
bearer_token
They've been touting performance increases for a while now

[https://confluence.atlassian.com/jirasoftware/jira-
software-...](https://confluence.atlassian.com/jirasoftware/jira-
software-8-0-x-release-notes-957981626.html#JiraSoftware8.0.xreleasenotes-
performance)

------
about3fitty
I wonder how many self-hosted GitLab instances are configured with the same
assumption in mind

~~~
jorams
That can hardly be blamed on GitLab though. The setting to make something
public is clearly named "public", and the description is:

> The project can be accessed without any authentication.

Meanwhile, Jira almost seems to aim for misunderstanding.

~~~
dredmorbius
There's specifying authentication and there's specifying routability. These
may not be clearly distinguished to admins.

------
social_quotient
If this had been another s3 bucket on AWS we would be blaming amazon. Here we
don’t blame jira/atlassian. Why do we do this? (Honest question)

~~~
BinaryIdiot
When you setup an S3 bucket the permissions are pretty explicit. The issue
here is the UI is confusing (arguably it's wrong but I digress) and is related
to a configuration that you'd have to hunt for. It's not an obvious permission
that you can easily know it should be changed unless you have experience with
it (whereas S3 it's listed right there when you created it and by default it's
pretty private).

~~~
paulstovell
It didn’t used to be. When you set up a bucket with public read access, you
might also decide to give other people on your team write access to the
bucket. AWS conveniently provided an All Users option for this.

Except it wasn’t “All Users in your AWS account”, it literally meant ALL USERS
of AWS. Disaster. This led to the same problems as this Jira issue.

AWS changed it so that’s no longer an option. Atlassian should do the same.

------
sjg007
I mean.. why aren't they using a vpn and restricting external access at the
firewall?

~~~
Spivak
Because (in theory) the Atlassian stack is sufficiently hardened and can be
safely run over the public internet.

The idea that everything must be behind a VPN at all times and you must hit
the exact same login form twice to do anything is silly and why most office
staff love off-prem services.

~~~
tastroder
It's not everything, it's services that are only used internally (which might
or might not be the case for Jira depending on the use case).

There's no two login forms anyway if your IT doesn't want it to be, on one
hand VPNs are usually not accessed on demand during the work day and on the
other hand all Jira versions I'm aware of can be integrated with some form of
SSO anyway if you feel like it. Offices are usually internal and wouldn't have
to deal with a VPN anyway.

~~~
Spivak
The problem is that my fellow IT people define "only used internally" to mean
"only used by employees" instead of "only useful to someone physically at our
office."

Protect your VPN with SSO and then protect your service with the same SSO is
incredibly common and perfectly demonstrates, in my view, the stupidity of
VPNs.

The VPN added NOTHING to your your authentication or authorization.

If you're going to fully check a users credentials at the VPN where users are
in a totally untrusted domain and fully check them again at the service then
clearly your internal network is also being considered an untrusted domain --
which I think should be the case -- but then all the VPN does is move users
from one untrusted domain to another. Why is the VPN there?

I think offices would actually be more secure if services like this were only
accessible externally (doesn't have to be literally, just philosophically no
reason to route out and back in your WAN). Instead of connecting to a VPN and
having access to the internal network where there's probably a lot of surface
area exposed the external only model means that you're only connected to the
single service you authenticated to.

~~~
tastroder
I don't think I get this argumentation. VPNs are easy to use these days so
there's no "physically at our office" angle imho. The VPN adds a zone that the
client can trust (which should not entail your whole internal network being
exposed to it but I've never seen that anywhere to be quite honest). They get
their Windows/AV/whatnot updates from that, connect to the services they need
on the road.

Simultaneously the VPN shields said services in a managable way, though that's
more of a on-premise vs. cloud discussion I feel like, with the VPN being the
way to get access to the on-premise stuff if you do not happen to be in the
office. Maybe I'm missing your alternative? VPNs have some upsides over, say,
a reverse proxy for that use case (weird sales clients for example that talk
TCP, not HTTPS) in the setups I've seen.

It also prevents exposure to the exact scenario we see in this very thread.
Finding public instances of popular software is easy, enabling drive-by
exposure to vulnerabilities. Putting them behind a proxy/VPN at least provides
a hurdle for non-targeted attacks from my point of view.

------
killjoywashere
Google is taking that search string as evidence of suspicious activity, fwiw.

~~~
libria
It's like a house alarm that tells the burglar "Hey you seem shady. But you
can come in if you promise you're a good guy."

~~~
killjoywashere
Except the homeowner doesn't own the alarm. It's more like a mapmaker allowing
access to the index of the map, which a clever person happened to figure out
revealed where some houses with broken locks are. And the mapmaker has the
decency to say "hey, let's see if this visitor is at least human" before
allowing you to proceed from the index to the map itself.

Ok, now the mapmaker has solid evidence that this human is doing something
shady.

Human, you are on notice.

------
29athrowaway
Was it necessary to leave the names in the screenshot?

------
graycat
So, in the documentation, "all" was very unclear. Users guessed that "all"
meant all in the company while it mean all in the whole world!

So, wildly ambiguous, unclear, dangerous product documentation.

Could clear that up by being really clear and explicit about "all in the
world", "all in the company", "all in a particular project", etc. and then
lots of very clear examples.

But it was easier just to have some check box, icon, etc. described as "all".

In current computing, such documentation nonsense is usually resolved by the
usual way of making sense of a computer user interface, _experimentation_ , or
use the TIFO method (try it and find out), or throw the options and
combinations of options over and over against a wall to see which ones appear
to stick, or do the usual, my usual description, "mud wrestling", all due to
bad documentation.

It is as if the software were designed and written by people who thought that
a check box with "all" was _all_ there was to the work.

Well, in this case the TIFO experimentation involved hundreds of Fortune 500
companies and many other organizations, small to the largest, around the
world.

It is as if the documentation writers were inarticulate and essentially
illiterate.

So, Xerox PARC thought that some buttons, say, as on a microwave oven, would
be sufficient for controlling lots of Xerox office machines. Then the computer
industry, with _graphical user interfaces_ thought that nearly all of
computing could also have such a user interface. Nope: Commonly even makers of
microwave ovens have well written users guides. The many millions of Web site
user interfaces are generally much more complicated to control than a
microwave oven and also need good _DOCUMENTATION_ , e.g., much more then
cryptic, not a chapter, paragraph, or sentence, not with examples, clear
definitions, etc., but just a word or two from a _roll over_. And often there
is just an icon, can't pronounce it, can't spell it, can't type it in text,
can't send it in e-mail, can't look it up in a dictionary or with a search
engine -- which takes us back to pictographs before the Roman alphabet. That
situation, in technical language, is a bummer; more clearly a disaster as the
OP shows.

IMHO, a good candidate for the biggest bottleneck in the future of computing
is the quite general lack of good technical documentation.

E.g., two weeks ago I signed up with a different Internet access provider
(ISP). They promised me I could have up to five e-mail addresses. Sooo, I
tried to get a second address for the alpha test I plan for my project (Web
site -- no icons!). It took 14 hours of my time and nearly that much time with
third level technical support. With decent documentation, I could have done
all the work in about 10 minutes. But, three days ago their Internet service
quit in my neighborhood. Their efforts to reset my equipment (cable modem, IP
router, WiFi connection) make my connection from before the outage work no
longer. The fix took a day and a half, about 30 hours of my time, and about 15
hours on their third and fourth level technical support. With decent technical
documentation, I could have fixed the problem myself in 10 minutes. And I have
MANY other such examples. Several hours or days instead of a few minutes --
HUGE bottleneck to progress.

I say again: One of the worst bottlenecks in the future of computing is the
lack of decent technical documentation, in a natural language, e.g., English,
and mostly in text. No joke, guys. Icons, check boxes, radio buttons, text
boxes, pull downs, pop ups, roll overs, etc., are NOT and can never be good
natural language technical documentation.

TIFO on world-class issues is a huge disaster waiting to happen.

~~~
sverhagen
I'm all for good documentation, because not everyone learns in the same way,
and if you have a product as broadly used as Jira, I think its user base
deserves it. But in the basis it's just an inefficient, after the fact attempt
to mitigate poor UI/UX. Which could EASILY have been clearer about the access
rules, and they could (should) have defaulted to a more restrictive setting.
First of all to protect users against the clearly more damaging of the two
extremes (too restrictive versus not restrictive enough) but also because it
better fits Jira's nominal use case.

~~~
graycat
Yup: Their "all" was a high powered, loaded gun, cocked, no safety, hair
trigger, ready to go off at any time.

------
ga-vu
Kinda hard to take his word when all the images are blurred in 90% of their
surface.... lol

You could have uploaded an image of my router's dashboard and I wouldn't have
known what I was looking at

~~~
Kronen
Well he is in both Halls of fame(United Nations and European government)

~~~
pandler
And I also just verified by checking myself against some known Jira dashboards
and searching for some of the search queries he provided... I'm not sure what
there isn't to trust when he tells you exactly how to verify the information.

