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

obviously advanced Linux users

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

Naturally, the passwords were not in clear

[Arancaytar]

The passwords were stored as hashes (message-digest or otherwise) with randomized salt, right? I mean, they have a clue about security, surely.

Right?

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.

Re:Naturally, the passwords were not in clear

[King InuYasha]

With passwords for HTTP[S], normally they are stored entirely in plaintext. So, no. Probably the Apache Foundation will wipe all the passwords and require a total reset of brutus.apache.org

Re:Naturally, the passwords were not in clear

[FallinWithStyle]

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

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

Re:Naturally, the passwords were not in clear

[Anonymous Coward]

The passwords were stored as hashes (message-digest or otherwise) with randomized salt, right? I mean, they have a clue about security, surely.

Right?

The message from Apache says that simple-dictionary passwords are most vulnerable, which indicates that a brute-force attack is still required to get a password (but brute-forcing dictionary words is easy). So it's clearly not plaintext, and it's also clearly salted or there would be no difference in difficulty obtaining different complexities of passwords via rainbow table lookups. So yes, they seem to have at least some clue about secrity.

The worst part is that the attackers intercepted and logged passwords for a brief period, while the attack was underway.

Re:Naturally, the passwords were not in clear

[King InuYasha]

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.

And they also logged passwords with a fake login page, so protections like that are pretty much void...

So, meh... It's my fault for not reading the article... When will I learn? :P

Re:Naturally, the passwords were not in clear

[Ivan Stepaniuk]

Normally where? there is no such a thing as passwords for HTTP in the first place. If you are speaking about simple HTTP authentication, the Apache httpd does not even accept plaintext .htpasswd files on Linux (it does when running on Windows, Netware or TPF, read the htpasswd man page). Other types of authentication rely on a wide diversity of different password storage backends and -normally- they do not store the plaintext password but at least an MD5 hash. In any case, modifying the script or cgi where the login form points to is trivial, that way you can get user's passwords as they log in.

Re:Naturally, the passwords were not in clear

[jimicus]

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), you only need one stupid application which doesn't take countermeasures against brute-force attacks and doesn't log failed logins (making fail2ban ineffective) and the whole damn lot is cracked open.

Re:Naturally, the passwords were not in clear

[Volante3192]

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

[Anonymous Coward]

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

[tibit]

Now, who want to bet that if those hackers would just run email/password or firstlast/password combinations against major online banking websites, they'd get quite a few hits? This is kinda serious, and precisely the reason I stopped using common passwords and just use a fresh keepassx-generated password for everything.

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

[AndGodSed]

Except that the OS was not compromised, but an application running on top of it.

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.

Re:Naturally, the passwords were not in clear

[EsbenMoseHansen]

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

[X0563511]

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

[Beelzebud]

I'll have to remember that one.

Re:Naturally, the passwords were not in clear

[Anonymous Coward]

And how does a salt help when they can get the salt? (see, full root access). It may only help in preventing use of pre-calculated hash tables, but that's for only very weak passwords.

This is a problem because many people reuse passwords across online services

Needless to say, I'm quite disgusted with the Apache foundation right now.

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

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

But then again you may be disgusted at Apache for informing you about this, because you prefer ignorance instead?

Re:Naturally, the passwords were not in clear

[h4rr4r]

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

[carp3_noct3m]

They key is in the press release. When they talk about how many users reuse password across systems. A large database with passwords and emails will have (yes i'm making it up) probably at least 25% of them using the same password for their email, and then once you have access to email, often that is the key to the kingdom so to speak.

Re:Naturally, the passwords were not in clear

[Lord Ender]

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/

Re:Naturally, the passwords were not in clear

[Anonymous Coward]

If someone can edit the Apache source tree without being detected and insert some subtle method of a backdoor (something far more subtle than this where uid=0 is in the code when uid==0 is meant), that would mean a LOT of money for the blackhat group, because so many Web servers run Apache that selling a possible backdoor to so many sites would be very lucrative, now, and years to come, as a hole put in now may allow for more targeted attacks in the future.

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

[not already in use]

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.

Re:Naturally, the passwords were not in clear

[MemoryDragon]

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 their existence due to being destructive, so for many this is motivation enough.

Re:Naturally, the passwords were not in clear

[Anonymous Coward]

Why are you disgusted with the Apache foundation? For not salting the passwords? Would that have helped that much to prevent a dictionary crack, and wouldnt the salt be known since they rooted the box?

Re:Naturally, the passwords were not in clear

[CAIMLAS]

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

[Anonymous Coward]

unsalted pws bad, but it is no biggie if you don't reuse!

Re:Naturally, the passwords were not in clear

[msclrhd]

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 malware are becoming increasingly more sophisticated. Look at conficker for example -- that actively blocked you from browsing to security websites and killed processes that were installing updates to patch the machine or to remove conficker.

Re:Naturally, the passwords were not in clear

[Mister Whirly]

When has that ever stopped that rabid anti-MS slashdot crowd from blaming Microsoft when the same exact situation happens with a third party application on Windows?

Re:Naturally, the passwords were not in clear

[pthreadunixman]

If you use digest auth, you must store the passwords in either clear text or at least with a reversible cipher. You can calculate the digest using a hash, but then the hash itself becomes the clear text password which makes little sense. With digest your trading secrecy on the backend for secrecy on the wire. TLS + basic is superior IMO.

Re:Naturally, the passwords were not in clear

[Anonymous Coward]

What are you disgusted with Apache for?

That a product they used (Jira) stored passwords as unsalted hash?

That you used a simple dictionary password?

That you use this simple dictionary password on multiple sites?

That you'll have to explain to someone that your work password may have been compromised due to password re-use?

That its even more embarrassing for you than it is for Apache?

hugs and kisses,

anonymous coward

Re:Naturally, the passwords were not in clear

[Smallpond]

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

[Beelzebud]

Never. If an attack like this happened on a machine running an MS OS you'd be laughed off this site for saying "the OS was not compromised, but an application running on top of it".

The double standard is laughable.

Re:Naturally, the passwords were not in clear

[Beelzebud]

All I know is that if this attack had occurred on a machine running an MS OS, it would not be given the benefit of the doubt around here. The next time a breach of this magnitude happens on a machine with Windows installed, try to use the same excuse and see where it gets you. If you said "the OS was not compromised, but an application running on top of it" you'd be tarred and feathered.

Re:Naturally, the passwords were not in clear

[Nerdposeur]

Needless to say, I'm quite disgusted with the Apache foundation right now.

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

[debatem1]

Looking over the last few dozen " was pwned" threads seems to dispute this. The recent Java exploit thread has (AFAICS) about 3 references (out of hundreds) to windows, despite it being a windows-only problem. The very first post on the PDF exploit thread is entitled "Linux is vulnerable too". Others are similar in content for the most part, and last I recall the Debian team wasn't spared any guff for their SSL fuckup. You might just be a little oversensitive to the issue.

Re:Naturally, the passwords were not in clear

[X0563511]

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

[Volante3192]

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

[wurp]

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) to each database of unsalted hashes you come across.

Re:Naturally, the passwords were not in clear

[BikeHelmet]

Needless to say, I'm quite disgusted with the Apache foundation right now.

At least it wasn't stored plain text!

Re:Naturally, the passwords were not in clear

[socceroos]

Honestly, did you even read TFS? This attack has nothing to do with Ubuntu's security, its all about an XSS attack with some TinyURL in the mix.

Re:Naturally, the passwords were not in clear

[Anonymous Coward]

So, yeah. They were storing the passwords unsalted, which means that it is susceptible to a simple dictionary crack.

Are you reading the same notice as me? If the passwords were unsalted, then password complexity would be irrelevant--a simple rainbow table lookup cracks them all. The fact that they simple dictionary words are MORE susceptible means that the passwords are going to need to be individually cracked by brute force, which means they are salted. Which means, aside from the security breach itself, they did their jobs well.

Re:Naturally, the passwords were not in clear

[darkpixel2k]

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.

GPGAuth would have prevented that. Never send your password over the internet again. Receive random garbled encrypted data, decrypt it, re-encrypt it, and send it back.

If 'they' compromise the site, they still don't get your password.

Re:Naturally, the passwords were not in clear

[darkpixel2k]

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.

Why? You're not using the same password on multiple services, right? That would be *as* or even *more* retarded then ASF storing your passwords without a salt...

Re:Naturally, the passwords were not in clear

[Nyder]

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.

If they ran AmigaOS they'd be okay.

Re:Naturally, the passwords were not in clear

[m0i]

Hrm, so they got caught by phishing using a fake Forgot Password form, and they send the exact same password reset request in their break-in acknowledgement? D'oh! It could well be another phishing attempt :-)
+1 for personnal certificates stored on tokens. -1 for one time passwords. -100 for reused passwords (special mention for 'online banking').

Re:Naturally, the passwords were not in clear

[AndGodSed]

This is slashdot. Double standards are the standard. You must be an ms fanboi for pointing that out.

Re:Naturally, the passwords were not in clear

[Anonymous Coward]

Not familiar with JIRA internals, but do the admins have any control over how JIRA stores passwords?

With regards to simple dictionary crack, even if you use a salt, you must still take care where you store it, how you store it and how you use it for the salt to be truly effective.

Re:Naturally, the passwords were not in clear

[Shompol]

Majority of web services store passwords unencrypted, and email them to me when i forget password (!). Not to mention if someone hacks them they will be quiet about it. I'd say Apache foundation is still top notch compared to most.

Re:Naturally, the passwords were not in clear

[plague3106]

Why unsalted, I don't know.

Gah, always needing to add salt. Typical American, don't you care about your heart??

Re:Naturally, the passwords were not in clear

[Anonymous Coward]

After RTFA, yes, the passwords were stored using SHA-512.

But they didn't salt the passwords first, which is a pretty bizarre move. Salting completely removes the benefit of rainbow tables, which are the big danger if they grabbed the whole database. Salting is brain dead easy to implement and costs essentially no extra resources while working, so not having it is a sign of potentially poor design.

Re:Naturally, the passwords were not in clear

[Arancaytar]

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

The salt is not intended to remain any more secret than the hash itself. It also is not designed to ensure security in spite of a breach, just limit the consequences (much like password aging).

Dictionary attacks become disproportionally, infeasibly expensive with a known salt.

Instead of looking for the hash in a pregenerated dictionary (which is easy to find, for example gdataonline.com for MD5, 10^9 entries), the entire dictionary must be regenerated for each hash. That's 10^9 hash operations to attempt to guess a single password.

It won't stop an attacker determined to get at a single password no matter the cost, but it will stop attackers who skim the database for easily cracked passwords.

Re:Naturally, the passwords were not in clear

[jmcvetta]

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.

Presumably Apache will reload all the code repositories from the last backup before the compromise, and leave it to developers to re-submit any code that had been committed after that point. There is no reason to believe that a skilled intruder could not have injected code in a way that would be hard to detect.

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 their existence due to being destructive, so for many this is motivation enough.

They have gained notoriety -- much more than they would have gained had they cracked into a lower profile site. It's not really clear they are being destructive -- so far, at least. But if I were the admin of a major open source related website or repository, I'd be on the lookout for suspicious activity patterns that might suggest this fellow trying to make use of his stolen email/password pairs.

Obvious who did it

[tomhudson]

It was the Cowboy attacked Apache.

Finally - a CowboyNeal option that is the right one!

Re:Obvious who did it

[Bobfrankly1]

It was the Cowboy attacked Apache.

Finally - a CowboyNeal option that is the right one!

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

Re:Obvious who did it

[middlemen]

Obligatory: Microsoft did it to prove that IIS is more secure.

Re:Obvious who did it

[hey]

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:Obvious who did it

[Korin43]

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:Obvious who did it

[DarkKnightRadick]

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:Obvious who did it

[Anonymous Coward]

While I know it's a joke, I'm amazed about how many slashdotters speak about this issue without understanding that it was a client side exploit (having javascript turned off would have prevented it), combined with a dictionary attack.
No operating system, or web server could had prevented that.
But to give credit where credit is due, IE8 does have a layer of security which prevents XSS attacks (in theory anyway).

Re:Obvious who did it

[atisss]

If it was a repository (or some of that password fits as root for repository server), attackers could have updated some code and masked the logs, so if nobody would notice by diffing local version to repository - we could have a surprise trojan in next version of some Apache product.

Re:Obvious who did it

[Firehed]

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 so you don't even know something happened.

Re:Obvious who did it

[hey]

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:Obvious who did it

[DarkKnightRadick]

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:Obvious who did it

[atisss]

Actually anyone having recent local copy of source code before attack could check diff, and watch for strange changes.

The question is if there were any repositories hosted on this server, or stolen admin password could have been used to access repositories.

Re:Obvious who did it

[EricTheO]

Twit! Fort Apache is in the Bronx. Everyone knows that right?

Brutus

[Anonymous Coward]

The software was hosted on brutus.apache.org

Et tu, Brute?

Serves them right!

[Anonymous Coward]

You can't trust Apache... turn your back on them, and they'll steal your land

Et tu, Brute?

[gzipped_tar]

FTFA:

"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[sic] clicked on the link [to the site containing the XSS exploit]. This compromised their sessions, including their JIRA administrator rights."

Famous last words: "So they showed me this button and I pushed it. Now what?"

Re:Et tu, Brute?

[Anonymous Coward]

So, the actual exploit was in the browser they were using?

Re:Et tu, Brute?

[gzipped_tar]

Browser is only part of the problem. Negligence is more hazardous.

Should'a been running IIS!

[Kenja]

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

Re:Time to switch to lighttpd

[Anonymous Coward]

What the hell are you talking about?

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.

[Anonymous Coward]

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.

Motivation? I don't know, making the worlds most popular web server look bad or surreptitiously posting bad source code?

Re:Damage contained through one-time passwords.

[Fritz T. Coyote]

...What would be the motivation(s) for hacking Apache, anyway? It's not like it's Citibank.

Indeed. Unlike Citibank, the Apache Foundation is solvent, and has not burned through billions of taxpayer's dollars.

(rimshot)

Re:Damage contained through one-time passwords.

[Anonymous Coward]

From the alert:

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, [redacted].com(org/net/edu/biz)

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.

[gzipped_tar]

> What would be the motivation(s) for hacking Apache, anyway? It's not
> like it's Citibank.

Hacking the server serving code so that they can ship malware through the distribution of Apache software?

This has happened before, and will happen again...

Re:Damage contained through one-time passwords.

[Jherico]

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

[gad_zuki!]

Or upload a trojan into the hosted Apache installers.

Re:Damage contained through one-time passwords.

[chrb]

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

[Lord Ender]

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 having to trick any users (and get by spam filters, web proxies, etc.). It makes perfect sense.

"Cyber" bank robbery accounted for more theft than in-person bank robbery last year. There is real, easy-to-demonstrate ROI in developing better attacks.

Re:Damage contained through one-time passwords.

[Yvanhoe]

Actually while I ackowledge Apache's response was adequate, isn't it worrying that such a thing can happen ?

Re:Damage contained through one-time passwords.

[jimicus]

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

[houghi]

Because they can?

Re:Damage contained through one-time passwords.

[Anonymous Coward]

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?

Nice! Even when an OSS project gets broken into, it's mention of its insecurity is still "FUD". What a jackass...

Re:Damage contained through one-time passwords.

[Anonymous Coward]

Well if it's so sophisticated, they wouldn't put the back-door into public versions, but they can just make the modified source code to be downloaded from specific hosts they target their attack to. Only way to check validity of package is hashes, but they can make download webpage look differently for specific hosts as well (ie. RedHat hosts). I don't think distros check whole sources from over for every release. This kind of attack is not that hard when you penetrate the server, and can be well hidden.

Re:Damage contained through one-time passwords.

[Anonymous Coward]

FUD...with the truth.

Huh.

Re:Damage contained through one-time passwords.

[Anonymous Coward]

What would be the motivation(s) for hacking Apache, anyway?

Well, some answers in the mail sent by Apache asking to reset the pwd:

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 'XX' to JIRA.
[...]
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, XXx.XX.

And reading the report from Apache (very interesting), you see that hackers had fun messing around things, but the aim was really password-retrieval. They got spotted once they started to shut down services.

Passwords were hashed

[Anonymous Coward]

From TFA: "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. "

I'm a n00b with security. Am I correct in thinking that there's no way to decrypt a password without the salt? How would Apache have determined the salt? And what are the odds of the thieves finding the salt?

Re:Passwords were hashed

[awesie]

A salt is stored in plaintext with the hashed password. The main purpose of a salt is to eliminate the use of precomputed hash tables (e.g. rainbow tables). I don't think the article mentioned whether the hashes were salted or not.

Re:Passwords were hashed

[gzipped_tar]

TFA said that as part of the attack the attackers managed to harvest user login credentials by spreading bogus password reset emails, rendering all those encryption stuff as impossible to bypass as the Maginot Line.

Using the valuable login info, they rooted the machine and, by definition of "rooted", controlled everything. Salting is irrelevant here.

Re:Passwords were hashed

[Anonymous Coward]

The main purpose of a salt is to eliminate the use of precomputed hash tables (e.g. rainbow tables).

No.

If you want to make Rainbow Table attacks harder, you're better off using a hash that's xx bits stronger, rather than adding a xx-bit hash.

You add salt to frustrate Dictionary attacks, so that the same password doesn't compute to the same hash. This matters when you have a known hash, that you're comparing against (by definition, all dictionary attacks are subsets of rainbow table attacks).

If you know the hash of a certain password, say, by creating your own account with that password before stealing the database, then without salt you know all other accounts with that same password, because they'll have the same hash. For common passwords and typical users, this means that something like +90% of passwords will be one of about 10 different common passwords, like, "password", "password1", "letmein", etc.

Re:Passwords were hashed

[bigrockpeltr]

but if done properly the salt can be in plaintext and not even recognized by an attacker. for e.g. 1/ use random salts ( each account would have a different salt and attackers would have to compute rainbow tables for each account assuming they know the salt) 2/ append/prepend the salt on to the hash. ( they have to guess if its at the front or back of the hash) 3/ you can control the length of the salt. ( they have to guess how many chars to use as the salt) 4/ you can also truncate the hash to some length you choose ( they attackers would have to guess the length and if they dont no hash would match because their salt offset would be wrong.) so with even relativley weak passwords it would still take a great deal of effort/ almost infeasible to crack ONE account unless they have other access to your code that computes the hashes or validates user entered passwords against the hashes.

Ubuntu? Really?

[Anonymous Coward]

Why are these people hosting important information on ... Ubuntu servers? With all the options these days for Linux distros, I would never consider Ubuntu for anything beyond a workstation.

Re:Ubuntu? Really?

[DarkKnightRadick]

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:Ubuntu? Really?

[danieltdp]

So you are telling us that the Apache crowd can't even choose a proper Linux Distro? I imagine you are confusing the existence of a nice gui on the Desktop edition with a badly-made Server one. No conection at all between those two possibilities...

Re:Ubuntu? Really?

[Anonymous Coward]

I can tell it's not server grade.

Nice bit of FUD. However, taking this into account, you might want to more finely hew your talking points in the future or continue looking like an uninformed "n00b" yourself.

Re:Ubuntu? Really?

[Anonymous Coward]

grow up man, proper linux distro? Explain to me what that might be? Other than some bias of yours.

Re:Ubuntu? Really?

[danieltdp]

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:Ubuntu? Really?

[DarkKnightRadick]

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:Ubuntu? Really?

[DarkKnightRadick]

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:Ubuntu? Really?

[danieltdp]

The link speaks for itself

Re:Ubuntu? Really?

[hydroponx]

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.

Possibly not, but I'm pretty sure the server edition is a little different than the desktop.

Re:Ubuntu? Really?

[styrotech]

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.

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 support lifecycles, and the Server LTS editions will get longer support than Debian stable normally will (ie 5 years).

And Ubuntu tends to have slightly more updates for non security related bugs than Debian.

The base install is about as bare boned as a base Debian install is. An Ubuntu server will also generally not have any of the typically troublesome desktop packages istalled (eg audio, latest graphics drivers, wireless etc). The patches for the same vulnerabilities are usually released for both Debian and Ubuntu within a day of each other.

While I personally prefer Debian servers a bit more, I really don't see any problems with using Ubuntu LTS Server editions. Especially if you need guaranteed security support for more than 2 years between upgrades.

Re:Ubuntu? Really?

[DarkKnightRadick]

Meh. I still wouldn't trust it. Gentoo or FreeBSD is what I'd choose for a server of any sort.

This really is a pointless conversation as it has nothing to do with the technologies involved (it was JIRA that was compromised, thus gaining root to the server).

So Ubuntu has a server edition. Whoop. I still won't use it. Just my preference. I never stated anything as fact. I started off this discussion with an opinion and will end it with such.

Ubuntu (server edition or not) will never be used as a server by me. It is a n00b distro. Maybe the server edition is better about updates and such than the desktop version, but I really don't care. My opinion is soured.

Re:Ubuntu? Really?

[Anonymous Coward]

Gentoo for a server... That's worse than suggesting Debian unstable for a "secure server."

Re:Ubuntu? Really?

[Anonymous Coward]

Regardless of whether it's server grade or not, no n00bs should be seen hanging around production servers.

Re:Ubuntu? Really?

[DarkKnightRadick]

agreed.

Re:Ubuntu? Really?

[DarkKnightRadick]

I ran Gentoo as a server. Never had an issue.

Serious Question

[Dr. Evil]

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:Serious Question

[Anonymous Coward]

Some people are dicks. News at 11.

Re:Serious Question

[c1ay]

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.

Re:Serious Question

[Required Snark]

Someone in China or Russia? Apache is so vital to corporate and even government operations that compromising the code base could have huge financial and/or intelligence implications. I'm sure that there are Apache behind security barriers, and using it to gather information and send it elsewhere would be greatly prized. Just guessing...

Re:Serious Question

[Anonymous Coward]

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

How many websites do you know that DON'T run Apache?

A successful break into these servers could lay the foundation for hijacking Apache patches/updates/releases in the future. As it happens, they were stopped right away though...

Re:Serious Question

[gzipped_tar]

According to TFA, after some fairly impressive exploits the attacker tried to shut down certain services. This is very unprofessional because it is a sure way to expose themselves quickly.

Now the question is: did they just did it for teh lulz, or are they so powerful that they don't care the loss of stealth? The plot thickens...

Re:Serious Question

[edmazur]

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

From an email I received from Apache 20 minutes ago (emphasis mine):

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 'edmazur' 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, cs.umass.edu.

Re:Serious Question

[Arancaytar]

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:Serious Question

[DarkKnightRadick]

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

[Zecheus]

I got an email from apache giving an answer to this question:

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.

Re:Serious Question

[dkleinsc]

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:Serious Question

[bigsimes]

It could be a smoke-screen that hides something else that has happened / will happen somewhere else in the system?

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:Serious Question

[Anonymous Coward]

Someone in China or Russia?

I think we can rule Russia out.

In Soviet Russia, Apache servers hack YOU.

Re:Serious Question

[Anonymous Coward]

users tend to have a very small combination of userids and passwords. if a combination worked on the apache jira instance, it might work in ibm's email or else citibank.

Re:Serious Question

[Nutria]

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.

Re:Serious Question

[CAIMLAS]

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:Serious Question

[DarkKnightRadick]

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:Serious Question

[hoggoth]

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:Serious Question

[orkysoft]

You're just asking to be added to the No Internet List...

Re:Serious Question

[Anonymous Coward]

It shouldn't be considered "weird" - did you think a particular crowd would somehow be exempt?
What many simply fail to realize is that black hats aren't 'friendly'. Just because Slashdot caters to the Linux OS crowd doesn't mean that black hats are any more friendly to you (or to open-source projects) than they are to anyone else. They will use whatever code they can to achieve their goal(s). Script-kiddies are even less discriminate, if sloppier.

So really, this attack shouldn't be surprising. Additionally, what isn't surprising are the more humble posts now being issued from what was largely an arrogant group of Windows-bashers.
Nice to see you're getting your come-uppance - and just FYI, it's called Karma.

Support true net neutrality, whatever OS you use.

Re:Serious Question

[DarkKnightRadick]

Sorry, this is slashdot. I've been getting a lot of sarcasm and taking a lot of heat lately for my position on various subjects.

Yeah, I do.

(:

Re:Serious Question

[Kalriath]

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

Email addresses. These are worth an absolute ton on the black market - trust me when I say the attacker doesn't give a flying fuck about the passwords. Expect that any email address in Apache's database is now going to receive a lot of "cheap luxury watch", "very cheap soft" and "online meds" offers.

If you can, change your email address now.

TinyURL Previews

[The MAZZTer]

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

http://tinyurl.com/preview.php

Re:TinyURL Previews

[Anonymous Coward]

Does it matter? Nowadays there are dozens of urls shortening services.
A browser extension on the other hand would prove very useful.

Re:TinyURL Previews

[Statecraftsman]

Url shorteners are an unnecessary security risk and also creates single points of failure for long term Internet stability. We should try to avoid them and instead encourage popular sites to provide their own shortened links. For more, here's a noteworthy blog post on the subject: http://joshua.schachter.org/2009/04/on-url-shorteners.html

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

Re:TinyURL Previews

[Hurricane78]

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

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

Re:TinyURL Previews

[Zancarius]

And if that URL just isn't long enough, try here.

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

[Lisandro]

Apache is a foundation, not a company. I otherwise agree - they handled this really well in my opinion.

Re:Respect

[Anonymous Coward]

Apache is a foundation, not a company. I otherwise agree - they handled this really well in my opinion.

They're a 501(c)(3) corporation, and are subject to some pretty similar regulations as companies and then some, but yeah I know what you mean.

Re:Respect

[PGOER]

These aren't the bugs your looking for...

Re:Respect

[scjet]

Yup, what doesn't kill Apache will only make it STRONGER, and stronger, ... -No FUD here.

Re:Respect

[Anonymous Coward]

I think the term you're looking for is "due diligence". The word "transparency" is so overused and misused these days it drives me crazy.

Re:Respect

[Anonymous Coward]

http://www.apache.org/foundation/faq.html#is-ASF-a-corporation

It's still a (not-for-profit) company.

Re:Respect

[wurp]

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

[mrkitty]

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

WASC Threat Classification - Cross-site Scripting
http://projects.webappsec.org/Cross-Site+Scripting

Ripple effect

[butabozuhi]

Although Apache says it's one-time use passwords were a lifesaver, that would be to itself? As many people use the same password for multiple systems, isn't there a pretty large risk of this impacting many, many other systems. Perhaps these techies wouldn't use such practices, but I'm guessing it's common enough. How many 'admin passwords' are now in the hands of these criminals? The damage from this could be pretty severe but will we ever know this?

Re:Ripple effect

[Statecraftsman]

That is a good point. Perhaps they're targeting the hardest targets and are preparedto brute-force these "high value" passwords one at a time thereby building an elite password dictionary.

Re:Ripple effect

[mcgrew]

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:Ripple effect

[MemoryDragon]

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.

Injection of vulnerabilities at the source

[Aceticon]

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 the know-how and the resources to both hack into the site and develop their own source-code level backdoors.

Criminal organizations with significant black hat operation would also be willing and capable of this sort of strategic action.

I would definitelly double check any code checked-in by the people whose passwords were stolen.

Re:Injection of vulnerabilities at the source

[sowth]

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.

Re:and windows is insecure...

[lordmatrix]

Operating system has nothing to do with this attack. Web server has nothing to do with this attack. JIRA has to do with this attack. If a session cookie is stolen and is valid when used by the 3rd party, it's the application's fault. The solution would be a better, more secure session manager in JIRA. Additional solution would be using HTTPS.

This Highlight a Problem

[Anonymous Coward]

.. that's bothered me since I saw my first tinyurl. You have no clue where that URL is actually pointing to. Could be a legit site, could be a cp site, who knows which? Verifying the link you are clicking on is information security 101.

Re:This Highlight a Problem

[sheph]

If only we could get the bad guys to just set the evil bit. It would make filtering so much more efficient.

Interesting attack, but depends on user fail

[Bearhouse]

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 [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:Interesting attack, but depends on user fail

[TheSunborn]

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

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

[Denihil]

ahhh, good point. i didn't even think of that. i just assumed the hackers would already have access to their source.

Email I received from Apache

[Andrew Cooper]

I received this from Apache just moments ago. It may clear up some questions. I redacted personal info.

Dear [redacted],

You are receiving this email because you have a login, [redacted], 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 [redacted] 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, [redacted].

Naturally we would also like you to reset your JIRA password. That can be done at:

https://issues.apache.org/jira/secure/ChangePassword!default.jspa

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

Why go after Apache?

[Anonymous Coward]

Excerpt from the email I got from Apache this morning:

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

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

So, since people tend to reuse passwords associated with a given email address, the payoff is that you go after a weakly protected source of both - the value isn't in compromising Apache per se, but using Apache to obtain credentials which you might use/sell to access other sites. I just wonder why salting wasn't used - although if someone stole the whole database they'd have the salt anyway.

Re:and windows is insecure...

[Volante3192]

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

[Pharago]

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

Correction

[dandart]

s/hackers/crackers/g

Additionally, Brutus is password cracking software... not mentioned in the summary.

Re:Correction

[nacturation]

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.

don't be stupid, it's design failure

[Colin Smith]

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

Re:don't be stupid, it's design failure

[Bearhouse]

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

Re:don't be stupid, it's design failure

[DJCacophony]

XSS is a web application vulnerability, first and foremost.

Ubuntu?

[Anonymous Coward]

What sane person would run Ubuntu on their server?

Re:Ubuntu?

[PCWizardsinc]

What's wrong with Debian/Ubuntu?

Why is cookie stealing possible

[Anonymous Coward]

What XSS allows is redirection to an attacker's controlled site, plus some script code execution on the victim's browser.

If the victim's computer does not honor document.cookie or other equivalent method, is cookie stealing still possible ?

Going further, why do most browsers honor the document.cookie method ?

Re:lols

[Anonymous Coward]

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?

Think About It

[Ashcrow]

There are number of people posting comments about how this isn't an issue since Apache's code is open. Let me outline a few possible issues even with the code being ...

1. If Apache keeps non-released security information in their bug tracker it could end up being disclosed. Great if you want to get your hands on security issues before patches are released.
2. Private comments can be leaked out which are probably not meant for general consumption. Probably not a huge issue, but it depends on the content.
3. Many people use the same passwords everywhere -- and the same usernames. Any cracked accounts could prove quite useful.


On the flip side it goes to show that XSS and CSRF are, as many security (open and closed) groups note, are a major problem -- and are pretty easy to exploit. While it is not fun to have this occur it may wake up some engineers into seeing that 'if it can happen to Apache maybe we should take it seriously'.

Then there is the whole thing of Apache using Jira instead of something Open ... http://blogs.atlassian.com/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach.html ... :-)

How to protect yourself...

[Anonymous Coward]

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

Re:How to protect yourself...

[nacturation]

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

Re:How to protect yourself...

[Anonymous Coward]

Probably too late to get rated up, but I loled.

(original poster)

UntinyFox

[pavon]

This one works: UntinyFox.
Reading the source, it appears to use this website to convert the URLs.

reasons

[Anonymous Coward]

Bad people think:
1. I'm cool, look what i did.
2. Now I have the usernames and passwords, and probably password schemas for a bunch of Apache developers and admins. Hit their sites. Profit!
3. Maybe one of these accounts will let me manipulate Apache source distributions. Backdoors. Profit!
4. Competitor using resulting FUD to increase market share. Profit!

Password reuse, the lazy hacker's easy-button.
user "I have no idea how they got my account."

Re:lols

[Anonymous Coward]

Should of installed Gentoo instead

Well, this is also why i use URL Elongator Plus

[baryluk]

There is many script which scans webpage for tinyurl type links and performs reverse operation and make them show as original url. One of such scripts is URL Elongator Plus for Opera http://extendopera.org/userjs/content/url-elongator-plus (it is UserJS script). Works fast, is configurable and supports lots of pages.

There is also other similar scripts.

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

Things start to heat up

[Mathinker]

Judging from these attacks and the two attempts to inject malware in Linux via infected submissions to a site distributing user-submitted Gnome themes, it looks to me like the commercial black hat community is already testing the water for the future when Windows isn't quite as easy to infect/zombie (or perhaps, for a future where most of the clueless are running locked-down non-general-purpose computing devices like the iPad).

I have a feeling that things may start to heat up for FOSS, to the extent that eventually (say in another 10-20 years) I'll have to move from thinking about Linux as being my secure system, to some new exotic OS like Haiku or Plan9 (and even then, there is the big problem that I'll also have to find exotic replacements for things like Firefox and Thunderbird).

Or have I just invented the next mutation of the "Year of the FOSS Desktop" meme? /facepalm

Disgusted?

[Anonymous Coward]

I can understand that you're disappointed about the inconvenience, but how much more of a straightforward and informative email could you possibly ask for?

Re:and windows is insecure...

[tibman]

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.

lite hash better than nothing

[Onymous Coward]

This may be a good time to review the "defense in depth" concept; having a quality password can actually help in some circumstances.

E tu brute

[Anonymous Coward]

..Nobody's said E tu Brute? Inconceivable!

Obligatory

[Anonymous Coward]

Well you do notice that Microsoft and Microsofters are now in the Apache Foundation, so it is only natural that the Microsoft way of thinking starts to affect operations. Look for more cracks as their way of thinking gets deeper into Apache.

The Joker

[Anonymous Coward]

The software was hosted on brutus.apache.org

Et tu Brutus?

XSS is really hard to eliminate

[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 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

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:XSS is really hard to eliminate

[Anonymous Coward]

I expect my bank to be very safe.

I expect Slashdot to have just enough effort put into it to not collapse into a heap of garbage, trollspam, and HTTP 500 errors.

It has always been thus, and I wouldn't have it any other way.

Re:XSS is really hard to eliminate

[thoughtsatthemoment]

If one site has to get confidential info from another size, it must be https. That shouldn't be too hard to do.

Re:lols

[Anonymous Coward]

Oh, hand on a sec, there's sarcasm here?

Nope.

Re:lols

[Anonymous Coward]

You fail to recognize sarcasm when not concentrating...

Would you happen to be from a small planet somewhere in the vicinity of Betelgeuse?

Re:lols

[TheRaven64]

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

Brutus?

[Anonymous Coward]

"The software was hosted on brutus.apache.org..."

Et tu, Brutus?

Why so dumb?

[socceroos]

Why are so many hinting that Ubuntu is to blame? This has nothing to do with the underlying OS. This has to do with a vulnerability in third party software.

Re:Why so dumb?

[Anonymous Coward]

Anytime anyone says that about a Windows exploit we here you freetards speaking shit on Microsoft.

Suck it, fanboi! We're not letting this shit go until you fuckers start talking logic instead of acting like a bunch of religious nuts. Go it?

Upstream attack

[Anonymous Coward]

JIRA developer Atlassian was attacked as well.

http://blogs.atlassian.com/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach.html

A good day as any to reset passwords.

Re:lols

[mathew7]

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?

The problem is they could do changes and reviews posing as other long-time trusted developers. This is a vulnerability in the chain of trust. If such an attack would be discovered too late, all the latest updates could be left vulnerable. For example, if the attack is discovered 1 month later, some back-door patches could get in the stable (production) release.

So this is like cancer: discovered in time, the consequences can be controlled, but discovered too late, all hell breaks loose.

...and the first short URL analyzer to the rescue

[Anonymous Coward]

Although most of the threats behind a short URL are XSS & friends, the use of short URLs to masquerade malicious things is clearly on the rise. It also look like a service has been released with the goal of analyzing short URLs (not only expanding): http://long-shore.com - the website also exposes a RESTful API that can be used to submit URLs and flag malicious ones.

Re:every site in the world should have frame busti

[Simetrical]

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

Wikipedia used to have that, but dropped it. It interferes with useful services like Google Translate (IIRC).

Re:lols

[supssa]

wow parents and grandparent are ridiculously stupid!