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
    "The attack was crafted to steal the session cookie from the user logged-in to JIRA. When this issue was opened against the Infrastructure team, several of our administators clicked on the link. This compromised their sessions, including their JIRA administrator rights"
  • by tomhudson (43916) <barbara.hudson@ ... a - h u dson.com> on Tuesday April 13, 2010 @12:33PM (#31833796) Journal
    It was the Cowboy attacked Apache.

    Finally - a CowboyNeal option that is the right one!

    • Re: (Score:3, Funny)

      by Bobfrankly1 (1043848)

      It was the Cowboy attacked Apache.

      Finally - a CowboyNeal option that is the right one!

      CowboyNeal....in the library....with the machete...

    • by middlemen (765373)
      Obligatory: Microsoft did it to prove that IIS is more secure.
      • by hey (83763)

        Well, its possible. With lots of indirection via Russia probably. Who has the most to gain? There is no need to steal Apache's code since its already available.

        • by Korin43 (881732)

          There is no need to steal Apache's code since its already available.

          They didn't steal the code, they stole a bunch of passwords.

          • Which really doesn't make any sense, though if it's passwords the users use in combination with the same login name and email address....

  • by Kenja (541830) on Tuesday April 13, 2010 @12:36PM (#31833848)
    cause that would have confused the hell out of the attackers.
  • by helixcode123 (514493) on Tuesday April 13, 2010 @12:39PM (#31833908) Homepage Journal
    FTFA: Apache said the use of one-time passwords was a "lifesaver" because it limited the damage and stopped the attack from spreading to other services/hosts. Nice that the damage was contained. What would be the motivation(s) for hacking Apache, anyway? It's not like it's Citibank.
    • by HogGeek (456673) on Tuesday April 13, 2010 @12:43PM (#31833986)

      Hmm, let's see:

      Implanting a back door in any one (if not all) of the Apache products, so that when Citibank does an upgrade...

      Far fetched, yes. But not out of the realm of possibility...

      • by chrb (1083577)

        Implanting a back door in any one (if not all) of the Apache products

        It would be very difficult to hide such a backdoor effectively in a high-profile open source product like Apache.

      • That's not at all far-fetched. Organized crime currently operates by attempting to get malware on machines in banks and businesses used for wire transfers, then wiring that money away. But to get the malware inside an organization in the first place, they have to trick the users into clicking something dumb (in email, IM, or web ads).

        If they could get backdoors in common internet-exposed applications (like apache or postifx, say), they would have immediate access into a large percentage of orgs without havi

    • by jimicus (737525) on Tuesday April 13, 2010 @01:03PM (#31834372)

      I can think of a couple.

      It's a very prestigious target (if you're the sort that would do this for some sort of prestige). It's also a poster-child for a solid OSS product - what better way to spread FUD?

      • by gad_zuki! (70830) on Tuesday April 13, 2010 @02:12PM (#31835868)

        Or upload a trojan into the hosted Apache installers.

      • Re: (Score:3, Insightful)

        by Yvanhoe (564877)
        Actually while I ackowledge Apache's response was adequate, isn't it worrying that such a thing can happen ?
        • by jimicus (737525)

          Worrying? Possibly.

          Surprising? Not at all. I've been sure in my own mind for some time that the risk these days comes from the application you run on the web server, rather than the web server itself. About the best you can do is lock down everything to buggery so that any impact can be minimised. From TFA, it sounds like the Apache people had done quite a bit to reduce the impact but there were a few things overlooked.

    • Re: (Score:3, Interesting)

      by Jherico (39763)

      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 houghi (78078)

      Because they can?

  • by Dr. Evil (3501) on Tuesday April 13, 2010 @12:42PM (#31833954)

    Does anyone have any thoughts as to why Apache would be targeted like this?

    Apache doesn't exactly garner bad blood from shady groups. Big corporations and governments have too much to lose by attacking Apache this way. I could understand an attempt by organized crime or a blackhat organization to secretly insert a back door into the Apache code base, but this was too heavy-handed to even consider being a secret attempt.

    The whole thing is weird.

    • Re: (Score:3, Insightful)

      by c1ay (703047)
      Maybe it was simply for the sake of practice and some other site with a similar setup is the real future target....just food for thought.
    • Yeah - other than the passwords, an OSS foundation doesn't really have any secrets to steal. However, how disciplined is the average person about password hygiene? These passwords will grant access to many accounts in many places, compromising emails, systems and possibly other large user databases via admin accounts.

    • by dkleinsc (563838)

      Big corporations and governments have too much to lose by attacking Apache this way.

      Only if they get caught. And it's not like I can't think of somebody who might be interested in eMbarraSsing the Apache Foundation.

    • by CAIMLAS (41445)

      Biggest competitor to Apache out there is Microsoft, as I see it. They're pushing Sharepoint hard, and Apache is the foundation of their competition.

      A lot of government entities (US and otherwise) could also benefit, though if it's been detected I'd guess it was somewhat more amateur than that.

  • TinyURL Previews (Score:5, Informative)

    by The MAZZTer (911996) <[moc.liamg] [ta] [tzzagem]> on Tuesday April 13, 2010 @12:42PM (#31833968) Homepage

    Turn them on, so you can see where they go.

    http://tinyurl.com/preview.php [tinyurl.com]

  • Respect (Score:5, Insightful)

    by Xacid (560407) on Tuesday April 13, 2010 @12:43PM (#31833984) Journal

    Nothing but absolute respect for how Apache is handling this. Were there issues that became apparent as a result of this? Yes. But have they discovered the flaws, acknowledged them, and are looking to close those holes? Yes.

    It's a shame more companies can't operate with such...transparency I guess you'd call it. However, consumers respond differently to different types of companies.

    I, for one, am proud to see a company take this seriously instead of trying to sweep it under the rug.

    • Re: (Score:3, Informative)

      by Lisandro (799651)
      Apache is a foundation, not a company. I otherwise agree - they handled this really well in my opinion.
    • by wurp (51446)

      Are they starting to salt their hashes? Because that's a very simple step that would have made this breach much less significant.

  • XSS FAQ
    http://www.cgisecurity.com/xss-faq.html [cgisecurity.com]

    WASC Threat Classification - Cross-site Scripting
    http://projects.webappsec.org/Cross-Site+Scripting [webappsec.org]
  • A potential aim of getting these specific passwords would be to be able to use those user's identification credentials have custom crafted vulnerabilities at the source level checked-in into Source Control in one or more any of the Apache applications and frameworks (not just the Apache Web server but things like modules and language frameworks and libraries).

    Certainly for state actors engaging in cyber-war, having their own backdoors in things like the Apache Webserver would be invaluable. They also have t

    • by sowth (748135) *

      You need more than that. Continuous code auditing is needed. You never know when a person has been compromised. Maybe they got paid lots of money, or maybe they are the member of an extremist group.

      There is also the possibility of a password being stolen, and you don't find out about it. A smart attacker could just make small subtle changes so they aren't discovered.

      These guys seemed to be going for the brute force push through on everything. Which is why they were caught.

  • FTA:

    On April 5th, the attackers via a compromised Slicehost server opened a new issue, INFRA-2591. This issue contained the following text:
    ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX [tinyurl.com] [obscured]...This specific URL redirected back to the Apache instance of JIRA, at a special URL containing a cross site scripting (XSS) attack. The attack was crafted to steal the session cookie from the user logged-in to JIRA. When this issue was opened against the Infrastructure team, several of our administators clicked on the link. This compromised their sessions, including their JIRA administrator rights.

    Oops...check those URLs, admins...

    • by TheSunborn (68004)

      But clicking on a link should newer be dangerous, so for this to work there must be a bug in their bugtracking software.

    • you can compromise your system by clicking on a link? That is fucked up design.

      • Re: (Score:3, Insightful)

        by Bearhouse (1034238)

        ..design failure..

        Of course it is - one shared (at some point in time), by all browsers, amongst other software.
        That's why it's "stupid" to trust your systems 100%
        You yourself don't have a quick look at a link, especially one from an unknown source, before blithely clicking?
        Especially if you're logged on with root or admin rights?

  • 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 Anonymous Coward

    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

"Marriage is like a cage; one sees the birds outside desperate to get in, and those inside desperate to get out." -- Montaigne

Working...