Monster.com breached

In late January, our friends at Monster were victims of a data theft covering an unspecified (but large) number of users. Because Monster also provides the USAJobs.gov website, it was also subject to the attack.

The first question everyone wants to know is, of course, “How many accounts were compromised?” Unfortunately, Monster has not been forthcoming about the magnitude of the breach, which could be intentional, or more likely, because they don’t know themselves (much like the Heartland breach I wrote about earlier). That tells me that, in theory, it could have resulted in the compromise of every single account in Monster’s system, and in fact, that’s my guess as to what really happened. In any case, with no additional data, it’s certainly what I’m forced to assume.

This looks like a basic database theft, where the attacker managed to get access to the Monster user database and steal basic demographic data, such as names, e-mail addresses, and so on. Monster asserts that passwords and SSN’s were not stolen, but this is belied by the password-change requirement that Monster imposed on all users (all) only five days after the break-in. Another article states that passwords and SSN’s were not compromised because they were encrypted (although it doesn’t identify a source for this information).

Time for a quick technical digression about encrypted fields in databases. A lot of sites will advertise that their passwords or SSN’s are stored encrypted in their databases. This is usually technically incorrect; typically, they’re stored as a one-way cryptographic hash, often using MD5, although sometimes using SHA-1 or something more exotic. These algorithms are great for finding a checksum (like a fingerprint) of a block of text, such that if you change anything about the text, the checksum will change with it. It’s Very Hard to take a given checksum and find a block of text with that checksum, although of course (way) more than one block of input text can have the same checksum. However, a good hash function tends to limit these collisions as much as possible.

So, great: in theory, everyone’s password and SSN are MD5′d before being stored in the database. In actual practice, that doesn’t matter as much as you’d think. The reason is that  you have to consider both the domain and the range of the function. Yes, the range (output) is very random-looking and is distributed over the 128-bit (or 160-bit, for SHA-1), but we know something special about the domain. For SSN’s, for example, it’s a number between 1 and 1,000,000,000. So, if you tried every single number, on average you’d have to try half of them before you found a match, meaning that the effective security of that “encryption” is the amount of time it takes your computer to do 500,000,000 MD5 sums. That is not that long any more.

You can guard against mass-cracking by salting your hashes. This is quite helpful, because the bad guy has to compute and store the checksum for (with a 32-bit salt) over 4 billion different versions of every possible SSN or password. Still, with SSN’s anyway, there are only a billion combinations (a little less than 2^30), each of which is a number that can be stored in 4 bytes (less, if you’re clever). You can think of it as a 62-bit key. There are some interesting combinations of pre-computed tables and on-the-fly processing that can yield some workable attacks even against keys this long.

All of a sudden, Monster’s warning that users change their passwords looks a little more serious. If the Bad Guys are 200 playstations away from being able to brute-force your password, you’re in trouble. Same goes double with your SSN: Monster already admitted to the theft of names, addresses, and dates of birth. That, plus a cracked SSN, is all the Bad Guy needs to get credit, or to do a variety of other nasty things.

But wait, there’s more! According to one stat I’ve heard, 41% of people use the same password on every website they use. Wow! Furthermore, I’d bet the number goes way up when you factor out the high-security sites like banks. Put another way, even if you’re in the other 59%, I’d bet a lot of people have the same password on Monster as on their e-mail account. And think about that for a second… where do you think all of those “I forgot my password” reset e-mails go? Yep, losing your e-mail account to a Bad Guy is just about as bad as it gets.

So, what do you do? For starters, quit using the password you used at Monster, forever. Change every password you have. Change all of your “secret” security questions and answers everywhere you can. And, of course, keep an eye on your bank accounts, credit card statements, and so on.

There are a couple of other things that can be done, as well. Websites that use two-factor authentication for login security are a big help, of course. You can also help mitigate the problem by using services like OpenID for login to sites that support it. That way, you only have to maintain your password in one place. And what’s more, if you use the right OpenID provider, you can get two-factor authentication for it. That leaves you in a particularly good position, at least for sites that accept OpenID.

And as for Monster… they saw fit to make everyone change their passwords (presumably because they could be compromised, as I described above), but they didn’t see fit to proactively notify users or buy ID theft protection for them, even though SSN’s are only 30 bits long, vs. your average 8-character password with at least one capital and one symbol, coincidentally also estimated to have 30 bits’ worth of entropy.

Fourth break-in in two years. Just sayin’.

How to lose 100M transactions a month to the Bad Guys

Over the last few years, there have been several high-profile data thefts resulting from Bad Guys stealing credit card numbers in bulk. There was CardSystems a couple of years ago, and of course, the 90+ million stolen numbers from TJX.

Well, on January 20th – during the President’s inauguration – Heartland Payment Systems announced what may be the largest loss of credit card information ever: 100 million transactions a month! It’s theoretically possible that more cards were compromised in one month’s time than in the entire three years that the TJX systems were being attacked. Over 220 banks have issued notices to cardholders that their cards were affected. And, of course, the predictable class-action lawsuits have been filed.

Details have been sketchy, but I’ve read a few snippets here and there that give me a good guess or two as to how this happened. But first, some background.

The payment card industry imposes on itself certain data security standards, called (creatively enough) the Payment Card Industry Data Security Standard, or PCI DSS. PCI lays down a number of requirements that must be followed by card issues, processors, and the merchants that accept these cards. The standards require formal audits and certification, and having been through a few of them, I can tell you that they’re very specific as to what minimum level of security must be in place.

Among other things, the PCI DSS standards were designed to avoid precisely what happened at TJX, CardSystems, and now at Heartland: the mass loss of cardmember data.

So, what happened? Are PCI DSS standards useless? Well, the attack on Heartland worked because of an issue that the standards don’t address: the Bad Guys snooped on data as it was moving from one (presumably secure) system to the next. Data “in flight” is not required to be protected in any special way, as long as it’s moving within an organization between two secure systems. Furthermore, due to the way the payment card industry has evolved over the years, handing off data from one organization to another sometimes requires that there be no data encryption in place.

So, that’s the vulnerability in the standard that it appears the Bad Guys exploited. How’d they pull it off?

At this point, Heartland is being coy about the details, but they have said that they discovered an eavesdropping-style attack that had been going on for an unknown period of time. As in, this thing could have been there for months. The Bad Guys managed to find a way to tap into the data network inside Heartland at a point where the data was in the clear. Once they had the data in their hands, they simply needed a way to get it back into the Bad Guys’ hands. There are a number of possibilities here, including low-bandwidth uploads to a drop site on the internet, or even easier, uploads via a 3G cellular modem like a Verizon air card. Does this sound similar to the ATM skimmers I wrote about earlier? It should!

So, the only question left is how they got the data. Here, there are a couple of possibilities. The Bad Guys could have found a way to sneak a kind of program called a protocol analyzer onto a vulnerable system – or they could simply have used a built-in analyzer like tcpdump. Then, any captured data could simply be read from that analyzer and uploaded as described above. While the PCI DSS specs require some degree of binary checksumming (a way to make sure that the files on the computer haven’t changed), I’m not sure if Heartland would have detected new binaries. 

The other possibility is using dedicated hardware to do the analysis. It could be as simple as one extra box on a rack, cabled into an analysis port on a switch – something that the Good Guys may never have noticed – or something even more elaborate, such as a passive RMON probe tap. Either way, we’re talking about ZERO specialized pieces of hardware; even the RMON probes can be built out of parts from your local MicroCenter.

A set-up like this might have gone undetected forever. In fact, it probably would have, had the Bad Guys been just a little bit more careful with the information they stole. You see, it turns out that Heartland was NOTIFIED that something bad was going on. A measurable uptick in fraudulent activity was noticed and reported to them months before their January 20 release. It took a specialist team – two of them, if you believe the press release – to take apart the network and find the bug. If the Bad Guys did their jobs right, this should be very very difficult to trace back.

What data was compromised? The Bad Guys got the information from the cards’ magnetic stripes. I wrote about mag stripe skimmers before, and all of the same considerations apply here. As to exactly what they got, it’s a virtual guarantee that the Bad Guys got card numbers and expiration dates. Some transactions likely included the Track 1 data from the card, which includes your name. Finally, there is room in the encoding for the card’s security code, although it’s not clear from reports whether that information was in the compromised data stream.

The most important question, though, is what to do about all of this nonsense. Start by assuming the worst – the Bad Guys have your name, your credit card number, expiration date, and maybe your card’s security code. This isn’t the end of the world in itself, but you DO have to take action to prevent this from causing you trouble down the line. While this is not specifically a major identity theft event, as it stands, it COULD impact your credit report if a Bad Guy uses your card without your knowledge. 

Furthermore, it’s the cardholder’s responsibility to monitor activity on each statement, and to report anything that looks suspicious. That could be easy if you use  program like Quicken to download and manually approve every transaction on every card you us – this is what I do – or it could be exceedingly difficult, to the point of futility, if you have lots of transactions on a card and get paper statements each month. The other danger scenario is if you have extra cards that you never use and therefore don’t monitor. Waiting too long to report fraudulent activity could cost you money.

Heartland declined to provide credit monitoring services to affected users. Partly, that’s because they probably can’t tell who has been affected, since they have no idea when the analyzer was installed. But whatever the case, I think they’re wrong: good credit monitoring services can let you know whenever a negative mark is made on your credit file. It can be much easier to address issues like this immediately, rather than waiting a couple of years and then wondering why your home mortgage application was rejected.

Of course, the best defense is to add a second factor of security to the card itself. Using a transaction confirmation system for risky or nonstandard transactions can go a long way toward preventing any credit problems.

Finally, if you ARE affected by this mess, you should have your bank issue new cards under new account numbers. In fact, you should consider replacing ALL of your cards, since it may be hard to tell which card you used at which merchant during which time period.