Forgot your password?

typodupeerror
Security Open Source Ubuntu Apache

Apache Foundation Attacked, Passwords Stolen 214

Posted by CmdrTaco
from the yeah-we-meant-to-do-that dept.
Trailrunner7 writes "Combining a cross-site scripting (XSS) vulnerability with a TinyURL redirect, hackers successfully broke into the infrastructure for the open-source Apache Foundation in what is being described as a 'direct, targeted attack.' The hackers hit the server hosting the software that Apache.org uses to track issues and requests and stole passwords from all users. The software was hosted on brutus.apache.org, a machine running Ubuntu Linux 8.04 LTS, the group said."
This discussion has been archived. No new comments can be posted.

Apache Foundation Attacked, Passwords Stolen

Comments Filter:
  • by Anonymous Coward on Tuesday April 13 2010, @12:59PM (#31834294)

    The host OS doesn't even enter in to it. They exploited JIRA, which is in Java, to steal cookies from the user via a XSS attack, which they used to steal an admin account and then they used that to install a plugin which overrode the standard login facilty. JIRA could probably have used some hardening, but frankly I suspect the security of nearly every bug tracker is pretty suspect.

    I wonder if NoScript's XSS blocker would have foiled it?

  • It's not like it's Citibank.

    Lots of professional developers who work for other companies also contribute to open source. Some of them might be in the habit of reusing the same password in various locations, or use passwords that give a clue as to how they might generate them in a less than secure fashion. Its not a smart thing to reuse passwords but it happens. Now the attackers might have leads on how to get into more valuable targets.

  • by Anonymous Coward on Tuesday April 13 2010, @01:45PM (#31835234)

    If you talk to most people about XSS issues, there's something hard-wired in our brains to shut them off after about 12 seconds. Apparently even experts can get caught off-guard. So I'll try to keep this short.

    When you're signed into a website, avoid doing anything Internet-related other than to interact with that website. This includes checking your e-mail or instant messaging, even if you're using other software to do those things. When you're done with that website, sign out and close your web browser (obviously, restart your web browser after if you want to do more web browsing.)

    Also, configure your web browser to remove your cookies at the end of each session. This is inconvenient if you're used to having websites recognize you for a month or so without having to login, but allows you to effectively "logout" of everything by simply closing your web browser. You can set this behavior to default in Firefox (and probably all other current web browsers) and override it for specific websites if you really want to preserve this functionality for Slashdot while making yourself more secure for online banking websites.

    Sorry if this happens to be rookie stuff for you, but there are a lot of people who don't understand XSS attacks and shouldn't have to in order to operate safely on the Internet. And this doesn't even get into the PDF exploits and other crap that's happily bypassing antivirus scanners now...

  • by bark (582535) on Tuesday April 13 2010, @01:53PM (#31835422)

    If you read the article, the Apache folks were compromised before the Atlassian breach - and in the article, it appears Apache contacted Atlassian regarding the xss compromise which was used 2 days later directly on atlassian itself.

  • http://en.wikipedia.org/wiki/Framekiller [wikipedia.org]

    one line of code:

    top.location.replace(self.location.href);

    put it in every page you ever publish on the web

    it's not 100% foolproof, nothing is

    but it's so little effort for protection from an important kind of xss attack

  • by Firehed (942385) on Tuesday April 13 2010, @02:44PM (#31836500) Homepage

    And TFS said that passwords were stolen via an XSS exploit. You could be storing passwords on the server with some sort of quantum solution and still be screwed, because the passwords are stolen before they hit the server.

    Sounds like there's two stages here though. Get admin access via logging passwords with the XSS exploit, and then get at the DB and do whatever the hell they want. Even if you have XSS vulnerabilities (and they're terribly common), admins should still know better than to login through a tinyurl link, since that's now one of the easiest ways for a malicious user to get a vulnerability on the page.

    That said, storing unsalted hashes is still abysmally stupid.

  • by not already in use (972294) on Tuesday April 13 2010, @02:46PM (#31836534)

    And how does a salt help when they can get the salt?

    Well, they'd have to generate a new hash-table using the specific hash, which at the very least is an extremely time consuming effort that puts up another potential roadblock in getting a whole shit load of user's passwords.

    Now, if you do not do this you would be 100% safe :)

    Wrong. All they need is your email password and then can reset or get user names for any other accounts you have. What is important, however, is that your email password is entirely unique and extremely strong.

    If you do this, you should be disgusted at *yourself* first. Then at the attackers. Then at the altasian for making software susceptible to this (they made the hash as it is in the DB, not Apache).

    Wrong again. I'm not disgusted in myself since my password is certainly not common enough to be cracked by a precalculated hash-table.

  • by Anonymous Coward on Tuesday April 13 2010, @03:59PM (#31837920)

    Every big and famous webapp had, and has, XSS holes, period. It doesn't matter how smart they are.

    Wouldn't you say that Slashdot should be very safe? For it must have been under a lot of attacks, and all the xss holes must have been discovered and fixed.

    I spent a few minutes looking around and I found one already. I'll publish it here right now for your amusement, I don't think real damages can be caused before the hole is closed.

    The Password/Claim OpenID form has no XSRF protection. It also works with GET method which makes it even sweeter. If a slashdot user's browser fetches this URL (trick him to click it; or more sinisterly, use it in a img src)

    http://slashdot.org/login.pl?openid_url=http://evil.openid.server.com/&op=claim_openid [slashdot.org]

    his slashdot account will be linked to an openid without him knowing it. The attacker can then log into the account with the openid, game over.

    Now let's point to CmdrTaco and laugh.

  • Re:TinyURL Previews (Score:3, Interesting)

    by Hurricane78 (562437) <deleted@nOSpAM.slashdot.org> on Tuesday April 13 2010, @07:06PM (#31840094)

    Pff, way too long. Just input this into firefox:
    to./3n4d [to.]

    Yes, that’s right. A TLD url shortener. The http: // is only needed for <a href="...">s or IE.

Only the hypocrite is really rotten to the core. -- Hannah Arendt

Working...