Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apache Foundation Attacked, Passwords Stolen

CmdrTaco posted more than 4 years ago | from the yeah-we-meant-to-do-that dept.

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

cancel ×

214 comments

lols (-1, Troll)

Denihil (1208200) | more than 4 years ago | (#31833748)

Open source got open'd?

Re:lols (4, Funny)

lgw (121541) | more than 4 years ago | (#31834376)

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 (1)

Denihil (1208200) | more than 4 years ago | (#31834420)

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

Re:lols (0)

Anonymous Coward | more than 4 years ago | (#31835394)

Should of installed Gentoo instead

Re:lols (3, Funny)

Pharago (1197161) | more than 4 years ago | (#31834614)

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

Re:lols (2, Funny)

Anonymous Coward | more than 4 years ago | (#31835174)

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?

obviously advanced Linux users (2, Informative)

Anonymous Coward | more than 4 years ago | (#31833752)

"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 (0)

Arancaytar (966377) | more than 4 years ago | (#31833768)

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 (5, Informative)

Arancaytar (966377) | more than 4 years ago | (#31833820)

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 (5, Informative)

not already in use (972294) | more than 4 years ago | (#31834484)

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/ [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 (3, Informative)

Sorthum (123064) | more than 4 years ago | (#31835100)

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 (3, Interesting)

bark (582535) | more than 4 years ago | (#31835422)

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

Re:Naturally, the passwords were not in clear (1)

King InuYasha (1159129) | more than 4 years ago | (#31833822)

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 (1)

King InuYasha (1159129) | more than 4 years ago | (#31833914)

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 (1)

EsbenMoseHansen (731150) | more than 4 years ago | (#31835508)

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 (1)

X0563511 (793323) | more than 4 years ago | (#31835632)

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 (1)

Ivan Stepaniuk (1569563) | more than 4 years ago | (#31834100)

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 (1)

tibit (1762298) | more than 4 years ago | (#31834516)

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 (2, Informative)

FallinWithStyle (1474217) | more than 4 years ago | (#31833838)

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 (3, Informative)

Luke has no name (1423139) | more than 4 years ago | (#31833854)

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 (2, Insightful)

jimicus (737525) | more than 4 years ago | (#31834106)

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 (2, Insightful)

Volante3192 (953645) | more than 4 years ago | (#31834172)

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 (1)

AndGodSed (968378) | more than 4 years ago | (#31835404)

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

Re:Naturally, the passwords were not in clear (2, Interesting)

Anonymous Coward | more than 4 years ago | (#31834294)

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

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

Re:Naturally, the passwords were not in clear (0)

Anonymous Coward | more than 4 years ago | (#31833906)

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.

Obvious who did it (2, Funny)

tomhudson (43916) | more than 4 years ago | (#31833796)

It was the Cowboy attacked Apache.

Finally - a CowboyNeal option that is the right one!

Re:Obvious who did it (2, Funny)

Bobfrankly1 (1043848) | more than 4 years ago | (#31833928)

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 (1)

middlemen (765373) | more than 4 years ago | (#31833952)

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

Re:Obvious who did it (1)

hey (83763) | more than 4 years ago | (#31834296)

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 (1)

Korin43 (881732) | more than 4 years ago | (#31834374)

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 (1)

DarkKnightRadick (268025) | more than 4 years ago | (#31834546)

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 (1)

atisss (1661313) | more than 4 years ago | (#31835246)

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 (0)

Anonymous Coward | more than 4 years ago | (#31834570)

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

Brutus (0)

Anonymous Coward | more than 4 years ago | (#31833798)

The software was hosted on brutus.apache.org

Et tu, Brute?

Time to switch to lighttpd (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31833812)

I don't want my website hacked!

Re:Time to switch to lighttpd (0)

Anonymous Coward | more than 4 years ago | (#31833900)

What the hell are you talking about?

Serves them right! (0)

Anonymous Coward | more than 4 years ago | (#31833814)

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

Et tu, Brute? (1)

gzipped_tar (1151931) | more than 4 years ago | (#31833844)

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? (0)

Anonymous Coward | more than 4 years ago | (#31834016)

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

Re:Et tu, Brute? (1)

gzipped_tar (1151931) | more than 4 years ago | (#31834194)

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

Should'a been running IIS! (5, Funny)

Kenja (541830) | more than 4 years ago | (#31833848)

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

Damage contained through one-time passwords. (3, Informative)

helixcode123 (514493) | more than 4 years ago | (#31833908)

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. (4, Insightful)

HogGeek (456673) | more than 4 years ago | (#31833986)

Hmm, let's see:

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

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

Re:Damage contained through one-time passwords. (0)

Anonymous Coward | more than 4 years ago | (#31834090)

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

Fritz T. Coyote (1087965) | more than 4 years ago | (#31834102)

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

Anonymous Coward | more than 4 years ago | (#31834330)

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. (3, Insightful)

jimicus (737525) | more than 4 years ago | (#31834372)

I can think of a couple.

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

Re:Damage contained through one-time passwords. (1)

gzipped_tar (1151931) | more than 4 years ago | (#31834402)

> 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. (2, Interesting)

Jherico (39763) | more than 4 years ago | (#31834970)

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.

Passwords were hashed (0)

Anonymous Coward | more than 4 years ago | (#31833916)

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 (1)

awesie (961837) | more than 4 years ago | (#31834050)

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 (0)

Anonymous Coward | more than 4 years ago | (#31835044)

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 (1)

gzipped_tar (1151931) | more than 4 years ago | (#31834128)

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.

Ubuntu? Really? (0)

Anonymous Coward | more than 4 years ago | (#31833940)

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? (1)

DarkKnightRadick (268025) | more than 4 years ago | (#31834620)

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.

Serious Question (2)

Dr. Evil (3501) | more than 4 years ago | (#31833954)

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

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

The whole thing is weird.

Re:Serious Question (0)

Anonymous Coward | more than 4 years ago | (#31834062)

Some people are dicks. News at 11.

Re:Serious Question (2, Insightful)

c1ay (703047) | more than 4 years ago | (#31834080)

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 (1)

Required Snark (1702878) | more than 4 years ago | (#31834206)

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 (1)

DarkKnightRadick (268025) | more than 4 years ago | (#31834640)

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 (3, Funny)

hoggoth (414195) | more than 4 years ago | (#31835298)

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 (0)

Anonymous Coward | more than 4 years ago | (#31835490)

Someone in China or Russia?

I think we can rule Russia out.

In Soviet Russia, Apache servers hack YOU.

Re:Serious Question (0)

Anonymous Coward | more than 4 years ago | (#31834230)

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 (1)

gzipped_tar (1151931) | more than 4 years ago | (#31834348)

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 (1)

edmazur (958154) | more than 4 years ago | (#31834398)

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 (1)

Arancaytar (966377) | more than 4 years ago | (#31834440)

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 (1)

Zecheus (1072058) | more than 4 years ago | (#31835014)

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 (1)

dkleinsc (563838) | more than 4 years ago | (#31835084)

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 (1)

bigsimes (737788) | more than 4 years ago | (#31835134)

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

TinyURL Previews (5, Informative)

The MAZZTer (911996) | more than 4 years ago | (#31833968)

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

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

Re:TinyURL Previews (0)

Anonymous Coward | more than 4 years ago | (#31834058)

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 (1)

Statecraftsman (718862) | more than 4 years ago | (#31834212)

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 [schachter.org]

UntinyFox (1)

pavon (30274) | more than 4 years ago | (#31835258)

This one works: UntinyFox [mozilla.org] .
Reading the source, it appears to use this website [alzaid.ws] to convert the URLs.

Respect (5, Insightful)

Xacid (560407) | more than 4 years ago | (#31833984)

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 (2, Informative)

Lisandro (799651) | more than 4 years ago | (#31834032)

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

Re:Respect (1, Informative)

Anonymous Coward | more than 4 years ago | (#31835030)

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.

and windows is insecure... (-1, Troll)

Jackie_Chan_Fan (730745) | more than 4 years ago | (#31833994)

Penguin Penguin... oh poor Penguin

Re:and windows is insecure... (2, Informative)

lordmatrix (1439871) | more than 4 years ago | (#31834238)

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.

Re:and windows is insecure... (1)

Volante3192 (953645) | more than 4 years ago | (#31834538)

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.

Ripple effect (1)

butabozuhi (1036396) | more than 4 years ago | (#31834084)

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 (1)

Statecraftsman (718862) | more than 4 years ago | (#31834300)

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 (1)

mcgrew (92797) | more than 4 years ago | (#31835462)

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.

Injection of vulnerabilities at the source (1)

Aceticon (140883) | more than 4 years ago | (#31834158)

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 (1)

sowth (748135) | more than 4 years ago | (#31834812)

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.

This Highlight a Problem (0)

Anonymous Coward | more than 4 years ago | (#31834248)

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

Interesting attack, but depends on user fail (1)

Bearhouse (1034238) | more than 4 years ago | (#31834342)

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

TheSunborn (68004) | more than 4 years ago | (#31834514)

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 (1)

Colin Smith (2679) | more than 4 years ago | (#31834712)

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

Re:don't be stupid, it's design failure (2, Insightful)

Bearhouse (1034238) | more than 4 years ago | (#31834908)

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

Email I received from Apache (1)

Andrew Cooper (1539649) | more than 4 years ago | (#31834448)

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/ [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 [apache.org]

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 [apache.org]

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? (0)

Anonymous Coward | more than 4 years ago | (#31834524)

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.

Correction (1, Offtopic)

dandart (1274360) | more than 4 years ago | (#31834700)

s/hackers/crackers/g

Additionally, Brutus [hoobie.net] is password cracking software... not mentioned in the summary.

Ubuntu? (0)

Anonymous Coward | more than 4 years ago | (#31834762)

What sane person would run Ubuntu on their server?

Why is cookie stealing possible (0)

Anonymous Coward | more than 4 years ago | (#31834886)

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 ?

Think About It (1)

Ashcrow (469400) | more than 4 years ago | (#31835200)

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 [atlassian.com] ... :-)

How to protect yourself... (1, Interesting)

Anonymous Coward | more than 4 years ago | (#31835234)

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

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

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

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

reasons (0)

Anonymous Coward | more than 4 years ago | (#31835370)

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

Well, this is also why i use URL Elongator Plus (1)

baryluk (1319237) | more than 4 years ago | (#31835408)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...