Apache Foundation Attacked, Passwords Stolen 214
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."
obviously advanced Linux users (Score:2, Informative)
Obvious who did it (Score:3, Funny)
Finally - a CowboyNeal option that is the right one!
Re: (Score:3, Funny)
It was the Cowboy attacked Apache.
Finally - a CowboyNeal option that is the right one!
CowboyNeal....in the library....with the machete...
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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....
Re: (Score:2)
That kinda makes sense. But it would make more sense to seek a trojan into a closed source enduser product. Its downloaded more and by less sophisticated users.
Re: (Score:2)
A diff of the code before the attackd (say something one of the admins downloaded beforehand, for whatever reason) and after it would still reveal if anything had been altered during the attack; unless there was a commit just before the attack and none of the admins had yet to download the newer code before the attack.
Re: (Score:2)
The client-side exploit could have been prevented if the software the server was properly sanitizing input data. Most of these XSS holes come from things like login forms pre-populating the username/email field with the previous value if you type your password wrong. Submit "onmouseover="alert(1); as a username/email to check if you have a hole. Evildoers will have that action instead change where the form POSTs to, steal your data, and silently redirect you back to where you had originally intended to go s
Should'a been running IIS! (Score:5, Funny)
Damage contained through one-time passwords. (Score:4, Informative)
Re:Damage contained through one-time passwords. (Score:5, Insightful)
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...
Re: (Score:2)
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.
Re: (Score:2)
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
Re:Damage contained through one-time passwords. (Score:4, Insightful)
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?
Re:Damage contained through one-time passwords. (Score:4, Insightful)
Or upload a trojan into the hosted Apache installers.
Re: (Score:3, Insightful)
Re: (Score:2)
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)
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.
Re: (Score:2)
Serious Question (Score:3)
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)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
I imagine though, that with such an attempt as this, that a freeze on downloads and a code audit would be in order for the next few months.
Re:Serious Question (Score:4, Funny)
My first reaction was that we should set up a huge department level bureaucracy, let's call it the "Department of HTTPD Security" (after the Apache server's process name HTTPD). This department will gets lots of funding and quickly hire many people. Due to the short time period these people will certainly not be the best, or even very good, at security, but this is an emergency so we'll gloss over that. The Department will subsume and take over several other large and already successful security agencies like CERT. From now on any code changes trying to enter or leave Apache or any other of a number of projects will be stopped by the Department, and be forced to be inspected by these inexperienced agents. No code blocks over 3.4K lines will be allowed in. Any archive files will need to be unzipped and displayed for the agent. The Department will also keep a list of first names of programmers who have had security problems and code from anyone matching this list will not be allowed. If any programmer complains about these rules that programmer will also be added to the list. If a programmer even jokes about Apache security or wears a T-Shirt with security exploits on it they will be added to the list.
That was just my first reaction, but then I realized that would be stupid, right?
Re: (Score:3, Insightful)
You really think my reaction is way overblown? So you're saying a code audit shouldn't happen? Maybe a few months is too long but some sort of audit should happen and it should be done by the people who, you know, maintain the actual code.
Take your sarcasm somewhere else. A code audit is not unreasonable given the situation.
Re: (Score:2)
Hahaha defensive much?
Do you see any similarity between my description and any real life over-reactions?
Department of HTTPD Security. D.H.S.
A code audit would be a very good idea.
Re: (Score:2)
How many websites do you know that DON'T run Apache?
Many, many, many e-commerce sites (especially in the mountainous plethora of Windows Shops run... well, you can guess that it's not Apache.
TinyURL Previews (Score:5, Informative)
Turn them on, so you can see where they go.
http://tinyurl.com/preview.php [tinyurl.com]
Re: (Score:2)
Re:TinyURL Previews (Score:5, Funny)
http://joshua.schachter.org/2009/04/on-url-shorteners.html [schachter.org]
And if that URL is too long, try: http://bit.ly/diVyDc [bit.ly]
Re: (Score:3, Interesting)
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.
Re: (Score:3, Funny)
And if that URL just isn't long enough, try here [hugeurl.com].
UntinyFox (Score:2)
This one works: UntinyFox [mozilla.org].
Reading the source, it appears to use this website [alzaid.ws] to convert the URLs.
Respect (Score:5, Insightful)
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)
Re: (Score:2)
Are they starting to salt their hashes? Because that's a very simple step that would have made this breach much less significant.
The Cross-site Scripting FAQ and Resources (Score:2)
http://www.cgisecurity.com/xss-faq.html [cgisecurity.com]
WASC Threat Classification - Cross-site Scripting
http://projects.webappsec.org/Cross-Site+Scripting [webappsec.org]
Injection of vulnerabilities at the source (Score:2)
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
Re: (Score:2)
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.
Interesting attack, but depends on user fail (Score:2)
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...
Re: (Score:2)
But clicking on a link should newer be dangerous, so for this to work there must be a bug in their bugtracking software.
don't be stupid, it's design failure (Score:2)
you can compromise your system by clicking on a link? That is fucked up design.
Re: (Score:3, Insightful)
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?
Re: (Score:2)
every site in the world should have frame busting (Score:4, Interesting)
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
XSS is really hard to eliminate (Score:2, Interesting)
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
Re:Naturally, the passwords were not in clear (Score:5, Informative)
Addendum: Never mind, sorry - unlike the summary implies by "all users" the attack was targeted at capturing passwords from users who logged in while the site was compromised.
Naturally, simple hashing is no protection against that.
Re:Naturally, the passwords were not in clear (Score:5, Informative)
Dear ____________,
You are receiving this email because you have a login, '________', on the Apache JIRA installation, https://issues.apache.org/jira/ [apache.org]
On April 6 the issues.apache.org server was hacked. The attackers were able to install a trojan JIRA login screen and later get full root access:
https://blogs.apache.org/infra/entry/apache_org_04_09_2010
We are assuming that the attackers have a copy of the JIRA database, which includes a hash (SHA-512 unsalted) of the password you set when signing up as '________' to JIRA. If the password you set was not of great quality (eg. based on a dictionary word), it should be assumed that the attackers can guess your password from the password hash via brute force.
The upshot is that someone malicious may know both your email address and a password of yours.
This is a problem because many people reuse passwords across online services. If you reuse passwords across systems, we urge you to change your passwords on ALL SYSTEMS that might be using the compromised JIRA password. Prime examples might be gmail or hotmail accounts, online banking sites, or sites known to be related to your email's domain, gmail.com.
Naturally we would also like you to reset your JIRA password. That can be done at:
https://issues.apache.org/jira/secure/ForgotPassword!default.jspa?username=_________
We (the Apache JIRA administrators) sincerely apologize for this security breach. If you have any questions, please let us know by email. We are also available on the #asfinfra IRC channel on irc.freenode.net.
Regards,
The Apache Infrastructure Team
So, yeah. They were storing the passwords unsalted, which means that it is susceptible to a simple dictionary crack.
Needless to say, I'm quite disgusted with the Apache foundation right now.
Re:Naturally, the passwords were not in clear (Score:4, Informative)
Oh man. This, a day after Atlassian itself got breached:
http://blogs.atlassian.com/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach.html [atlassian.com]
Their fault or not, having their name linked to two breaches in as many days has gotta be unpleasant at best for Atlassian.
Re:Naturally, the passwords were not in clear (Score:4, Interesting)
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.
lite hash better than nothing (Score:2)
This may be a good time to review the "defense in depth" concept; having a quality password can actually help in some circumstances.
Re: (Score:3, Insightful)
Here is the actual e-mail they sent out, which unfortunately, I received:
https://issues.apache.org/jira/secure/ForgotPassword!default.jspa?username=_________
The Apache Infrastructure Team
Since their servers were hacked, how do you know this was from really Apache? Did you click ona link in an email?
Re: (Score:2)
Fair enough. On the other hand, they told you what happened, admitted fault, and clearly explained how this might affect you and what to do about it.
How many organizations would do that? I'm actually impressed.
Re: (Score:2)
All hashes are vulnerable to a simple dictionary attack.
Unsalted hashes are vulnerable to a rainbow table attack (building a table of hashes of all common passwords once, then finding all users with any of those passwords using a simple text match).
Vulnerability to a rainbow table attack is much more serious, particularly since you can download or build up a rainbow table without the password hashes. That means you can immediately apply years of computational time (time you spent generating rainbow tables)
Re: (Score:3, Interesting)
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
Re: (Score:2, Informative)
The passwords were stored as hashes (message-digest or otherwise) with randomized salt, right? I mean, they have a clue about security, surely.
Right?
From the article: "The passwords were encrypted on the compromised servers (SHA-512 hash) but Apache said the risk to simple passwords based on dictionary words "is quite high" and urged users to immediately rotate their passwords."
Re:Naturally, the passwords were not in clear (Score:4, Informative)
After RTFA, yes, the passwords were stored using SHA-512. However, for three days the login form for one of the compromised services was altered, possibly allowing clear-text passwrod grabbing.
Is Apache a valuable target? I'm interested in what people would crack this site for, if not for fun or proof of concept.
Also, inb4 "Ubuntu sucks" or similar trolls. Linux haters would be in here if it were Ubuntu or Red Hat. Netcraft would be trolling if FreeBSD were the host OS. And God Forbid Apache had been using Server 2008.
Re: (Score:3, Insightful)
AFAICT, web servers themselves aren't commonly hacked these days - and indeed that seems to be the case here.
The foolish thing is - and it's downright stupid, make no mistake - while most modern web servers are fairly secure, the same is most definitely not true of the applications and frameworks that commonly run on them. And because it's quite common to find a password for one application works for others (either by a user using the same password or by design, eg. using a common backend such as LDAP), yo
Re: (Score:3, Insightful)
Also, inb4 "Ubuntu sucks" or similar trolls. Linux haters would be in here if it were Ubuntu or Red Hat. Netcraft would be trolling if FreeBSD were the host OS. And God Forbid Apache had been using Server 2008.
Yeah, I'd forsee twice the number of comments by this time if this was IIS with half of them saying "switch to a real OS!!"
Re: (Score:2)
Except that the OS was not compromised, but an application running on top of it.
Re: (Score:2)
Re: (Score:2)
It's like using an IE, Firefox, Flash or Acrobat Reader exploit to compromise a Windows machine.
Ultimately, your security is only as strong as it's weakest link (like having a sophisticated multi-lock system on the door to your house and leaving a window unlocked/open.). If you use a simple password, it is easy to break into any system. If you use an unpatched Operating System, or any of the associated platforms (.NET/MFC/Qt/Flash/...) or applications, you could be open to an exploit.
Attacks like this and m
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I didn't follow the Java one much, but the PDF one quickly devolved into arguments on security models between Linux and Windows.
The ATM malware comments, on the other hand, were heavily anti-Windows even though the culprit was the human element. You've got a person with physcial access and the local admin password. Everything is hosed with that equation if they want to be malicious.
Re: (Score:2)
Re: (Score:2)
The double standard is laughable.
Re: (Score:2)
What's wrong with giving good advice? Sure it would not have been related to the issue at hand, but good advice is good advice.
Re: (Score:2)
As someone who uses Ubuntu on his laptops and workstations, let me just say:
They should've been using a real OS.
I mean, seriously. Ubuntu on a server? Yeah, it's great and all, but it doesn't get a whole lot of scrutiny for security.
Re: (Score:2, Interesting)
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?
Re: (Score:2)
Re: (Score:2)
SHA-256 is, in theory, totally crackable for up to eight characters or so. The FRT project has SHA1 rainbow tables up to around that length. I was not able to find any SHA-256 tables, though. Anyone in the business of password cracking likely has private rainbow tables for all of the common hash algos.
See the currently-available public rainbow tables here:
http://freerainbowtables.mirror.garr.it/mirrors/freerainbowtables/ [mirror.garr.it]
Re: (Score:2)
After RTFA, yes, the passwords were stored using SHA-512. However, for three days the login form for one of the compromised services was altered, possibly allowing clear-text passwrod grabbing.
Is Apache a valuable target? I'm interested in what people would crack this site for, if not for fun or proof of concept.
Also, inb4 "Ubuntu sucks" or similar trolls. Linux haters would be in here if it were Ubuntu or Red Hat. Netcraft would be trolling if FreeBSD were the host OS. And God Forbid Apache had been using Server 2008.
I am not sure either, the only possible value is to inject code, but even that is quite hard since every commit is sent through mailing lists so that the committer usually might be aware of third party commits under his name.
My personal guess is that it just was for 'fun' but for doing it for 'fun' involved a lot of work over several days with questionable results aka, nothing to be gained, since there are not trade secrets and everything can be downloaded anyway.
But on the other hand some people justify th
Re: (Score:2)
I'm an idiot. They were stored in SHA-512 hashes, since they were passwords for JIRA, but the likelihood of the passwords breaking on a dictionary attack is apparently high.
It's high because they chose to store the hashes unsalted. Not a good move.,
Re:Naturally, the passwords were not in clear (Score:4, Interesting)
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.
Re: (Score:2)
People who still use http's basic auth need to be slapped. There's little reason not to use digest.
That said, only .htpasswd seems to ever be cleartext. If you save them in a database (and anything as "large" as JIRA would do so) then they are usually hashed at least. Why unsalted, I don't know.
Re: (Score:2)
TLS + anything is superior in everything but CPU usage.
I personally think the web would be a better place if TLS (or at least SSL) was "standard" (ie, used in place of regular HTTP)
Re: (Score:2, Informative)
Re: (Score:2)
It's just funny, to me, that the tone here is very moderate, calm, and perhaps even lightly defensive.
If this same thing happened on an IIS box, we'd have a flood of comments of 'get a real OS!' regardless of how off target those shouts would be. It's just the nature of the beast.
Re: (Score:2)
From what i'm reading it could have happened to a IIS box in the exact same way.. the webserver didn't do anything wrong, nor the OS. Javascript (guessing) was used to steal a session cookie. So we could say the Browser (or lack of no-script plugin) is to blame.
Re: (Score:2)
Re: (Score:2)
But even then the commits are sent through an email system so if there is an attack to inject code one of those attemts end up being becoming public, the next thing you can be aware of is that every committer will check his own commits back in the history to the date of the compromise and if needed will pull his code.
So there is a double layer of security involved.
Re: (Score:2)
I would think that a network administrator would know better than to use his root password for his company's network for anybody else's site. Any net admin that did that isn't very good at his job.
Re:lols (Score:5, Funny)
Hey, this is serious! These hackers might have access to the full source code for Apache. Now they can craft specially targeted attacks against most web servers - no longer does Apache have that advantage over the leaked Windows source code. A terrible day for security on the web.
Re: (Score:3, Funny)
Re: (Score:2, Funny)
Do you mean the source code for the Apache web server itself? Hasn't that always been available? Since when has it been a closed source product like IIS?
Oh, hand on a sec, there's sarcasm here?
Re:lols (Score:4, Funny)
Re: (Score:2)
No kidding. While I've only had limited experience with Ubuntu, I can tell it's not server grade. It's made for the n00b crowd who want Linux without the hassle.
Re: (Score:2)
Re: (Score:2)
In my opinion and in this specific case: No, they cannot.
Ubuntu, from my own experiences and from everything I've read, is meant to be a beginner level distro. Sure you could use it as a server, but you can also use Windows as a server. Doesn't make it a good choice.
Re: (Score:2)
Re: (Score:2)
Do you have anything more substantial behind that reasoning?
The Ubuntu Server Edition is basically just Debian with Postfix instead of Exim, and more support from commercial software packages (eg VMWare etc).
Another notable difference (and possible advantage for some users) is that Ubuntu has defined
Re: (Score:2)
A distro that accounts for your needs. The bias is in your head. You shouldn't use DSL to run a server. That is one example of improper distro selection. You shouldn't run Hardened Linux on your kids netbook. Thats another.
All the other meanings to my words where given to you
Re: (Score:2)
Oh hey. A fully patched default installation of Ubuntu stood up next to Mac OS X and Windows Vista.
Doesn't say anything about using it as a server.
Re: (Score:3, Insightful)
Sorry, but that distinction has long since been lost... if it was ever popular to begin with. These days we have good hackers and we have evil hackers.
Re: (Score:2)
If you talk to most people about XSS issues, there's something hard-wired in our brains to shut them off after about
TL;DR