Backdoor Discovered In Atlassian Crowd 133
An anonymous reader writes "Recently published on the Command Five website is a technically detailed threat advisory (PDF) in relation to a recurring vulnerability in Atlassian Crowd. Tucked away inconspicuously at the end of this document in a section entitled 'Unpatched Vulnerabilities' is the real security bombshell: Atlassian's turnkey solution for enterprise single sign-on and secure user authentication contains an unpatched backdoor. The backdoor allows anyone to remotely take full control of a Crowd server and, according to Command Five, successful exploitation 'invariably' results in compromise of all application and user credentials as well as accessible data storage, configured directories (for example Active Directory), and dependent systems."
Huh? (Score:5, Interesting)
What is Atlassian Crowd, where is it used, how does this effect me, why should I care?
Did I miss any important questions?
Not surprising (Score:5, Interesting)
Atlassian has absolute contempt for their paying customers. Each release of JIRA has functionality and flexibility that people actually want removed in the name of making it easier to use for new users. JIRA and Crucible use some monstrosity of JavaScript that causes lag when typing into intput fields, and certain versions clash with Ghostery in a way that causes certain characters (e.g. spaces) to be swallowed. It's sad, but it doesn't surprise me at all that they don't care about security in an authentication system.
Commercial Trash (Score:4, Interesting)
Unless it starts to really, really hurt selling this kind of trash, not fixing _known_ vulnerabilities and not using secure coding practices, nothing will change. It is just cheaper this way and most customers do not care or cannot do anything anyways. One reason surely is managers at the customers that made this broken decision or supported it and now cannot back out without hurting themselves. Another is that absolutely nothing is going to happen to the vendor legally.
Unless we start to require sound secure software engineering practices OR ELSE! nothing will change.
Re:Not surprising (Score:5, Interesting)
It may be a factor of whether you're talking as a user or as an administrator.
I can't speak authoritatively to JIRA as a product I'm responsible for -- I never owned a JIRA installation (well, not one with significant volume) -- but I use JIRA, and we use JIRA here, for a whole crapton of things from change tickets to production emergency handling, to task handling, to all development tasks. As a software engineer, and a software engineering manager, I love it -- and so do most of the other users we have here.
It helps that we think of this kind of stuff as something you should actually invest in, and we have someone who probably has about 50% of his time dedicated to making JIRA run and making it work better for us. I've always found that bug/defect/issue/task tracking systems are better, and make their users happier, when they have a champion who's allowed to invest real resources in their care and feeding.
Re: Huh? (Score:4, Interesting)
Actually you can hook Jira into Stash, which is a GIT repo server, hook that into FishEye/Crucible which is a code review portal and hooked into Jenkins, thereby creating a nearly round trip QA process.
QA creates a ticket, developer sees ticket, creates a branch from it, commits code, gets peer review after which the code is deployed to a QA server, ticket is moved back to a QA user who has a link to the QA server (typically a unique server instance is spun up for each ticket), QA confirms - this spins down the QA server instance and a pull request is made for the production branch.
So there you go. Automated code deployment with useful checkpoints in a workflow process.
Don't be jealous.