> multiple current employees’ data, including names, email addresses, work departments and other information.
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!
They had access to a visitor management system, which may turn out to be fairly interesting. Not the crown jewels, but who is visiting, and how often can be sensitive.
> 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.
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.
The title of the post seems a little bit disingenuous - Atlassian themselves wasn't hacked, nor was the vendor that the data ended up coming from for that matter.. It was a case of an employee accidentally posting credentials for Atlassian's Envoy setup in a public repository, which they apparently use for in-office resources, hence why it has basic employee information and floor plans.
>> Atlassian themselves wasn't hacked...It was a case of an employee accidentally posting credentials for Atlassian's Envoy setup in a public repository
Disagree. “Hack” typically implies malicious intent so it kind of does matter. “Leak” probably would have been more appropriate since this appears to have been the result of negligence rather than malice.
I have never in my life heard that hack comes with malicious intent. To me hacking is a generalized term for successful unauthorized computer system access.
After giving this some more thought I think you’re right. I would even broaden your definition to include using authorized access in ways that weren’t originally intended by the computer system’s designers.
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”.
Myself, I would agree with your earlier definition of this being a leak[1] simply using the definition. There wasn't a program created or exploit discovered that exposed previously private information, an authorized user posted to the incorrect privilege level location.
A leak by definition is something from inside. This was not. This was an exploit from outside actors that made this data available to the public.
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.
I disagree that finding mistakingly posted credentials, logging in and performing an export task is a hack, hacking, or exploitation. All the functionality was already available as it would be for any authorized user. This is the equivalent of reading the user guide.
> Using leaked credentials to access a system that would not otherwise be accessible is >absolutely 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.
There is an active searching for these credential leaks in the various repositoriues to then be used so this is an exploit. It shows intent, an organised way of searching for vulenrabilities and accomplishment of the task.
It's the equivalent of stalking the security guard and evasdroping on his public communications in the hope that he slips us and when drunken enough will reveal the passcode to the entrance door. Public repositories make it more easy to "stalk" in that sense, but yet it's a active search for a vulnerability, that of not not following security recomandations.
If someone intends to rob a bank doens't matter how they have obtained the vault key, when the bank was robbed.
Can you expand on this a bit? A search on the internet provides plenty of examples of this, even a search in the dictionary[1]. Along with movies[2], books[3], and typical news reporting hack/hacking/hackers has been used to indicate malicious intent.
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.
"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.
Yeah I understand the difference between the two which is why I mentioned them. Moving back to the non-malicious meaning seems like a moot point. The layperson doesn't care about the difference only the outcome. Which in most cases is they don't know you or have a business relationship with you and you are now accessing their system. If I was working within the pentester / security researcher space I would not be doing any work outside the bounds of an explicit contract/bug bounty program, etc as any access gained would be illegal access regardless of your "supposed" intentions.
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"
as that seemed odd given the books, movies and legal cases.
The employee leaked the credentials, but I'd argue that finding the leaked credentials, logging in, dumping the data into a file and publishing it with a note how you pwned the company is still a hack. Not a highly skilled hack, but still a hack.
I suppose it's the most basic possible level of defense-in-depth that Atlassian didn't reuse those credentials, or put other sensitive operational information (that could result in a deeper breach of customer data) into their Envoy data. So it technically matters which credentials were leaked. But definitely still not a good look.
Sure, but it _does_ matter _what_ credentials were leaked, and these creds didn't secure anything particularly critical in the grand scheme of things. Sure it might suck a bit for Atlassian employees who wanted to keep the fact they worked for Atlasisan a secret, but given a lot of them walk around wearing T-Shirts with "Atlassian" on them, I don't think they do.
Yes, they're not the same thing. First, the credentials were leaked. Then, the service was hacked using the leaked credentials. Afterwards, information obtained in the hack was leaked.
> Hacking is the act of identifying and then exploiting weaknesses in a computer system or network, usually to gain unauthorized access to personal or organizational data.
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.
Social engineering is social engineering. You're hacking humans if anything, but you're not hacking a system by definition. You can social engineer people for other reasons than hacking a system.
At some point it does matter how the credentials were leaked. Eventually security will succeed or fail due to the behavior of the people involved in the system (users, admins, developers, executives), no matter how much you try to engineer a solution.
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.
At what point would (if any) would the liability change?
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?
If you're jiggling doorknobs and one opens for you, that is generally illegal.
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.
It does matter what information was leaked, not just "information that was supposed to be private".
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.
Their permissions system is a complete mess on their actual platform; if you create a support request it generates a Jira ticket, but depending on how access is set up, you may get access to the entire support "project" which means you can see other customer's support tickets (I'm being a little vague because I don't want to give the whole thing away, there is more to it than this, but I currently can see every open support ticket).
Not at all surprised this happened, and more will invariably come.
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!
…what? Atlassian uses Jira (a product they own) to manage their support tickets, and they have not configured it to only allow the customer who created the ticket to access their ticket.
The analogy is that Amazon is to AWS as Atlassian is to Jira.
Oh that's the angle you are referring to. Fair enough.I concentrated on the support system part. I don't think that should be part of your analogy. If you leave that out it'd be easier to see what you are referring to.
Say: Amazon hosts their static website content on S3 and left it open to public write access for example.
So you don't think it's relevant to note a company that makes a product can't secure that product for its own use and is actively leaking customer data to other customers?
If by Story you refer to the article, that is not what happened.
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.
The Atlassian engines stalled long ago but somehow they continue to defy gravity. Bitbucket is years behind GitHub. The last time I used it, it was extremely unreliable. Jira is an ugly and laggy mess. Confluence is crap.
Actually Github only recently gained one of the best features bitbucket has always had, which is a file explorer on the left in PRs. I have no idea how people could use Github without that.
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.
> Actually Github only recently gained one of the best features bitbucket has always had, which is a file explorer on the left in PRs. I have no idea how people could use Github without that.
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
Finding a file I already know the name of is not a problem. And Ctrl/Cmd+F works just fine for that.
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.
YMMV as always and Github does have this as well now, so we're good :)
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.
Jira is a beast, like salesforce. It is self-perpetuating. It takes so much effort to configure that there are consulting agencies that specialize in it and charge 6-figure sums to configure your instance… after paying that fee, managers need to cover their asses and keep paying for Jira, because sunk costs.
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
65 comments
[ 5.1 ms ] story [ 128 ms ] threadWhat 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
[2] https://nvd.nist.gov/
[3] https://nvd.nist.gov/vuln/search/results?form_type=Basic&res...
[4] https://nvd.nist.gov/vuln/detail/CVE-2023-26256
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”.
[1] https://www.dictionary.com/browse/leak
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:
as that seemed odd given the books, movies and legal cases.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?
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
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.
YMMV as always and Github does have this as well now, so we're good :)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