Complete Story

Thanks to Slashdot for covering this.

Things like this are also a prime reason to never use the same password on two websites. Use a password safe people, unique complex passwords for every site.

(Keepass is pretty full featured if you're unfamiliar with with password safes)

2 members found this post helpful.

nice ownage. but they misuse "hacker" term again :'(

Thanks for posting. While the web log post is good I recommend reading http://blogs.apache.org/infra/entry/...org_04_09_2010 instead and http://avatraxiom.livejournal.com/102080.html for a short list of of security tips.

1 members found this post helpful.

Awesome! Thanks!

SeLinux in this case could prevent a lot of damage. Did they use it ... ? I cannot find anywhere in commnets that it was used.

SELinux in this case would have prevented nothing so far as i can see by reading the actual account. I'm interested in see your explanation of what it would have prevented and how.

Since sarajevo has not responded and since you are likely to have more knowledge of SE Linux compared to him, maybe could you come up with one example of where SE Linux could have helped if it were enabled and running in the standard "targeted" configuration? If you would be willing to (thanks!) then to make it easier let's assert the JIRA admin account they gained access to does not equal a root account.

I too, would like to see such an explanation ... I doubt anyone will be able to give one tho.

There are areas that SE Linux could have helped. To apply that to this case however requires a lot of ifs and buts because the case shows some errors. This type of error no software can hope to defend against (human errors I mean).

That about sums it up. There are instances where both selinux and apparmor could prevent additional exploits (although reading the article didn't indicate that this particular breach would be one of those), but it can't save you from yourself. No admin is perfect, but having all the security fronts covered that you can reduces the probability of a catastrophic system compromise and sometimes enable you to find a potential security issue before an external entity does.

I wasn't thinking of additional exploits but actual parts of the breach process. Now I don't like guesswork or assumptions as a foundation for explaining things but if I strain myself and assert that 0) JIRA admin does not equal root and 1) daemon processes run in the JIRA context, then there's at least three points I can think of right now:
- changing the upload attachment path (right after bruting login.jsp got them JIRA admin access) wouldn't allow access outside of the JIRA context,
- browsing the file system (after uploading the JSP filesystem browser) wouldn't be possible outside of the JIRA context,
- running the JSP backdoor wouldn't be allowed to bind to a port that isn't in the allowed list of ports for the JIRA context.
It's hypothetical, minor fersure and maybe insignificant as well and it could only have slowed down progress if they didn't have a backup plan and tools in place but at least I came up with something instead of elaborating on the human error part which aspect I already did cover.

1 members found this post helpful.

I was reading this article recently that found human error or the human factor to be the weakest link in any security scheme. You can have all the technology you want to try to secure yourself, but if you don't know what you're doing or how to use it, it won't do you much good. This actually applies to numerous fields, even medicine, engineering, etc. The most sophisticated technology can't make up for human stupidity or carelessness or lack of understanding.

1 members found this post helpful.

Nice explanation. Thanks.

When I wrote above that SeLinux could help to prevent more damage, I thought in case there was ( ??? ) selinux enabled on system, it would prevent compromised user ( JIRA admin ) to read files at rest of system ( unless JIRA admin==root )
But all this unSpawn already wrote above.