So, Anonymous, under the guise of its AntiSec campaign, has hacked an Apple server, got access to 27 administrator usernames and passwords, and put them on Pastebin. Is it time to panic? Is it time to point and laugh at Apple? Is it time to stop using iTunes? Not really – this is a small hack that will cause little to no damage.
Even though LulzSec officially called it quits not too long ago, some of its members teamed up with Anonymous to continue their campaign of mischief under the AntiSec moniker. Companies and websites are being hacked left and right, but it’s impossible to keep up with all this stuff. Imagine my surprise when I read Apple got hacked.
As is customary by now, the hack was announced on Twitter. “Not being so serious, but well: http://t.co/DOE7Aeh #Apple could be target, too. But don’t worry, we are busy elsewhere.”
So, what is in this data cache? Not particularly much, probably because it looks like a rather minor server that got hacked – abs.apple.com – which has since been taken offline. They managed to extract a whopping 27 usernames and passwords – but the passwords are hashed. I’m no security expert, but comments over at Hacker News indicate that the hashes are Googleable. They appear to be “MySQL ‘PASSWORD()'(SHA1 x2) hashed passwords”, and indeed, Google returns results for these. No idea what that means – can someone with knowledge in this field pipe in here?
This looks like the result of another SQL injection attack, but other than some minor embarrassment, it would seem this won’t affect Apple or its customers too much. LEt’s hope the iTunes account database is properly secured – but considering the fact that iTunes is most likely a high-profile target and has not yet been hacked, it’s probably safe to assume it’s going to take more than an SQL injection to cause any serious damage to Apple.
While this caused little to no damage, they did get in. It isn’t like Apple has the best security record for their OS. Time for Apple to start an audit. Make sure to tighten down the hatches.
Even so the thing I think people ignore is the fact that the heavy lifting within Apple isn’t done by Apple’s own products; they have a mixture of Windows, AIX, Solaris, Linux and a few other OS’s for good measure so it would be interesting to see what system was affected by the hack.
You are correct though when it comes to the security record which will come under even more scrutiny with the launch of iCloud and people wondering whether Apple is on top of their security game enough as to trust them with sensitive information.
Ja. It’s not like Apple has one of the biggest databases of active credit cards and personal details that hackers would find useful. It’s just lack of trying.
A “Googleable” hash means that the passwords were not salted; this means that anybody can create a rainbow-table of precomputed hashes and match up Apple’s hash with a known original password. If the passwords were salted (and ideally salted per-password), all possible original passwords would have to be computed for each known Apple hash, significantly increasing the workload. With GPU computing so relatively cheap now, reverse-hashing passwords, even strong ones, can be achieved in as little as 10 seconds with a single rack of computers.
Jeff Atwood (of the codinghorror.com and stackoverflow.com fame) has blog post a long time ago on this topic.
It is an insightful and enlightening read.
http://www.codinghorror.com/blog/2007/09/youre-probably-storing-pas…
Sounds like a shot across Apple’s bow to me, and a warning to all the Mac users that want to think their little closed Mac world is secure and not vulnerable. Anonymous is just letting Apple, and Mac users know that no, it is not. And if they want to, they can target Apple with a much more damaging attack.
stop giving Lulz/AntiSec/lame-o-group-of-the-hour the attention they so badly want.
Completely agree; there’s an ancient law of the internet which seem to be forgotten nowadays: don’t feed the trolls. Giving a news entry on a news site such as OSNews is definitely troll feeding.
Corporate insecurity doesn’t go away if people stop speaking about it.
The Anonymous group provides a natural venue for highlighting corporate insecurity, albeit in a harmful way. I’ve never condoned what they do, but looking at this pragmatically, the world would not be safer with them out of the picture; eliminating this media driven group will not eliminate the crackers who operate underground out of the spotlight.
I ask this question in earnest: who should take corporations to task for poor security?
Edited 2011-07-05 08:22 UTC
Well, I’ve gotten more proactive with my password management due to all this, so hey, it has had its positive effect on me.
The world isn’t safer with them in the picture, either.
Unless there was something that actually concerned the public on the server (like users accounts) this stunt hasn’t really made the world safer.
I find this line of reasoning quite curious. It’s a little like arguing that there’s a good thing that there are criminals who can make us aware that, uh, there is crime.
Not people who think it’s “fun” to be irresponsible and post login details on pastebin, that’s for sure.
Soulbender,
“I find this line of reasoning quite curious. It’s a little like arguing that there’s a good thing that there are criminals who can make us aware that, uh, there is crime.”
Well let me ask you this, would you prefer the media to kept a lid on corporate security failures?
“Not people who think it’s ‘fun’ to be irresponsible and post login details on pastebin, that’s for sure.”
Ok, but you didn’t answer the question.
No, but there’s responsible reporting and then there’s self-aggrandizing sensationalism. The former is helpful, the latter isn’t.
You know what? I dont know but I do know that I do not want Lulz and similar morons handling it.
Looks like the free market is working just well. People highlight the flaws of a manufacturer then the manufacturer gets embarrassed and people know to avoid said manufacturer.
SHA1 is a one way hash like MD5. So can’t get passwords from it, its pretty much useless to the hacker.
All the google results are pointing to the same hacked paste dump. How do you figure that they are not salted from that?
Edited 2011-07-05 02:59 UTC
siimo,
“SHA1 is a one way hash like MD5. So can’t get passwords from it, its pretty much useless to the hacker.
All the google results are pointing to the same hacked paste dump. How do you figure that they are not salted from that?”
It may not be possible to reverse the SHA1 hash *directly*, but it is possible to enumerate password combinations to build a reverse index.
Attackers have databases of enumerated passwords (many gigabytes to terrabytes in size) which are organized to allow one to effectively look up the original text for any SHA1 hash which was enumerated during the generation of the database.
I found an interface to one such database here:
http://www.hashcrack.com/
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d -> “hello”
Note that you have to hash values without a CR:
> echo -n “hello” | sha1sum
If you have an SHA1 hashed password, it is very likely you can obtain the original password.
edbd1887e772e13c251f688a5f10c1ffbb67960d -> “secretpassword”
The difference with “hash salting” is that each uniquely salted password would need it’s own index of cleartext->hash values. So at the very least an attacker would have to generate a new hash database from scratch for each unique salt instead of using a pre-existing database.
However even salting alone is insecure since building the reverse index is feasible using free software. A single desktop processor can try over 10M hashes/sec. That’s nearly a trillion per day. A cluster (or running on amazon S3) will crack a salted password in very little time.
The solution is to make the the hash function much slower by applying it recursively. Therefor it takes far more resources to generate the reverse index. However it cannot be too slow otherwise it will effect the legitimate use of the hash.
Edited 2011-07-05 05:01 UTC
Informative, but a minor quibble: echo -n suppresses a newline, not a carriage return.
Actually, no. A sufficiently long salt (say at least 48 bits) makes pre-computed attacks unfeasible.
Of course, combining salting with key-stretching (as in bcrypt) makes it even more unfeasible.
Soulbender,
“Actually, no. A sufficiently long salt (say at least 48 bits) makes pre-computed attacks unfeasible.
Of course, combining salting with key-stretching (as in bcrypt) makes it even more unfeasible.”
This is not strictly true. You seem to be assuming that the salt is secret, however in a scenario where an attacker gets in through a web application vulnerability, the attacker will have access to the salt and will be able to build the reverse hash indexes based on it.
Consider the practical differences to the attacker who’s building a reverse index.
foreach password {
insert hash->password where hash=H(password)
insert hash->password where hash=H(salt+password)
}
Salting alone does not create the computational complexity required to foil a permutation attack. In fact it’s doubtful even to increase the complexity by a factor of 2.
What is needed is a way to increase forward hashing complexity such that building an index becomes prohibitively expensive and time consuming.
As I mentioned earlier, applying hash algorithms recursively is an effective way to do this. There are many possible variants of this idea, here are the two most obvious:
H(H(H(H(salt+password))))
H(salt+H(salt+H(salt+H(salt+password))))
You’re disagreeing with what most cryptographers say.
Look at bcrypt. it does what I presume you’re after.
“You’re disagreeing with what most cryptographers say.”
What specifically makes you say that? I have a strong background in cryptography, but I don’t think this is necessary to understand why salting doesn’t preclude a reverse permutation attack.
I assert:
1. A reverse hash index can be generated for plain password hashing (as evidenced by the link above). True/false?
2. The salting doesn’t add significantly to the (time) complexity for forward hashing. True/false?
3. A reverse hash index can be generated for salted passwords in the same way it can be generated for unsalted passwords. True/false?
If any of these are false, please explain why you think so.
“Look at bcrypt. it does what I presume you’re after.”
I looked it up, but it’s a file encryption utility and I’m not really clear about exactly you wanted me to look at.
I’m not “after” anything. Just pointing out that H(salt+password) is vulnerable to the same dictionary type attacks as H(password)
If someone were to ask me, I’d advice them to use an SHA2 HMAC for salting with no less than 1K iterations. 10K iterations would be better (and still only take 1ms to compute at login).
If a permutation attack previously took 2 days on a given cluster, it would now take 20,000 days (or 56 years) on the same cluster.
Of course, we’re assuming the attackers even care about the passwords, which they may not since they’ve already obtained elevated privileges by this point.
Edited 2011-07-05 21:36 UTC
Obviously true.
False. Salting significantly increases the time and complexity of creating the tables. See below.
If it didnt add anything significant it wouldn’t be recommended practice.
True but you would need one rainbow table for each possible salt. The longer the salt, the more tables needed. This is why salting defeats rainbow tables in practice.
Oh right, there are more than one “bcrypt”.
http://en.wikipedia.org/wiki/Bcrypt
Soulbender,
“False. Salting significantly increases the time and complexity of creating the tables. See below.
If it didnt add anything significant it wouldn’t be recommended practice.”
That’s not precisely what I said, I asked specifically about forward hashing complexity. I did edit my post by adding “time” in parens, but I guess it was too late.
I’d like to enter into evidence the following PHP example (apologize in advance for formatting bugs):
function NullHash($password, $salt) {
return $salt.$password.$salt;
}
function Unsalted($password, $salt) {
return hash(‘sha256’, $password);
}
function SimpleSalt($password, $salt) {
return hash(‘sha256’, $salt.$password.$salt);
}
function HMACSalt($password, $salt) {
return hash_hmac(‘sha256’, $password, $salt);
}
function RunTest($function, $name) {
$password = ‘superbadass’;
$salt = ‘kk222929’;
$time = microtime(true);
for($i=0; $i<1000000; $i++) {
$function($password, $salt);
}
$time = microtime(true) – $time;
printf(” %10s %10.3s\n”,$name,$time);
}
for($trial=0; $trial<3; $trial++) {
print “\nTrial $trial\n”;
RunTest(NullHash, ‘NullHash’);
RunTest(Unsalted, ‘Unsalted’);
RunTest(SimpleSalt, ‘SimpleSalt’);
RunTest(HMACSalt, ‘HMACSalt’);
}
The output for me is as follows:
Trial 2
NullHash 0.7
Unsalted 1.9
SimpleSalt 2.1
HMACSalt 4.4
Now, PHP is a terrible choice for doing this sort of benchmark due to high string overhead. But the prototype was quick and I believe my point stands.
The unsalted and simple salt algorithms have nearly the same forward hashing performance. The HMAC algorithm (which calls the sha hash twice under the hood) is slower by roughly a factor of two.
This shows that forward hashing is not significantly affected by adding salt. If you buy all this, then the answer to my second assertion is true.
“True but you would need one rainbow table for each possible salt. The longer the salt, the more tables needed. This is why salting defeats rainbow tables in practice.”
I wasn’t really talking about “rainbow tables” specifically, I was talking about indexes like the one in the link I provided.
A rainbow table discards information in a time/space tradeoff and is therefor a subset of a more complete index. Whether or not they are effected by salt probably depends on the salting algorithm and the way in which the rainbow tables are generated. But this does not affect a dictionary permutation attack.
Soulbender,
I did some research on bcrypt. I guess I should have realized that you were talking about a replacement for the original unix crypt, which is surprisingly still very common.
bcrypt is designed to impede brute force scanning by slowing down forward hash computation. It also uses a large salt size, unlike crypt which is embarrassingly small with only 4096 possibilities.
http://www.openbsd.org/papers/bcrypt-paper.ps
“Bcrypt uses a 128bit salt and encrypts a 192bit magic value. It takes advantage of the expensive key setup in eksblowfish”
It repeatedly encrypts the cleartext 64 times and has a specifiable cost parameter to slow down the hashing further.
Along the way I came across another “scrypt” which is said to be better than bcrypt on account of being not only computationally intense, but also by having much higher ram/state requirements. This is said to make custom ASIC processor design that much more difficult, since these often have limited states.
I think both of these would be fine for password hashing.
I still consider H(salt+password) to be vulnerable against moderately resourceful attackers since forward hashing is way too quick.
My understanding is that it works something like this:
1) You have a hashed version of a password (and you don’t know the real password), E.g. 81dc9bdb52d04dc20036dbd8313ed055
2) In the past, you’ve also created hashes from a large number of common passwords (dictionary words, given names, etc), giving you a database listing the plain text passwords in one column and the hashed output in another column.
3) You look up “81dc9bdb52d04dc20036dbd8313ed055” in this collection and notice that it’s the same hash you get when running MD5 on the password “1234”.
The “googleable” part comes in at step 2, I’d imagine: instead of creating the list of un-hashed and hashed passwords yourself, you just google “81dc9bdb52d04dc20036dbd8313ed055”, under the assumption that someone has already done that work and posted the details online.
Lo and behold, the first google result shows the un-hashed text right in the summary:
“Google Hash. md5(1234) = 81dc9bdb52d04dc20036dbd8313ed055”
OSNews went from Apple, Apple, Apple (iPhone, fights on our freedom, iPad), to cell phones, cell phones, cell phones (Nokia selling out to Microsoft, lots of bitch-fighting between companies over patents, etc.), to hacking, hacking, hacking (Anonymous here, LulzSec there). And now back to Apple… getting hacked. Yay. Whoopty damn do, who cares? Seriously, the news stories on this site are getting incredibly boring to the point where I just don’t give a damn any more.
Where did all the interesting articles go?
UZ64,
Yea, today there is so much hype over stupid devices I can’t stand it either.
Everyone says that computing moves fast, but all I see is a bunch of tech companies playing monkey in the middle with us. They go back and forth between the same ideas for decades and then treat them like new each time. Computing breakthroughs are a whole lot more innovative the first time round. There were certainly more opportunities then. Today a handful of dominant companies get all the credit and attention.
You do know you are free not to read OSNews, right?
.
You could also submit articles yourself, of course.
I think it’s okay to complain. It’s just like if you don’t like how your country is being governed, it a cop-out to say “if you don’t like it, why don’t you move to [insert enemy country here].”
However, we can only report on what’s going on in tech today. If what’s mostly happening is mobile, or apple, or hacks, then that’s what we’ll talk about. Of course, we rely on our readers to draw our attention to other topics. See that “submit news” link in the upper right hand corner of the screen? Use it!
Oh yes, of course it’s fine to complain – I just meant that nobody is forcing you to read things you may not like.
And for the rest… Well, there have always been certain waves in tech reporting. Complaints about too much Ubuntu news… Too much Mac news… Too much Windows 7 news… Too much gadget news… I’m not a particular adget freak either, but that is where the focus lies in the tech world at the moment – I don’t think anyone on the team can really help that.
At least Windows, Mac OS and Ubuntu are operating systems. At times I’ve got slightly tired of hearing about Ubuntu, but at least it fits for one thing, and it’s not a damn gadget. With Ubuntu’s bizarre, stupid ideas the last several versions and for the future though, Ubuntu is getting on my nerves now. But I don’t think I’d complain about an Ubuntu article, because it’d probably still be better than the crap posted lately…
I don’t mind hearing about “gadgets” every once in a while, but I swear–sometimes that’s all there is to read here, and to make it worse it’s often about ONE gadget from ONE company, or lawsuits between massive telecommunications companies.
I’ve actually been finding DistroWatch Weekly to be more interesting than OSNews lately, and it used to be the other way around. Too bad it’s only a weekly publication.
Edited 2011-07-05 18:34 UTC
IOS, Android, and webOS are also operating systems. Other than that, the legal stuff and hacking is sadly a large part of the tech world today, and it will have a massive impact on it in the years to come. It would be dishonest not to report on it.
I understand you don’t like the topics, but I can’t change that. I like writing about them, and as it stands today, that means OSNews will be full of them, since I pretty much AM OSNews.
Not reporting on current affairs isn’t dishonest, it’s useless as it’s news most “other” sites are also reporting.
What those sites don’t report is the new release of FreeDOS, which did make it on this site. That’s where the value of this site is (well, should be IMHO): reporting interesting OS stuff the mainstream sites don’t notice or care about.
Oh, I know. And that will be the next step if OSNews articles continue to be the same pointless crap. I’ve noticed the site always seems to go through ups and downs when it comes to articles, but this time the downs are just not going away. Therefore the complaining… and if this trend continues… I’m outta here. It seems that even Slashdot is more worthy of reading these days. And for the longest time, OSNews was constantly putting up articles of actual interest.
Yeah, I know, I know… who cares. Just another viewer gone.
How often does news speicfically about OSes come out, do you think? If you’re looking for the latest (boring) news on advancements in the Linux kernel, there’s a mailing list for that.