Slashdot Mirror
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."
"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"
Finally - a CowboyNeal option that is the right one!
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.
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."
Does this smell like Chloroform to you?
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?"
Colorless green Cthulhu waits dreaming furiously.
cause that would have confused the hell out of the attackers.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
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.
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.
In a band? Use WheresTheGig for free.
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.
Turn them on, so you can see where they go.
http://tinyurl.com/preview.php
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.
XSS FAQ
http://www.cgisecurity.com/xss-faq.html
WASC Threat Classification - Cross-site Scripting
http://projects.webappsec.org/Cross-Site+Scripting
Believe me, if I started murdering people, there would be none of you left.
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.
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?
mu
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.
My other signature is a car
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.
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.
Colorless green Cthulhu waits dreaming furiously.
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.
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!!"
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.
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?
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...
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.
Socialism: a lie told by totalitarians and believed by fools.
ahhh, good point. i didn't even think of that. i just assumed the hackers would already have access to their source.
WÌÌfÍ--ÍSÌÒÍ...Í...ÌHÌÍfÍÍÍ--ÍÍÍ
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.
Similes are like metaphors
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.
A successful API design takes a mixture of software design and pedagogy.
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.
they just couldn't figure out how to access subversion so they got the code thru some more entertaining ways
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.
"There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
s/hackers/crackers/g
Additionally, Brutus is password cracking software... not mentioned in the summary.
you can compromise your system by clicking on a link? That is fucked up design.
Deleted
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.
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?
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 ...
... http://blogs.atlassian.com/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach.html ... :-)
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
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...
This one works: UntinyFox.
Reading the source, it appears to use this website to convert the URLs.
Except that the OS was not compromised, but an application running on top of it.
Seven Days with Ubuntu Unity
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.
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.
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.,
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
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.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
I'll have to remember that one.
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...
-- dnl
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
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
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.
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.
$ unzip, strip, touch, finger, grep, mount, fsck, more, yes,fsck,fsck,fsck,umount, sleep
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.
"It's ok, I'm completely secure as long as my iron is off"
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/
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
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
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.
http://soylentnews.org/~tibman
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.
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.
How are sites slashdotted when nobody reads TFAs?
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.
Similes are like metaphors
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.
This may be a good time to review the "defense in depth" concept; having a quality password can actually help in some circumstances.
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.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
unsalted pws bad, but it is no biggie if you don't reuse!
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.
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?
"But this one goes to 11!"
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.
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
-- dnl
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?
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.
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.
What's wrong with Debian/Ubuntu?
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.
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.
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.
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)
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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.
"There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
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.
If only we could get the bad guys to just set the evil bit. It would make filtering so much more efficient.
I don't believe in karma, I just call it like I see it.
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.
"There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
He uses Gentoo. He's installed the words, but the grammar is still compiling.
I am TheRaven on Soylent News
The link speaks for itself
-- dnl
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.
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.
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.
Needless to say, I'm quite disgusted with the Apache foundation right now.
At least it wasn't stored plain text!
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.
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.
"There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
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.
There's no place like
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...
There's no place like
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.
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.
Be seeing you...
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').
have you been defaced today?
This is slashdot. Double standards are the standard. You must be an ms fanboi for pointing that out.
Seven Days with Ubuntu Unity
agreed.
"There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
I ran Gentoo as a server. Never had an issue.
"There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
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.
Why unsalted, I don't know.
Gah, always needing to add salt. Typical American, don't you care about your heart??
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.
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.
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).
MediaWiki developer, Total War Center sysadmin
wow parents and grandparent are ridiculously stupid!
Hatin' on products I don't like and getting modded up talking about tech I totally don't understand like it was 2005!