Data from Atlassian dumped online after apparent hack
cyberscoop.com
cyberscoop.com
It doesn't matter how credentials were leaked.
I was trying to distinguish between breaches that result from intentional exploitation (malicious or otherwise) and breaches that result from negligence. Having thought about it a bit more, these things are not actually mutually exclusive. Many intentional exploitations take advantage of dumb mistakes (e.g. posting credentials in a public repo).
As such, I take back my earlier disagreement: this is a valid use of the word “hack”.
Note the difference:
> accidentally posting credentials for Atlassian's Envoy setup in a public repository
this was a leak.
Using those credentials to then obtain other data and post them publicly-> this is the hack. A hack does not need to be complicated, just to accomplish something that was not intended.
Similarly, convincing a security guard to let you in to an area of a building that you aren’t allowed into is also an exploit.
Can you go into this a bit more as I'm not seeing anything being exploited? Were the credentials not valid? Was exporting data not available to that authentication user? Did they elevate their permissions beyond what the original credentials provided?
If I find $20 on the street and buy a lotto ticket and win, what was exploited? I used the money to buy an item that can be purchased with money. In this example would you be saying that finding the money was the exploit or using the discovered money to buy something?
> Similarly, convincing a security guard to let you in to an area of a building that you >aren’t allowed into is also an exploit.
I agree this is an exploit, aptly named social engineering. However in this example you started with nothing and "convinced" the guard to do something.
This is different than already having the credentials. The equivalent for this example, to me, would be finding a persons office/building card and walking past the guard but I wouldn't see that as an exploit. Both the access control and guard are reacting accordingly to the expected inputs.
I would view an exploit as going beyond the intent of the built-in/existing controls.
You can debate crackers vs. hackers and that its the intent that differentiates them but its a moot point based on that very thin veil of separation. Similar to the title security researcher or pentester you only can believe whats presented publicly by that person, group or organization and you can never validate that they haven't sold access or exploits to anyone else.
I would say your generalized term would be better understood as a security audit, pentest or bug bounty which would appear to represent a non-malicious intent to gain "successful unauthorized computer system access" as defined by the contract.
[1] https://www.merriam-webster.com/dictionary/hack [2] https://cybersecurityventures.com/movies-about-cybersecurity... [3] https://www.amazon.com/Cuckoos-Egg-Tracking-Computer-Espiona...
https://en.wikipedia.org/wiki/Hacker
"Reflecting the two types of hackers, there are two definitions of the word "hacker":
1. Originally, hacker simply meant advanced computer technology enthusiast (both hardware and software) and adherent of programming subculture; see hacker culture.[3]
2. Someone who is able to subvert computer security. If doing so for malicious purposes, the person can also be called a cracker.[4]
Today, mainstream usage of "hacker" mostly refers to computer criminals, due to the mass media usage of the word since the 1990s."
Fortunetly there is a trend to revert back to the non malicous meaning of the word. See you are commenting on a "Hacker" news site. See https://hackaday.com/ See even "DailyHacks" or "LifeHacks" in a social non technical setting, etc. Hacking is simply fiddling with a system and making it do something that it was not designed to do.
In my original comment I was looking for the OP to expand upon:
"I have never in my life heard that hack comes with malicious intent"
In this case, they weren't exploiting any weakness of the system thus they did not hack. Logging in is an authorized action. Who is using those credentials is another story. Clearly it is a user mistake. It's like leaking your SSN and saying people hacked your credit card.
But the credentials were stolen and used to access information that was supposed to be private (even if keys are left lying on the ground, you can't just take the car that they open like its yours).
All of the legal liability of having broken the law, while very little street cred of having done anything particularly novel.
What if the data was on a hidden URL that required no auth, would that still be considered a "hack"? After all the URL wasn't suppose to be known, even if it was in public sight.
And and even more extreme example would be what if the information was mistakenly published? Is it still illegal to download it?
There must be some line here right? Is it just that there needs to be a reasonable assumption that the data is public?
So if there's a URL that isn't normally accessed by the public which has no auth on it, and you stumble across it as part of scanning of the api, then accessing that information is very likely illegal.
If you try to use that information to publicly embarrass the company, you may wind up getting arrested for it.
For the information to be made public, to have a defense you probably need to show that somebody in the company deliberately pressed some kind of "make it public" button. If there's a folder with 999 other documents which the company intended to be public but one of them shouldn't have been included then you've got a lot better leg to stand on.
Your freedom may very well come down to which analogy lawyers can convince a judge to apply. Don't expect the law to act like a computer program with definitive inputs and outputs. You very well may get treated as guilty if you "act guilty". And the bigger risk here is that if you find something like a document which was errantly made public that you may get treated like someone who went jiggling doorknobs and found one that opened for you. There is no definitive line, there is only what a prosecutor can convince a judge.
The defense of "but they had crappy security, I'm just doing a public service letting the public know how bad they are" never flies, and there's a constant trickle of "security researchers" who get charged with hacking crimes for stuff like this.
If I read "Data from Atlassian dumped online" the obvious inference is that it would be the primary data from Atlassian, i.e. the customer data about customer projects which Atlassian is hosting as the key part of their business. This is not it, this is something much less sensitive that affects much less people - while this is bad, this is absolutely insignificant compared to the level of badness that the title implies.
Most likely they were API keys that were leaked.
... which begs the question why they were using API keys and not workload identity?
How are they still alive?
Now one thing that Github has is integration. You get lots of stuff integrated for free where Atlassian offerings are separate products. And you don't have to configure much.
You can't compare Github to just bitbucket. You have to compare it to a combination of bitbucket, bamboo with Elastic agents and Jira. With a competent admin this is all easily set up and administered. And especially if you are a largish company Jira is the killer vs. Github issues. Especially if said company is somewhat process heavy which Jira is just the best at. So configurable and extensible. Of course a small startup or open source project will prefer the zero fuss Github.
And of course as devs we don't care much about those parts. But you did ask why they are still alive.
The “find file” button which opens a quick open style prompt makes it as easy to find a location on GitHub as it does when I use VSCode
What I personally use the file explorer in a PR for is for various other things.
* Quick overview of the "complexity" of the change. If I see a huge list of files or files "all over the place" that let's my spidey senses tingle. Much more so than a simple "X files changed" bit of text could.
* Navigating around the changeset by most interesting area first. E.g. I might see at a glance that there are changes in three folders of interest and the rest are less important. I don't read PRs from top to bottom like Github tries to make you. I find that unnatural.
* I can also easily, visually, jump around between these areas/files to cross references changes without having to remember their names or scrolling a lot.
* In large changes (lots of files in lots of places - it happens sometimes) I can collapse folders that are not interesting or that I'm done with. The fact that I already opened a file once does not tell me anything really as I tend to jump around between files to cross reference things. In fact one great feature to have is to mark a file as "unread" again. Which IIRC Crucible had.
Jira is the worst ticketing system that exists other than every other ticketing system. Yes you could use Rally or whatever but it's unlikely that migrating to a different tool is going to solve any problems that you have with Jira.
BB is, well... orgs that have BB usually have people who look after BB and don't want you to move, and developers who do want to move, but don't have the heft within their organisation to move to good tools in the fact of demands to push features instead of improve tooling.
At a certain point it’s just an abstract spreadsheet with custom rules no one knows how to maintain, and the team ends up praying to the Jira gods like some ancient religion to keep their dev process going.
Anyone who does actually have a handle on it becomes a go-to resource on their team, so they jealously guard their install and never let the company switch try anything else to preserve their status
Not at all surprised this happened, and more will invariably come.
Systen A with permissions: Jira
System B with permissions: AWS
This is the only property the two systems used in the analogy are required to have. In fact they don't even need to have the exact same property. Of course more similarities between the two make the analogy closer to each other but that is not required.
Obligatory - if somewhat far fetched - car analogy: Tesla's app is a complete mess! Depending on how you set up access, anyone with permissions to your car could just drive off with it!
The analogy is that Amazon is to AWS as Atlassian is to Jira.
Say: Amazon hosts their static website content on S3 and left it open to public write access for example.
I do think that's a relevant part of the story.
If you are referring to your own vaguely described issue, please do report it to them or any other "authority" you see fit so it can be fixed if indeed that is the case. FWIW I do know my own tickets I created with them in the past were not publicly visible as in they did know how to set up issue security correctly ;)
That said misconfigurations happen all the time in large organizations. Not defending Atlassian there. No affiliation beyond using their products at work.
Each ticket is associated with a group or channel or whatever jira groups by.
Account -> Group mapping is 0, 1, infinity
What was the hack, scraping LinkedIn?
In all seriousness, I feel like we need some different language or a color-coded system (ugh, kinda hate that after I just typed this) for the severity of information in hacks. All of this information listed is semi-public anyway. Birthdates/SSNs/private info I can understand getting up in arms about. But names and email addresses? Wait until younger folks hear about this giant book phone companies used to deliver that had nearly everyone's name and phone number in it!
No, we just need to read the article.
There already is language for this, but what we often have on HN are people posting random and old links to online newpaper articles that don't convey enough information about the vulnerability, its root cause, or its effect. In this case, there isn't a vulnerability score, because there isn't a disclosed vulnerability or exploit. However, there may be some risk that people outside Atlassian are unaware.
CVSS scoring is used in many places. There are calculators that score a vulnerability in the context of a base score, temporal score, or environmental score. [1] Here is NIST's NVD page. [2] At the bottom are some of the most recently scored vulnerabilities.
If we search for Atlassian tagged vulnerabilities at the NVD site[3], we see that the most recent vulnerability, CVE-2023-26256[4], actually is ranked high at 7.5 on the v3.1 CVSS scoring. There is an actual description. Plus there are references to advisories/solutions/tools, the CWE, a listing of affected software configurations, and a change history.
[1] https://www.first.org/cvss/calculator/3.1
[3] https://nvd.nist.gov/vuln/search/results?form_type=Basic&res...