US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing
zdnet.com
zdnet.com
Maybe the founders could have used some of that time spent planning a tunnel between their side-by-side $100M houses, or engaged in Twitter rants, to actually bother delivering value to customers. It’s only a matter of time before this product suite is disrupted, and it might represent one of the most obvious low-hanging opportunities in our entire industry.
I still remember being in line at a WWDC a few years back, overhearing someone ask a developer, “where do you work?” When the developer responded with “HipChat,” the other person immediately chuckled and said, “oh — Atlassian... I’m sorry” — and then everyone around them also started laughing. 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 (shows you why it’s so easy for the government to run circles around the local tech industry and pass whatever laws they want).
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 critical CVEs, nor most major open source projects, either.
Microsoft had a recent vulnerability in their Azure Cosmos DB product that left thousands of customers' data unprotected. Google has released multiple patches to Chrome in the past month.
If you demand you'll only use products from companies or open source projects that have never had a major CVE, you'll be writing a lot of your own software that probably has even worse security.
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.
So yes. Yes it does. Unless you meant that CVEs imply garbage code, in which case I think you read the comment wrong.
> everyone is now aware of the awful engineering practices that underpin their products
This one fault doesn't tell anything about overall quality of the product.
Would you care to give us alternatives, for example, to the JIRA bug tracker (which I used a lot, slowly :-))
Paper.
An Excel spreadsheet shared on a Windows for Workgroups share drive.
Carrier pigeon.
Quitting software to become a llama herder.
Seriously, though, after over two decades of using different tracking systems I think that the real alternative to stuff like Jira is to not go there. You may think that you need all those bells and whistles, but you really don't. What you actually need is the simplest possible issue tracking system you can get away with. All you really need is a prioritised list of issues, and a list of who is working on which issues now. ‘Kanban’ boards get pretty close.
Minimalism is power.
JIRA is too many things to too many people - in the quest to be everyone's bug tracker, they wrote (badly) in the whole kitchen sink. This is a general issue with most software, though. Especially big software.
You cannot have complex capable software that is also simple. That's an oxymoron. You can have complex software which works, but it is difficult to get there, and keep it there. There is simply too much that can go wrong that over time, it almost must go wrong.
Keeping everything 'simple' is not an alternative - the world is complex and so even a bunch of simple things, when put together, make something complex. Think unix shell scripts which can be so much sphagetti. The unix philosophy is to keep things simple, and yet ignoring the complexity leads to its own complexity.
That's the real 'terrible engineeing practices' which get down Atlassian and everyone else's programs.
Someone said 'use paper' or 'quit and become a llamma herder' - these seem simple but again, paper burns, shepherds get shot or held up by drug gangs.
All to say, I don't think JIRA is actually that bad. There could be worse products, there could be better. But it would exceedingly difficult to make something simple which also served everybody.
The most annoying bug was that one could only have around 4-5 tabs open before something went wrong and everything stopped updating.
Kiln was also a great product and allowed for using both Git and Mercurial. It was way better than anything else at the time, but lost out to Github.
I always liked Spolsky's Evidence Based Scheduling that was built into the products.
Thanks
It is very enlightening. Try using their editor component to display the text of one of your Jira comments and making it display attachments.
Think about that for a second. If someone finds a vulnerability in JIRA, they don’t just find a vulnerability in that software: they’ve got access to support tickets, issue tracking, etc about lots of vulnerabilities in lots of software. That’s a big deal.
The fact that the US government had to step in and say PLEASE TAKE THIS SERIOUSLY, rather than Atlassian going into a Code Red situation, shows that they just don’t take the level of responsibility they’ve been given as seriously as is required for what they’re doing. This isn’t just some lousy app having a CVE. This is the keys to the kingdom for a lot of very critical software. This is systemic risk. The problem isn’t the code, it’s the culture.
If you “work in the world of business software” and you think that’s a “complete bullshit statement,” I really hope you don’t work on anything for which such systemic risk is possible. Because, to turn your statement back on you, that’s a complete bullshit way to treat the responsibility you have for the data with which you’ve been trusted. Go build a social media app or an online shopping site or something, and stay out of critical systems that can create cascading vulnerabilities.
If you are maintaining the software of someone else and this software is exposed to the internet that's your responsibility to update the software. If you want your service to be available from the web and have good security, use the cloud offering, that's what it's for.
And if you don't want to use external software to manage your internal knowledge, then create some shared windows folders that nobody use and quickly becomes a mess. What alternative do your propose ?
Oh, you mean like Microsoft and Google in the examples I gave?
Why are you changing the goal posts? Your original statement was that this issue is evidence that "everyone is now aware of the awful engineering practices that underpin their products." My clear argument is that this is not the case, as lots of companies with systemically critical software also have bugs of this magnitude, or more.
Imagine being so naive as to think that documentation would be improved by e2e encryption. It's not bad enough convincing developers to write things down, now we need to explicitly share those things with every new person who joins the team?
"Sorry, we can't fix your bug for 6 weeks, Bob's on paternity and the fix is documented on his page".
> MAJOR difference between Chrome getting owned, and the program that hosts all of a company’s internal communications
There's at best 0 difference between these things. Pop chrome, harvest tokens, access Jira. Think about that for a second. What critical company information is not accessible to someone who has arbitrary code execution in your browser.
Confluence has become an absolutely disgusting, bloated Javascript beast. The amount of JS that it loads is unbelievable.
Then again, if you're only using the “ordinary” features, Jira doesn't have much advantage over any other bug tracker; Gitea can integrate with Jira just as well as with any other bug tracker, and well enough that the Jira / Confluence integration isn't necessary.
The Atlassian softwares are okay, but (from my limited experience) worse than their alternatives. On several occasions, I expected a bug, but it refreshed or redirected, and there wasn't a bug. I have found no bugs while using Jira, and not unusably many while using Confluence… but I can say the same for Gitea, GitHub, Gitlab and even Bugzilla. (Gitea's native issue tracker is actually good enough – and therefore better than Jira – for everything I ever used Jira for.)
Perhaps you should consider that not knowing a thing is very, very different than that thing not being true...
I’m not really sure what the point of the rant is. It’s not as if such a comment conclusion is as big of deal to reality as an idiot staying unvaccinated.
But I get it; someone is “wrong”* on the internet.
* where wrong is defined very specifically to one or a handful of particular readers but the error doesn’t rise to being a real problem for humanity
Well that and spending any amount of time using it and feeling the crustiness.
You can't easily dump Jira if you are using Jira, confluence, bitbucket, and whatever their CI/CD product is called (bamboo?)
It isn't the set of features that makes them sticky. It is the 10% of features the lead PM can't live without, and the slightly-overlapping-but-different 10% of features the team PM's can't live without, and the slightly-overlapping-but-different 10% of features the developers can't live without, and the roll-up report features the leadership team can't live without... There has been some research into this phenomena [1]. I'm not aware of a handy term for the phenomena, would surely appreciate someone pointing me to it, and the industry recognizing it and building for it, though.
Internally in my head I call it "multiplexing feature sets". Though I never say that aloud and just give the long-winded explanation if I have to bring it up in meetings.
> ...I don't see any reason why we should prefer Atlassian over Taiga, other than familiarity and inertia.
In large-organization dynamics, never underestimate the familiarity and inertia factors. I regularly see vendors screw this up so badly. Account management teams of even large organization vendors (so they should be taking action upon this, but apparently are not) regularly have no clue what kind of massive red flag it takes to push their decade(s)-entrenched product from "man we wish this could be better" to "you really need to fix this, or we need to start looking elsewhere".
How do you tell when a customer is just kvetching and presenting empty threats, or is laying it on the line to you? Easy: the customer is happy to share with you specific details of how the product shortcomings/defects are impacting line of business processes and the business impact (ask for this under the cover of learning what the critical business impact is so your support teams can devise the most appropriate tactical technical solution for immediate partial/total relief), and is eager for live working sessions with the customer's engineers.
And understand this: rarely will a customer reveal they have switched away until it is practically finished. They want to maintain what little interim support quality they have left, until they can step off. If your account management practices engage "all hands on deck" priority support when you get wind of a competitor in the wheelhouse, then you've lost before you even started. That's why the reveal is always a shock to vendors, and always a done deal when it is shared.
The time to understand that your product and product support consumption experience for a particular set of customer needs is horribly broken is when you notice a customer requesting product support leadership engagement more than 2-3 times in a year. If you aren't tracking those engagement touch points, then I guarantee you are losing license sales. They just don't show up in the sales metrics.
[1] https://www.sciencedirect.com/science/article/pii/S187770581...
If they get plagued by further security vulnerabilities then companies handling sensitive data will concede to migrate, but it won't be simple by any means.
If you believe changing people's habits is easier than ever, it's rather the opposite. Workers are less and less inclined to learn any other way . The alternative has to be order of magnitude better than what they are using, otherwise they will resist the change. The fact is atlassian provide good to great products overall.
Except that confluence and JIRA are both so slow that you'll still be there 2 minutes later waiting for it to load. Perhaps not everybody's experience is so bad? I don't understand how anyone could consider these products convenient given how ridiculously slow they were.
We used to do refinement meetings over video call (I guess everyone is these days) inputting into JIRA, and we'd literally spend 3/4's of the call waiting for JIRA to catch up with the words I'd typed. There's bad engineering, and then there's making writing a sentence text box lag with times measures in seconds.
Even taking the following into account?
>> Atlassian products are vast, integrated, and support all the crazy draconian processes that every insane project manager wants to implement.
Our support board has customized forms. These forms create tickets that can seamlessly be moved to our scrum board once they are vetted. We use JQL to manage a lot of the boards we use. We have custom workflows for different ticket types. We use the comprehensive access controls to grant partial access to users based on custom roles.
None of this rigidly enforces our workflows (aside form access control). Instead, it streamlines sharing information across departments.
When it comes to a company wiki system, Confluence is extremely hard to beat. (I’ve use so many wiki systems. Dokuwiki is my goto.)
All of these systems use a single user account. We use single sign-on, but we don’t have a large IT department to manage the dozens of services we access every day.
People are like”use the shiny thing” forgetting the existing thing has, you know, stuff I actually use.
Everything from sales to support to customizations and integrations matter to companies, especially as they grow and develop their own teams and management structures which require the software mold into their workflows. Whether the management processes are the best is a different conversation, but being able to support any scenario is why Jira and Confluence are so successful.
It's the same reason why Salesforce has dominated CRMs even with so many "modern" alternatives around.
It’s incidentally also exactly why they’re often horrid to work with.
I've tried a lot of these products and in the end come back to Jira because it works better on average for everyone.
As an engineer & former manager, there are definitely things I didn't like about Jira like slowness, but everything else I investigated/used were worse in multiple significant ways.
If you come to a venue like Hacker News, you'll mostly be getting opinions of the people who actually use the product. These opinions do not reflect the interests and priorities of the people who decide which product to buy.
I work with a Jira instance that has something like 20 years of history and over half a million tickets. Migrating just the tickets and their comments might be possible, but migrating all the other metadata and every service and automation we've integrated into the workflows (some of which we depend on to be able to work at all) would take months of work if a suitable alternative even exists in the first place.
If it were just tickets and some CI integrations, migrating away from Jira would be trivial, but that's not where all the value is.
The rest of this your comment reads like you continue to be naive to Atlassian’s success. I have to think many people do find unique value in their products (myself included), some people don’t laugh rudely when they hear what folks are working on, and I think that shows in the overall achievements of the Atlassian team and product.
I’ve witnessed first hand truly fantastic organizational changes after adopting Jira, Confluence, etc., and I wouldn’t continue to write them off so easily.
Nothing Atlassian does is that much better than past tooling, it all comes down to how you want to run your org, what discipline you apply, and where you apply it.
Confluence? Forgotten
Git repos? Forgotten
Notion? New hotness, still forgotten
Google Docs / Office 365 ? Forgotten
This is just a difficult problem to solve, especially for organisations growing at speed.
One of these things is not like the other, and anybody who uses a real editor and VCS but still has to deal with confluence or the rest of the above knows it.
Child poster below going on about markdown etc is absolutely wrong.
Wow, This is incredibly mean.
There are still not any knowledge base tools that can keep up with Confluence. For Jira the competition is slowly catching up but there are still a large gap for big organizations. That's why they are still here, their product is still superior to the competition.
Atlassian get a lot of criticism, that's not always justified
For my part, I've spent enough time using both Atlassian products and competitors to find something to hate in all of them. Familiarity breeds contempt.
That said, I can't think of a single feature Atlassian released in the past several years that made the experience of using Jira or Confluence substantially better. (I could at least say markdown support if that was ever ported to Jira Data Center.)
The argument for software subscriptions is that it funds continuous improvement, but most of the top complaints from 2011 are just as relevant in 2021.
No. It's because their products are sticky in nature. The tools are used to hold the current state and historic knowledge of the organisation, and even the thought of replacing one of them gives IT manager types the shakes.
Yeah, I think that perception used to be pretty hardcore years ago.
I eventually realised that so many, many companies use this software as a backbone to their company and operations. And for the majority of those, the companies like it. So much so that instead of migrating to a competitor, they move to the new cloud offering.
* Selecting a language on one code block changes the languages for other code blocks on the same page, sometimes. (I've not figured out the exact conditions on this one yet.)
* Whitespace is not preserved / rendered the same as the editor; we have several Confluence pages with YAML where the rendered version won't parse, but it looks fine in the editor.
Give me Markdown in git any day.
Ordinary text blah blah {{interspersed code snippet}} some more ordinary blah blah text
working, or haven't you tried it?
[0] https://www.realestate.com.au/news/the-list-australias-top-t...
That might be the most disconnected-from-reality statement in this entire discussion.
Whatever you think about the quality of Atlassian's products, they are ridiculously entrenched and about as easy to "disrupt" as Microsoft Windows.
They just sell their feature list to CEO’s and Product Manager/Scrum Lords, and suddenly Atlassian is an absolute requirement.
This was already obvious to anyone actually using their products.
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.
And what are these practices?
> assume that there are problems of a similar nature in their cloud service
?
> then everyone around them also started laughing
You know, I'm sure that highly paid dev felt just fine.
NIST Link to issue: https://nvd.nist.gov/vuln/detail/CVE-2021-26084
Tweet from USCYBERCOM urging users to patch: https://twitter.com/CNMF_CyberAlert/status/14337876717851852...
Tweet from BadPackets showing where the bad actors are originating from: https://twitter.com/bad_packets/status/1433157632370511873
But on the “attacks coming from”, I’ve never understood putting stock in these. Aren’t these all going to be proxies and botnets?
For the bug in question, I bet the vast majority of webservers never need the ability to call unrestricted Runtime.exec(), yet access to that is just one unsanitized input away from complete control over your server.
OS vendors have made leaps and bounds in the past decade making it much harder for code vulnerabilities to lead to system takeover. I'd argue it's time for server code and language runtimes to make it easier to write secure code.
I absolutely agree that runtimes, frameworks, and server code should do a better job at trust and sanitization, but you will always get to a point where if you want to get something done, you need to do the work.
I guess I’m skeptical that eval() or runtime.exe could or even should take in lists and configs of what the code is allowed to do and monitor for it during execution. It seems like doing that would add countless issues and complexity, but more so just kick the can down the code to another layer with the same eventual issue.
[edit] Oh it's even better. Their site says 'Note: if you are a tech administrator, you will always receive these notifications.' but they never mailed us. Great job, Atlassian, great job.
Then, Atlassian updated the ticket a day later to state the issue affected all servers on the affected versions regardless of user authentication or registration but didn’t send out a follow up communication when they did so. Instead they waited until Friday afternoon before a US holiday weekend to send out another update. So if you weren’t watching the source ticket directly and thought you could wait due to the setting distinction you wouldn’t have known for over a week and you were left vulnerable.
Atlassian should have sent out another communication to all customers as soon as they knew the scope was broader than they had initially thought.
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.
This is unrelated to any mailing-list change, since both were sent from/to the 10991049.xt.local mailing list.
Search for the header entry `List-ID: <10991049.xt.local>` in your Sep 4 email. If it came from that list, the one from Aug 25 will very likely have been lost during transit.
I use their products in the 10-user license program since 2016 and got automatically subscribed to their mailing list back then, and never made some change to the subscription. I'm receiving emails from that list since 2020-10-17.
On the 2020-07-10 I got a mail from them telling me:
```
Subject: Please double-check your contact details for Atlassian
Making sure you don't miss important emails
Hi,
When you purchased your Atlassian products, we asked for the contact information for two types of people in your organization:
Billing contact - A person we contact with invoice and billing information
Technical contact - A person we contact about product changes, security advisories, etc.
We don't want your company to miss out on important information from Atlassian, so please take a minute to make sure your contact information is current. Here's what we have in our system:
```
Once I noticed I did not get an email, on Sep 3, I checked some checkboxes at https://my.atlassian.com/email But that page also says tech contacts should always receive an email regardless of settings. I have received other security announcements in the past.
Office 365 can't find any emails from Atlassian on Aug 25 when searching using the Message trace tool (which also includes any spam mails, deleted mails, et cetera), so I would suggest Atlassian fix their mailing list.
I’ve always found government, sensitive customers (banks, payment processors, healthcare) and big spenders get prioritised with phone call notifications.
However with a deprecated product, the financial impact is so minuscule - leadership won’t prioritise this one unless you’re big fish.
The only companies that are like those companies are those companies.
In most companies, the CS people don't know what anything in that sort of alert means and will discard it thinking that it's a spam or phishing attempt.
The problem is not that he doesn't work for a megacorp. The problem is that Atlassian screwed up.
I think you're reading it as saying that the helpdesk people ("customer support"?) at a large organization like Amazon, Microsoft, or Salesforce would be trained to recognize a mis-directed email from a vendor and send it to the right place, but I don't think that's the claim being made.
Also, regardless of whether or not I received the mail, the initial mail stated that only authorized users could exploit this. So Atlassian did not inform any of their users fully until Sep 4, whereas they were well aware on Aug 26 that the vulnerability was exploitable by anyone.
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 standalone instances are hosted on GCP/AWS/Azure, which counts to them as "cloud".
Reserving 1% because I'd strike "lesser technical" from your final sentence. The misleading quote is simply not correct. It is misleading because it's not true. It says Confluence hosted in the cloud is not vulnerable. False statement that can mislead anyone regardless of how technical they are.
They said "lesser technical people", not "less-technical people". A more technical person might not be able to read between the lines, but a better technical person should.
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 Confluence Cloud. It's vastly inferior to our old aelf-hosted mediawiki, but at least it's not an open barn door.)
Really though, "self-hosted" would make even more sense, as companies often deploy such applications in one or more "off prem" environments anyway. I'd hardly consider my company's multi-region/multi-AZ AWS VPC to be my "premise".
We got hit by this and had to shut down and upgrade. Atlassian are taking a while to send new license keys.
For god sake, can we all agree to stop using OGNL at this point? At my previous job I kept having to fix OGNL vulnerabilities on our stack, it was awful.
Don't remember Apple developer portal hack? OGNL
What about Equifax? OGNL
This thing is so freakingly insecure it's crazy.
Also, not having confluence for a day exposed just how reliant we were on it for day-to-day activities.
For someone not familiar with their products, what did they do for you specifically?
Our teams were also able to do a “network isolation” and essentially bring the server offline quickly, without touching more pieces and possibly exposing our credentials or tokens.
We also had the paid Overwatch protection which is Crowdstrikes 24/7 security monitoring solution which resulted in an actual person emailing half our team at 1am letting us know this was happening and their recommended remediation steps.
FWIW, we dumped crowdstrike for Cisco AMP and have been happy.
Tip: adding noexec to /tmp helped.
Atlassian products are some of the worst glued-together garbage in the industry. The entire product surface area is probably rife with exploits.
Using Confluence or Jira will show you just how much Atlassian cares about its own products.
I'd love for this to be the straw that breaks the camel's back and makes IT/infosec orgs move away from this bilge.
Atlassian produce some of the worst tech on the planet. Trying to administer this crap is horrible.
And don't get me started on how many project managers spend all day staring at Jira tickets instead of actually talking to their teams. Management-by-Jira is a disease, a symptom of bad organisational culture.
At some project size, measured either by software complexity/interoperability or user base, you will need a tool to manage issues and tasks.
What you're talking about is an organization where developers are not empowered - but even empowered developers need an issue tracker or a board of some description.
A "management by jira" culture will not be remediated by tooling.
However, the final part has nothing to do with jira IMO. You would have the same behavior in these organizations regardless of tool.
The dysfunction you describe goes way beyond a single or set of tools.
It wasn't atlassian that "came along" - someone penned down an agreement and, from what it sounds, there was a lack of clarity both in regards to current and future principles of work and collaboration.
What we can do, as devs, to protect ourselves from the madness you describe is to be explicit about our work processes and their purpose. Nothing much, but just a set of agreed upon principles and ways of working which should have nothing to do with tools.
What you end up with, by being explicit, is for having "something" to be supported by one or several tools.
Makes it easier to evaluate, select and change tooling that is fit for purpose.
then they get promoted, and may never learn / experience why a task / defect tracker is not where you store requirements / design.
(note: the above comments are for long lived software only. it you rewrite your web site from first principles every you, do whatever. it doesn't matter)
Then I tried a bunch of their competitors. Still stuck with some of them.
Sadly, some of Atlassian's products - namely Confluence and Jira - are the best in the business.
Those complaining below about PMs staring at JIRA all day... well, this is a problem with PMs, not JIRA, and it happens even if they are using other work management tools. We created a middleman position in our business to deal with the stuff we didn't want to - tracking work, getting requirements, etc - and we must reap what we've sown. They become obsessed with the management stuff because that's why they exist, and they will fill their time to justify their existence.
Since you are looking mostly for the wiki part there is Dokuwiki which is magnitudes better at being a wiki. Remember, wiki is derived from the Hawaiian word for quick or something to that effect and whatever Confluence is it isn't quick.
Don't know how well it will hold up under scrutiny if black hats gets a reason to swarm over it, but unlike Confluence you can hire someone to patch the guts of it if necessary.
Edit: I have no reason to believe it is worse than anything else, I'm just pointing out it probably hasn't had so much exposure to help it harden.
I mean: ux discussions often feels like they assume users are a separate species somewhere between ordinary humans and chimps when it comes to intelligence.
I have some experience with training users and I have only given up once.
These were sales people.
So often, somewhere right above a chimp is where some of your users are.
- you can edit a paragraph without locking or creating conflicts for the whole page
- it is much faster, and as far as I can see the observe–orient–decide–act loop is a real thing and should be taken into account
- much better wiki syntax (compared to old Confluence)
- trivially extensible so you can create forms and other helpers to make it simpler for users to do the right thing
- if one absolutely need it I think there exist at least one wysiwyg extension for Dokuwiki
I would say it is very darn complete, perhaps without the syntactic linking that Confluence has. The only thing missing from it, is a very solid backup and restore method from the admin panel. The authors want users to rely on database backups and file level backups, that must be handled manually. Essentially saying "not my problem".
Just a note on this, this is something I'd like to build in eventually. It's just that each layer of our own we add upon the underlying methods increase the risk of error in something fairly critical.
A simple command-line based backup solution wouldn't be too difficult to add, but restore and admin-panel usage are more significant challenges once you get into it.
VisualEditor is an extremely good WYSIWYG interface. The wiki is able to scale well (project sites are unlikely to approach Wikipedia scale). The API is useful. Wikitext editing gives power users a lot of flexibility, though it’s not as popular as Markdown.
Access control & edit-publish workflow options may be too limited for the desires of some project teams.
http://www.xwiki.org/xwiki/bin/view/Main/WebHome
https://xwiki.com/en/try-xwiki/
[1] https://www.wired.com/story/australia-encryption-law-global-...
One of the main things to consider with BookStack is the semi-fixed Shelf > Book > Chapter > Page structure (Where pages have content, chapters & shelves are optional, and Books can be within multiple shelves). For some this structure is limiting, For others it helps drive organization.
There really isn't that many alternatives, SharePoint maybe, but then you're just suggestion something worse.
The last time we reviewed the Atlassian Cloud hosted products, they did not meet our security needs (requirements include isolated tenant from other customers, customer managed keys, etc) though they were much closer than a few years earlier. We also review the general security practices of the company (for example to make sure they implement a secure SDLC and follow other security best-practices).
Example: If you are a semiconductor manufacturer, you probably are not going to be storing all the documentation about your bleeding edge fabs on a cloud provider.
In short, that’s not happening for a wiki.
XWiki?
Well first its interface, if a non technical user can't user the tool that's going to be a big problem. Confluence has not the best interface but still better than Xwiki. The best the interface the better the adoption as a whole in the company. And for knowledge sharing adoption is critical. That's actually why Notion has been such a success recently. Even though their product is average, people want to use it, because they like the interface.
I don't have the time to do a full comparaison of other features, but wiki tools are in usage very different than collaboration tools. Can you have the list of last consulted documents ? Can you embed external documents ? ... Kind of the same things as Slack vs IRC
So why are they so popular? Because Jira is a wet dream for mediocre micro-managers (of all levels), allowing them to manage by ticket, instead of lead by example.
New thing? Let’s open a new JIRA project and prefix with some random shit show workflow customised by someone who was clearly asleep or incompetent!
> ""["class"].forName(...)
as opposed to:
> "".getClass().forName(...)
Does anyone know why this works in OGNL? It does not appear to be valid Java syntax.
[1] https://github.com/httpvoid/writeups/blob/main/Confluence-RC...
Edit: Oh apparently, it's just a feature of OGNL: https://commons.apache.org/proper/commons-ognl/language-guid...
No, the rest of the company shouldn't be required to enter the complex and esoteric world of Git and fire up a terminal + a bloated code editor and deal with merge conflicts just so they can collaborate on a simple text doc.
This reads like a horror story I'd find on the landing page of some Saas tool under a heading that reads, "The Problem"
Instead, they just won't update the doc at all and will pester the kind of person who does know how to use git until they do it for them. Then the doc will sit there dormant and un-updated until the process repeats.
> a bloated code editor
Have you ever used Confluence? SMH.
All those defending Atlassian need to go read this other current front page hn article: https://news.ycombinator.com/item?id=28414308 and probably lots of other articles about good documentation.
To be fair, I understand what you are saying, but the problem is you are trying to meet the needs of suits, while I'm trying to meet the needs of technical teams. I can acknowledge that git can be daunting for suits, and probably not the correct method for them to write docs, (e.g., I'm not saying force the suits to use git, even though, with a web interface like GHE or gitlab etc, this is actually quite easy and visually intuitive, no terminal or (laughing) "bloated code editor" required) but it seems the "suits side" of this argument doesn't want to acknowledge that the needs of technical teams aren't being met when they force their lowest common denominator tool on the entire org.
All the people who claim it is awful software, they ignore how many people love the Atlassian suite.
And in addition to that. When you use Saas. Security is a top priority, a Saas provider can't allow to have data of its customers leaked on the web. Whereas once again when it is internal data people will be less cautious
I agree that a lot of Saas startup are going to neglect security. But here we are talking about Knowledge base tools Saas companies. This is not some standard Saas company. They know they are in charge of company internal secrets. Or at lest I hope
I mean right this minute there's a privacy-focused SaaS on the front page for not being as private as everyone thinks. There's also a network hardware vendor on the front page for including back doors. A philosophy like "SaaS vendors know they can't allow security breaches" is really glossing over the need for layers of security and knowing that it's ultimately all on the trustworthiness of specifically who is involved.
I can't disagree with you. But you can either deny that the average Saas is more secure than a forgot Confluence internal servers exposed to the internet
But a big point of hosting it internally is that you don't have to.
That difference would undoubtedly have saved every single company that was affected in the current story.
It was constant a battle of "the critical basic feature you need in this micro version is broken" and other critical functions being hidden in random places.
I applied to their engineering team citing my experience and ability to help with a lot of these things, but never even heard a response.
Current alternative software suites I've seen are beyond terrible or generally non-existent / missing major features. I'm sure there's some "pretty SaaS solutions" out there from a startup that charges exorbitant prices, but I don't believe their back end or security are going to be any better.
Confluence, at it's core, is just a wiki. Sometimes it needs to be available online, sometimes it really doesn't.
You're theoretically more in control of the data, which may be a legal requirement in certain jurisdictions and/or industries.
https://www.zdnet.com/article/whats-actually-in-australias-e...
Legally many of our clients require that their data, all of it, secret or not, reside within the EU.
Currently cloud is not so hot, due to Schrems II. During the last six months we migrate a number of customers on-prem, and only one is building out their stuff in AWS.
There's a fair few reasons other than this, it's not unthinkable to host servers yourself if you already have other servers on-prem anyway.
(This is opposed to the lazy model, where your aplication is fully exposed to the web and you click log in and it redirects to SSO - if there is a vulnerability that doesn't require authentication you're already compromised)
The proxy will handle sign in and passes traffic to/from the webserver backend, and you should not be able to send a single HTTP request to the underlying application without the proxy capturing authentication and who the user that sent the request was.
I had the impression that in a zero trust environment all apps are required to be hardened to the point that they are deemed safe to be exposed to the publc internet.
You may be confusing inbound and outbound proxies. If an inbound proxy is put in front of a server, it is able to be extremely hardened without exposing the webserver, and only allows traffic in extremely limited ways. This frees up the webserver to be more open to the internal network, obfuscates information about the webserver to outsiders, etc.
You may be thinking of an outbound proxy where all of your web requests travel through it in order to provide web filtering, protected DNS, and other protective services to internal endpoints and clients that are already on your network.
A VPN is a much deeper connection than an inbound proxy. It typically requires the external endpoint to be trusted, which is the complete opposite state of an endpoint connecting through an inbound proxy. It then allows the endpoint to operate from a position of trust within the whole internal network. Patches can be updated, endpoints can communicate with each other, and the full network traffic of the endpoint routes through the network. With a VPN you even wind up going through the outbound proxy typically!
YMMV though, not every org is setup exactly like this. I’m making gross generalizations about things. Definitely do some web searches on the differences.
But so that you still can ensure data-locality or run a customised instance e.t.c. if you have requirements around that. Plus licensing is approx. 40% of the full SaaS cost at scale so may be cheaper to deploy that way.
- Cost, VPNs and the hardware to run them can be expensive
- Single point of failure. If you run all your remote access through a VPN gateway then you run the risk of disruption if it goes down. Of course you can implement redundnt/multiple gateways but that increases cost.
- Complexity for B2B setups. If you're exposing an API and you want third party services to access it, it can be more complex if there's a VPN involved.
All that said, I still wouldn't run something like this (or indeed most services) directly on the Internet as it's a single vuln. away from problems, however I've seen plenty of services directly visible on the Internet for these reasons. You can spelunk around one of the search engines like Shodan or Censys to get an idea of how many people run application services directly on the Internet.
I think, unfortunately, what a lot of people take away from "zero trust networks" as a concept is get rid of all bastions/VPNs and firewalls, but that ultimately leads to the topic of this article...
being connected all the time sucks for zoom meetings as the vpn server is on the other side of the continent.
I love having access to most of my work tools outside the vpn - github, confluence, jira, aws console.
Confluence is often where the long-term docs for product/design oriented team members end up living, or at least being linked.
The easy two-way connection between Jira and confluence uses syntax any social media user will be familiar with, so non-techies can link the 'what' with the 'why' in a task before engineers even see them in a grooming session.
Anything that moves documentation and ticket preparation effort away from engineers/tech leads/team leads has a significant hidden saving.
But actually that's not the key point. Nobody buys just Confluence. That would be silly. A bland and terrible (but free) wiki software is definitely better than Confluence.
People buy JIRA. And then you've bought into the Atlassian ecosystem, and you want the nice tight integration with your wiki software
https://www.cvedetails.com/product/8170/Atlassian-Jira.html?...
I would also say based on experience that if they tell you that an exploit can't be used against any of their other software that you shouldn't ever believe them.
https://www.shodan.io/domain/ycombinator.com
At the moment, I think we're checking around 600 million hostnames.
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.
That doesn’t explain what the benefit of the attack is. It just explains that it’s an effective attack.
Access the janitor's account on the facilities Jira, which is all that runs on an old Pentium II in the broom cupboard and you get one set of benefits; access the CFO's on the Big Money Server and you get something else entirely. How on Earth did you manage not to realise this by yourself?