Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

zdnet.com

Post reply on HN
Print view View original

251–260 of 344 posts

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#251

Post by craftinator »

jordanbeiber wrote: post #228
craftinator wrote: post #211

Earlier quoted context omitted.

If you provide a tool that let's managers easily and arbitrarily increase the requirements on their employees, over time they'll continue to do so, because it's a management tool and their job is to manage. I experienced this phenomenon when I was a designer / CNC programmer. We had a form for requesting a part to be designed and machined. It had a box for tolerance allowance, where the person requesting a part could…

He obviously did not understand what his job as a manager is about. Why on earth would a manager be allowed to set tolerances like how you describe, tool or no tool? It makes no sense and is first and foremost a management and cultural issue. Second a work process issue. Solid third, one of competency. Probably ways below numerous other problems lies the tool. You obviously needed to be able to set tight tolerances f…

> He obviously did not understand what his job as a manager is about.

> Why on earth would a manager be allowed to set tolerances like how you describe, tool or no tool?

He's not the expert in the field, I am. Normally, I would have vetted the work orders and fixed it before hand. This is similar to managers in the software world, where the team lead or senior engineer would say," No, we won't do that, it's a bad idea". He never should have been exposed to an option that could screw everything up so badly, but I mistakenly left it on the form. He was just trying to fix what he perceived as a potential problem. He was used to making small changes to work orders to save money or get a more refined product.

The biggest problem with our company's structure is that the operators, for whatever BS org reason, don't have the "pay grade" to tell him to pound sand. Managers need to sit below engineers, in my opinion.

> you must be measured like crazy - set goals based on metrics that will push things in a direction you see effective.

In my sector of manufacturing, margins are king (regardless of locale). If you can cut 10 seconds from an operation, or find a tool that lasts 20% longer, you can save tens of thousands of dollars a year, so we track everything.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#252

Post by kortilla »

jordanbeiber wrote: post #228
craftinator wrote: post #211

Earlier quoted context omitted.

If you provide a tool that let's managers easily and arbitrarily increase the requirements on their employees, over time they'll continue to do so, because it's a management tool and their job is to manage. I experienced this phenomenon when I was a designer / CNC programmer. We had a form for requesting a part to be designed and machined. It had a box for tolerance allowance, where the person requesting a part could…

He obviously did not understand what his job as a manager is about. Why on earth would a manager be allowed to set tolerances like how you describe, tool or no tool? It makes no sense and is first and foremost a management and cultural issue. Second a work process issue. Solid third, one of competency. Probably ways below numerous other problems lies the tool. You obviously needed to be able to set tight tolerances f…

> Why on earth would a manager be allowed to set tolerances like how you describe, tool or no tool?

Because the tool allowed it. What you’re failing to grasp is that UI has a massive influence on how humans behave.

People see empty fields and think they should fill them out.

Jira very frequently encourages over-specifying things by the ticket filer (it doesn’t hide fields by default and “helpful” human behavior is to provide as much info as possible).

The second order effect is that the project managers realize they can add fields and people start filling them with data. This is great for visibility without having to poll all of the employees! Except now it’s garbage data because the wrong people are filling in the data or they are bad guesses and inevitably that rolls up into a report that causes problems later.

Jira is a bad tool because it misleads both people and product managers into thinking they can get data from it that they realistically can’t.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#253

Post by cptskippy »

numair wrote: post #72

The good thing about the fact that Atlassian offers both on-prem and cloud versions of their offerings is, everyone is now aware of the awful engineering practices that underpin their products. We have to assume that there are problems of a similar nature in their cloud service, which is way more of a problem considering the number of orgs that depend on the JIRA SaaS offering. Maybe the founders could have used some…

> It’s amazing that this company continues to fall up, and that the founders have taken on roles as the ruling digital gurus of Australia

It's probably because they primarily target non technical folks. Our IT department has inherited numerous Atlassian products adopted by business units and it takes at least a year or two to unwind them if ever.

In the meantime the just keep cashing those checks.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#254

Post by workerdrone451 »

keithnoizu wrote: post #236
hn_throwaway_99 wrote: post #146

Earlier quoted context omitted.

> The good thing about the fact that Atlassian offers both on-prem and cloud versions of their offerings is, everyone is now aware of the awful engineering practices that underpin their products. Regardless of what one thinks about Atlassian, this is a completely ridiculous bullshit statement, and anyone who works in the world of business software knows it. I don't think there is a company out there that hasn't had c…

Atlassian has a reputation for poor engineering/backend practices. It's a great (to use) product though.

It's an ok product until you run into performance issues. Which due to said horrible backend engineering is numerous. Also their support is awful.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#255

Post by wiz21c »

arghwhat wrote: post #182
hn_throwaway_99 wrote: post #146

Earlier quoted context omitted.

> The good thing about the fact that Atlassian offers both on-prem and cloud versions of their offerings is, everyone is now aware of the awful engineering practices that underpin their products. Regardless of what one thinks about Atlassian, this is a completely ridiculous bullshit statement, and anyone who works in the world of business software knows it. I don't think there is a company out there that hasn't had c…

You are missing the point entirely. Any sufficiently complicated product will eventually have major CVEs, as you say. Anyone having hosted Atlassians product know that these products are nothing but garbage fires on the inside, as the commenter above said. Both of these statements are true and not mutually exclusive in any way.

> these products are nothing but garbage fires

Would you care to give us alternatives, for example, to the JIRA bug tracker (which I used a lot, slowly :-))

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#256

Post by tgsovlerkhgsel »

zepto wrote: post #192

Can anyone comment on what the value of this attack is to the attackers?

At the very basic, almost any attack can be monetized through resources (crypto mining, DDoS-as-a-service, selling access to the machines to other criminals) or extortion (ransomware, threatening to expose data), at scale and without the attackers really having to care too much what they hit.

If they devote more time per target, they can also go after specific data, e.g. for espionage or insider trading.

One compromised server can also serve as a foothold ("oh, you have a service account with all permissions on that server? nice!") which then allows all of the above to be launched against a bigger part of the infrastructure.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#257

Post by tgsovlerkhgsel »

achillean wrote: post #121
rick_ross wrote: post #103

I know a guy who said “We don’t show up on Shodan because Shodan only groups by IP and does not know the VirtualHost, we’re fine”

FYI: Shodan also does monthly hostname-based scans of the Internet where we set the "Host"/ SNI headers. We use our own DNS DB to grab a list of hostnames/ IPs to launch scans of: https://www.shodan.io/domain/ycombinator.com At the moment, I think we're checking around 600 million hostnames.

Is that DNS DB publicly accessible?

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#258

Post by Y_Y »

Y_Y wrote: post #205
dijit wrote: post #87

> The vulnerability only affects on-premise servers, not those hosted in the cloud. This is a dangerous statement to make and should be revised to say: > The vulnerability only affects standalone versions of the software, not the managed service of confluence provided directly by Atlassian. The problem with the former is that lesser technical people, especially directors, might assume they're fine because their stand…

Why do people say "on-premise" instead of "on-premises"? Here follows the definitions I am familiar with: "premise" - a house or building, together with its land and outbuildings, occupied by a business or considered in an official context. "premise" - a previous statement or proposition from which another is inferred or follows as a conclusion. (I have the privilege of worrying about this because my company uses Con…

(That first one should be "premises", but I didn't proof-read or notice in time to make an edit. Also the last sentence should have "self-hosted". Bad QA.)

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#259

Post by thatsamonad »

lightning19 wrote: post #176
thatsamonad wrote: post #165

Earlier quoted context omitted.

Another issue is that they sent out the initial communication on August 25th (which I did receive), but the original wording indicated that it only affected servers that allowed user self-registration. We didn’t have that enabled, so I held off for a bit because the risk seemed lower and our upgrade process is a bit arduous (we have quite a few customizations on the server and need to perform all upgrades on a test i…

100%, I did the same thing on my side. If shit really hit the fan I could've lost my job because of this as it was my call to not patch. When I went back to the link provided in the email the self-registration part was removed so I looked like a complete tool over zoom when trying to explain this situation to my boss

If it helps you at all, we aren’t the only ones who were blindsided by the severity-level update and lack of further communication. There are several comments on the source ticket calling out the poor communication, and the earlier comments are all asking for clarification about the user registration requirement: https://jira.atlassian.com/browse/CONFSERVER-67940

Both I and another colleague looked at the issue when it first came out and decided we were “safe” for a bit based on the initial communication. Many IT/IS teams were probably scrambling over the long weekend to patch this issue.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#260

Post by closeparen »

cogman10 wrote: post #78
pletnes wrote: post #74

Earlier quoted context omitted.

There are many jira alternatives out there, from what I can tell. Why are they not disrupted already, if it’s such a low hanging fruit? (Honest question - I don’t have any personal preference)

Atlassian products are vast, integrated, and support all the crazy draconian processes that every insane project manager wants to implement. You can't easily dump Jira if you are using Jira, confluence, bitbucket, and whatever their CI/CD product is called (bamboo?)

Not just product managers. All kinds of enterprise processes decompose nicely into tickets. Arbitrary workflows, transitions, validations, custom fields, filters, and reports make it one of the most successful “no code” tools behind Excel, and then the REST API is comprehensive and well documented. At my company JIRA bots are compelling and cheap alternatives to new web UIs for internal tooling needs, surprisingly often.
Post reply on HN