Apache Foundation Attacked, Passwords Stolen

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."

Comments

Re:Naturally, the passwords were not in clear

[Arancaytar]

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.

Should'a been running IIS!

[Kenja]

cause that would have confused the hell out of the attackers.

Re:Naturally, the passwords were not in clear

[Luke has no name]

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.

Damage contained through one-time passwords.

[helixcode123]

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.

Re:Damage contained through one-time passwords.

[HogGeek]

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:Damage contained through one-time passwords.

[jimicus]

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.

[gad_zuki!]

Or upload a trojan into the hosted Apache installers.

TinyURL Previews

[The MAZZTer]

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

http://tinyurl.com/preview.php

Re:TinyURL Previews

[Stradenko]

http://joshua.schachter.org/2009/04/on-url-shorteners.html

And if that URL is too long, try: http://bit.ly/diVyDc

Respect

[Xacid]

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:lols

[lgw]

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:Naturally, the passwords were not in clear

[not already in use]

Here is the actual e-mail they sent out, which unfortunately, I received:

Dear ____________,

You are receiving this email because you have a login, '________', on the Apache JIRA installation, https://issues.apache.org/jira/

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:lols

[Pharago]

they just couldn't figure out how to access subversion so they got the code thru some more entertaining ways

Re:Naturally, the passwords were not in clear

[Sorthum]

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

Their fault or not, having their name linked to two breaches in as many days has gotta be unpleasant at best for Atlassian.

Re:Serious Question

[hoggoth]

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:Naturally, the passwords were not in clear

[bark]

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.

every site in the world should have frame busting

[circletimessquare]

http://en.wikipedia.org/wiki/Framekiller

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

Re:Naturally, the passwords were not in clear

[Firehed]

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:lols

[TheRaven64]

He uses Gentoo. He's installed the words, but the grammar is still compiling.