Misconfigured Jira instances exposed data of hundreds of Fortune 500 companies
medium.com
medium.com
To prevent this issue as a site admin on Jira cloud, go to:
Jira Settings -> System -> General Configuration
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.
Guess it's on the roadmap, like everything else. https://confluence.atlassian.com/confeval/other-atlassian-ev...
Maybe not perfect with hosted cloud servers (as opposed to your own origins), but a good start!
> 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.
Is Jira a UX disaster because of just that?
Or is it bad on top of that?
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.
And now that you describe it, I suspect it's inevitable that anything bad in the first way becomes bad in the second. If the purpose and the use cases are clear, that can guide good design. But if the product is too complex for mere mortals to understand it, then of course the teams building it will eventually turn it into a frankenstein collage of UI issues.
- 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.
To take your transportation example, there is no good way to provide one product which scales from “shoes” to “airplanes” by user configuration. It makes no sense to ask if the shoe-plane is well implemented or not. It’s a terrible concept to begin with.
You make it sound like, otherwise, your product is a failure, while Jira is and incredible success.
Of course, there are good managers of developers. But they neither use nor need Jira.
As an aside, I think that's why Agile and Lean methods have been mostly adopted in name only, leaving the substance untouched. The goal of both movements was to shift power to people doing the work, and managers see that as a reduction in importance.
Yes. It's crazy how many times I've made mistake in Jira or was surprised by it. It feels like there is no consistent in Jira and each feature has its own set of rules and logic and all these features were tacked on to create Jira.
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.
Unfortunately JIRA is monstrously complex and dead weight hides in that complexity as you've noticed. My company is so far gone. We use JIRA as the system of record for change audits. This is a function it is particularly poorly suited to. I don't even want to list the other things we use it for. They are too numerous an depressing. But rest assured, if you can somehow map a process to JIRA, it's there.
I need to bookmark this, and - with your permission - cite you when (often) I am proposed obscenely complex software to solve trivial issues.
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.
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).
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.
[1] https://medium.com/@logicbomb_1/bugbounty-nasa-internal-user...
https://medium.flatstack.com/misconfig-in-jira-for-accessing...
> 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
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 )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.
https://confluence.atlassian.com/jirasoftware/jira-software-...
> The project can be accessed without any authentication.
Meanwhile, Jira almost seems to aim for misunderstanding.
Would we? Amazon requires you to explicitly make the bucket open. It also allows you to prevent that account-wide with IAM policies. It also allows delegating the opening to public to specific people.
And I believe you get warnings about public buckets from their advisor. (May be misremembering that one) You can easily audit that too.
So basically I don't see what else could AWS do to make this more secure. It's 100% on the user at this point.
By all current evidence, we'd blame Capital One, so I guess this is consistent?
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.
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.
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.
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.
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.
Ok, now the mapmaker has solid evidence that this human is doing something shady.
Human, you are on notice.
https://store.google.com/us/product/nest_secure_alarm_system
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.
Well, it didn't make ice. Since it would dispense water, the water line WAS connected and working.
Well, the front door has lots of buttons. They didn't help.
Finally the solution: Look in the freezer. At the top pull out a complicated plastic piece of unknown utility. For me, bend down, look up, look at the back wall of the freezer in the upper left corner, and see a switch, ON-OFF. It was OFF. Now it's on, and the ice maker is working!
I needed a manual and didn't have one.
The documentation I mentioned is important, for microwave ovens, fancy refrigerators, and certainly for the user interface of high end software that can have disasters such as in the OP.
You could have uploaded an image of my router's dashboard and I wouldn't have known what I was looking at