Schneier on Security
A blog covering security and security technology.
« Friday Squid Blogging: Squid Cake |
| U.S. is One Small Step Closer to Making No-Fly List Less Harassing »
February 9, 2009
Monster.com Data Breach
Monster.com was hacked, and people's personal data was stolen. Normally I wouldn't bother even writing about this—it happens all the time—but an AP reporter called me yesterday to comment. I said:
Monster's latest breach "shouldn't have happened," said Bruce Schneier, chief security technology officer for BT Group. "But you can't understand a company's network security by looking at public events—that's a bad metric. All the public events tell you are, these are attacks that were successful enough to steal data, but were unsuccessful in covering their tracks."
Thinking about it, it's even more complex than that. To assess an organization's network security, you need to actually analyze it. You can't get a lot of information from the list of attacks that were successful enough to steal data but not successful enough to cover their tracks, and which the company's attorneys couldn't figure out a reason not to disclose to the public.
Posted on February 9, 2009 at 6:47 AM
• 23 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
It's far too early in the day, on a Monday no less, to be putting on the tinfoil...
But it does make you wonder if organized crime, with the help or at least toleration of foreign intelligence services, does any data aggregation of these various identity leaks.
Encrypted passwords are quite vulnerable if they're not using some still secret salt to rainbow attacks. Even with a salt with enough passwords, computing power, and time they're still crackable. Without having data in front of me, I'd guess most people use variations of the same password or a "theme."
What's the power of not only aggregating identity information like figuring out where people work, but also looking at several of their passwords you've stolen as plain text or decrypted over the last 10 years of state sponsored / tolerated cracking?
Now instead of a highly visible brute force attack against an account, you can try just the occassional attack using passwords you know the target has used, or common variations of them with a relatively high level of confidence...and do so over the course of years so you never reach the threshold for automated intrusion detection systems to issue alarms.
IOW: if you want to access an organization's network security, you need to _ATTACK_ it. My 2c.
Aren't there cracker bulletin boards where tips on vulnerable networks are exchanged? With a big enough community, quite a lot of security information could be gleaned that way. That's ruling out attacks that aren't based on insider information.
As regards successfully covering your tracks, I am reminded of the comment made many years ago about IBM's MVS operating-system:
"RACF (the MVS security system) has never experienced an unidentified security breach".
You may not be able to get a complete picture of their security, but doesn't it at least tell you what they did seriously wrong? In this case, for instance, the disclosure mentioned that passwords were definitely compromised. Which tells me that they left them in cleartext or with kid-sister encryption on them.
@ Matt from CT
"variations of the same password or a "theme." "
I've been doing that for 20 years now. Settled on the current "base password" back in college. It's not in the dictionary, not something guessable even by people who know me well. Sounds like an English word, but isn't. On my home machine I have a text file listing all the variations of it I use for the several dozen sites I use.
The file reads like:
pass usual+1v, substitute 4 for A.
So, sure, if you know "usual", and you can get access to my home machine, you can get all my passwords.
"if you want to access an organization's network security, you need to _ATTACK_ it"
Partly true, partly false.
Most ethical attacks are highly constrained (time, target, methods, risk appetite...).
An audit adds other dimensions.
1) Your attack is successful because a router had default credentials.
2) My audit shows that there is no hardening process as part of the build.
So now we have your effect, my probable cause, and together a good hint at a solution to the specific vulnerability you exploited, and many other generic 'weak by default' vulnerabilities you missed.
'It's far too early in the day, on a Monday no less, to be putting on the tinfoil...'
Security is 24x7, it's never too early for the tinfoil hat!
"Security is 24x7, it's never too early for the tinfoil hat!"
I agree; paranoia never sleeps.
I used to use (other people's) ham radio callsigns as passwords (for example AA5jkl); then all I had to do was remember the person I used. But nowadays thats too short to thwart brute force.
Just add a base infront or behind it :-)
Tell them to sign up with BT CP's pen test, we did. :)
I wouldn't mind but this is about the third time of late that its happened to Monster.com (that we know about anyway).
They're obviously not learning from their mistakes!
@bob - When I need a longer password, or some stupid system insists I use several types of character, I just add a smiley face on the end. For example:
That dang single letter misspelling, sure is a plausible deniable thingy.
Working in e-commerce for the last few years, you can be surprised from time to time! We were patching our web-servers for a M$ patch a week after the patch was issued, it took that long to get through DEV and QA (which is actually not a bad turn around with a cluster of our size.)We applied the update to all boxes, but we had not been able to power cycle them all before we were penetrated, as our firewall logs would eventually tell us. By that time it was too late, after the reboots we were no longer vulnerable, but the payload was delivered, and the backdoor was in place.
We found the compromise through a hacker slip up, and good event logs/triggers. The hacker made 3 failed SQL queries, which were followed up with, 2 weeks after they gained access!
I can empathize with some brake-ins because of my experiences with them. Again, we don't know the specifics of Monster's, but even if your doing all you can, as we were when we were in my anecdote above, your still vilified or told "this shouldn't of happened". It happens to the best of the best (like me ;) The tools hackers used on me/our client's site we home-grown, and "infected" good process's, so our process monitor didn't pick it up, and no AV def for it (still, even though we've submitted to everyone!)
We found the hack 2 weeks later, because of the failed query (1 misplaced quote!), it took a month to piece together what he/she was doing during those two weeks... We were doing things (patching, input sanitization, log watching) as fast as we could... Just like Kaspersky (recent news) might have been doing things like patching as fast as they can... it's never enough for the public/press :) Not everyone can afford BT/Counterpane, and even then, I don't think anyone offers a guarantee, and if they did, I know I'd never try that service because I know better than that.
>for example AA5jkl); then all I had to
>do was remember the person I used.
>But nowadays thats too short to
>thwart brute force.
You know, I'm not sure I'd even brute force a password like that if I was a state sponsored or otherwise well funded criminal organization.
AA5jkl's md4 (Windows NT) hash is 953f e146 060a f8a0 9754 7827 89c3 e456
I believe it's around 166 Terabytes in hashes generated by 16 character passwords.
You wouldn't even need a database to do the lookups -- chunk the job among a number of Linux hosts and partitions...something like:
text file 0af8
then just grep the a0 9754 7827 89c3 e456 part to find the corresponding plain text.
(Naming scheme is derived from the hash, with 256 hosts with 65k mount points with 65k directories in each with 65k files. I'm not sure off hand if we could have that many mounts/dirs/files, but it's a starting point)
It's relatively affordable -- to get a rough idea, I looked at the cost to host such an operation on Amazon's cloud. For the storage at $0.13/GB for 50-400TB a month, so that's $21,000. That they list pricing tiers for 500+ TB tells me they wouldn't be very concerned over a couple hundred TB being generated. 256 of their biggest, computationally powerful virtual machines would run $147,456. You would, however, have your own very happy Amazon salesman asking you if you want to go golfing in Hawaii or get superbowl tickets.
Yeah, it's out of the range of ordinary petty thieves for sure...but those numbers are not very intimidating -- you sure as heck wouldn't need to be the NSA to pull it off.
State sponsorship would make it easy, but to stray into movie plot territory for a moment it would be a lot cheaper to run then any of the plots SPECTRE ever tried in a James Bond flick.
Apply Moore's Law and figure in 4 years it'll be one fourth as expensive and it gets kind of scarey to think how vulnerable passwords are getting to be even if all you have is the hashes.
Thanks for sharing that story Rich!
It's a great real world example of the vulnerabilities out there when people are specifically focusing their efforts to penetrate particular companies with tools that slip under the conventional antivirus/intrusion detection systems.
I'm not sure if our client was a specific target, but the app(virus?) they used hooked Apache and IIS, we only use Apache... again no one has created a sig for it since (we did create one ourselves using ClamAV).
My basic sentiment with my story was, we do (and were doing then) all we could to keep up, patching, monitoring etc... We went through our "shoulda, coulda, woulda" phase after the incident. We should of had DEV try the patch sooner, we could of paid M$ for an early version of the patch, we would not of be hit... Maybe, who knows, from experience since that incident, it's not as cut and dry as that. If we were a specific target, maybe they would of had to try harder, but they might have gotten in with another vector... They only need to find one hole in your security, not all of them ;)
We reported the break-in even though we had no legal or regulatory reason to do so. We gave more detail too, but not every detail. We get lot's of attacks everyday, and as far as we know, these hundreds of unique attacks are not successful. Successful attacks have more weight than failed attacks.
AV is a bandaid on a cancer, we use it sparingly and rely more of Principal of Least Privilege. Another good thing for us is we don't store credit-card data and very minimal PII, so it was much less of a story.
@Matt from CT:
and thats why we salt passwords.
@ Bruce Schneier,
"... paranoia never sleeps."
Nor does Pandora...
@ Matt from CT,
"Apply Moore's Law and figure in 4 years it'll be one fourth as expensive..."
Err I think you will find that it will be a lot faster than that.
You've got a "Moore's law" on the CPU, the RAM and Hard Drives.
With the appropriate trade offs it could be at a quater the cost within 18 months.
The only real limit on this is the "base distribution" price that says that there is a minimum price a good can drop to at the point of retail.
Truly Scarey, I'd not tought of the possibility of Cloud computing for such things...
Considering that, I must needs rethink my passwords or put everything of concern behind 4096 bit key crypto and an impossibly long passphrase.
To quote Pinky: "Egad, Brain!"
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.