May 07, 2007

WSJ: Soft evidence on a crypto-related breach

Unconfirmed claims are being made on WSJ that the hackers in the TJX case did the following:

  1. sat in a carpark and listened into a store's wireless net.
  2. cracked the WEP encryption.
  3. scarfed up user names and passwords ....
  4. used that to then access centralised databases to download the CC info.
The TJX hackers did leave some electronic footprints that show most of their break-ins were done during peak sales periods to capture lots of data, according to investigators. They first tapped into data transmitted by hand-held equipment that stores use to communicate price markdowns and to manage inventory. "It was as easy as breaking into a house through a side window that was wide open," according to one person familiar with TJX's internal probe. The devices communicate with computers in store cash registers as well as routers that transmit certain housekeeping data.

After they used that data to crack the encryption code the hackers digitally eavesdropped on employees logging into TJX's central database in Framingham and stole one or more user names and passwords, investigators believe. With that information, they set up their own accounts in the TJX system and collected transaction data including credit-card numbers into about 100 large files for their own access. They were able to go into the TJX system remotely from any computer on the Internet, probers say.

OK. So assuming this is all true (and no evidence has been revealed other than the identity of the store where it happened), what can we say? Lots, and it is all unpopular. Here's a scattered list of things, with some semblance of connectivity:

a. Notice how the crackers still went for the centralised database. Why? It is validated information, and is therefore much more valuable and economic. The gang was serious and methodical. They went for the databases.

Conclusion: Eavesdropping isn't much of a threat to credit cards.

b. Eavesdropping is a threat to passwords, assuming that is what they picked up. But, we knew that way back, and that exact threat is what inspired SSH: eavesdroppers sniffing for root passwords. It's also where SSL is most sensibly used.

c. Eavesdropping is a threat, but MITM is not: by the looks of it, they simply sat there and sucked up lots of data, looking for the passwords. MITMs are just too hard to make them economic, *and* they leave tracks. "Who exactly is it that is broadcasting from that car over there....?"

(For today's almost evidence of the threat of MITMs see the BBC!)

d. Therefore, SSL v1 would have been sufficient to protect against this threat level. SSL v2 was overkill, and over-expensive: note how it wasn't deployed to protect the passwords from being eavesdropped. Neither was any other strong protocol. (Standard problem: most standardised security protocols are too heavy.)

TJX and 45 million americans say "thanks, guys!" I reckon it is going to take the other 255 million americans to lose big time before this lesson is attended to.

e. Why did they use a weak crypto protocol? Because it is the one delivered in the hardware.

Question: Why is hardware often delivered with weak crypto?

f. And, why was a weak crypto protocol chosen by the WEP people? And why are security observers skeptical that the new replacement for WEP will last any longer? The solution isn't in the "guild" approach I mentioned earlier, so forget ranting about how people should use a good security expert. It's in the institutional factors: security is inversely proportional to the number of designers. And anything designed by an industry cartel has a lot of designers.

g. Even if they had used strong crypto, could the breach have happened? Yes, because the network was big and complex, and the hackers could have simply plugged into some place elsewhere. Check out the clue here:

The hackers in Minnesota took advantage starting in July 2005. Though their identities aren't known, their operation has the hallmarks of gangs made up of Romanian hackers and members of Russian organized crime groups that also are suspected in at least two other U.S. cases over the past two years, security experts say. Investigators say these gangs are known for scoping out the least secure targets and being methodical in their intrusions, in contrast with hacker groups known in the trade as "Bonnie and Clydes" who often enter and exit quickly and clumsily, sometimes strewing clues behind them.

Recall that transactions are naked and vulnerable . Because the data is seen in so many places, savvy FCers assume the transactions are visible by default, and thus vulnerable unless intrinsically protected.

h. And, even if the entire network had been protected by some sort of overarching crypto protocol like WEP, the answer is to take over a device. Big stores means big networks means plenty of devices to take over.

i. Which leaves end-to-end encryption. The only protection you can really count on is end-to-end. WEP, WPA and IPSec and other such infrastruction-level systems are only a hopeful answer to an easy question, end-to-end security protocols are the real answer to application level questions.

(e.g., they could have used SSL for protecting the password access to the databases, end to end. But they didn't.)

j. The other requirement is to make the data insensitive to breaches. That is, even if a crook gets all the packets, he can't do anything with them. Not naked, as it were. End-to-end encryption then becomes a privacy benefit, not a security necessity.

However, to my knowledge, only Ricardo and AADS deliver this, and most other designers are still wallowing around in the mud of encrypted databases. A possible exception to this is the selective disclosure approach ... but for various business reasons that is even less likely to field than Ricardo and AADS were.

k. Why don't we use more end-to-end encryption with naked transaction protocols? One reason is that they don't scale: we have to write one for each application. Another reason is that we've been taught not to by generations: "you should use a standard security product." ... as seen by TJX, who *did* use a standard security product.

Conclusion: Security advice is "lowest common denominator" grade. The best advice is to use a standard product that is inapplicable to the problem area, and if that's the best advice, that also means there aren't enough FC-grade people to do better.

l. "Oh, we didn't mean that one!" Yeah, right. Tell us how to tell? Better yet, tell the public how to tell. They are already being told to upgrade to WPA, as if improving 1% of their network from 20% security to 80% security is going to help.

m. In short, people will seize on the encryption angle as the critical element. It isn't. If you are starting to get to the point of confusion due to the multiplying conflicts, silly advice, and sense of powerless the average manager has, you're starting to understand.

This is messy stuff, and you can pretty much expect most people to not get it right. Unfortunately, most security people will get it wrong too in a mad search for the single most important mistake TJX made.

The real errors are systemic: why are they storing SSNs anyway? Why are they using a single number for the credit card? Why are retail transactions so pervasively bound with identity, anyway? Why is it all delayed credit-based anyway?

Posted by iang at May 7, 2007 02:27 PM | TrackBack

aside from the issues AADS and X9.59 financial standard protocol

providing transaction armoring for naked transactions

so they are no longer vulnerable to evesdropping and
replay attacks

there is this recent item:

New Weakness in 802.11 WEP

which claims that it has an attack against what is being proposed for WEP2.

the referenced website:

may be suffering from having been "slashdot'ed" ... since it haven't been responding.

Posted by: Lynn Wheeler at May 7, 2007 05:47 PM

that was a blockbuster post !

it's funny, perhaps the whole bizarre edifice of Visa/MC payment model as we know it now will have to be changed.

is it a case where centralisation is logical and the only way?

You often mention DGCs on the blog - with DGCs of course, obviously, everything about the payment is handled (newsflash!) -- BY THE DGC.

If customer C tries to buy a book in bookshop B using DGC D, then of course - obviously, duh - C communictes with and only with -- again, "duh!" --- D. It's All About C and D.

The Payment has no involvement at all between C and B - it's a Payment! C, a customer of D is making a Payment at D. It's all C-D .. no B.

After a whole lot of interaction between C and D, D establishes that indeed C "has made a payment." Then, as an unimportant afterthought (it can be checked later if there's a woe), D just let's B know that C did in fact make a payment.

Note that in all this, in the DGC universe, it is totally inconceivable that D would farm out part of the function of the payment to B ("what??!"), or that B could somehow "take the payments" ("huh??"), or that B would have something to do with "processing the payment" ("sorry?!?"), or that B would use some other set of companies to help do the payment ("WTF??") .....

of course, obviously, duh, give me a break, etc .... the bloody payment is of course handled entirely by D!!

With cards, the whole situation is risible .... other entities, even the Merchant (no - seriously!) are involved in the Payment; rather than just the Payer and the Payment System.

I suppose the reason is that nowadays we live in an "online" world. Movies are edited "online" (old-fashioned "offline editing" is history), heart patients get monitored in real time, and "maps" in your car now show you where you are with a pointer, they are online.

So, in our "online" world of today, anyone thinking of starting up a payment system (such as the DGC universe did), of course just obviously assumes that a Payment is done by the Payer and Payment System - and it would be ridiculously whacky if the (no, really) Merchant, or anyone else, was involved in that for any reason. There's no other way you'd think about it. You'd never in a million years think about the merchant (or anyone else) being involved.

When credit cards were invented, I guess it was still an offline world (hard to imagine) (remember checks, "clearing", etc etc?) ...... so for that reason the total epic KLUDGE that is credit card processing 2007, with madness like the merchant, processing companies, banks, and so on being involved with the Payment, that we see today.

Surely there's enough fiber around now that Visa/MC will just say "screw that" and move to a ("normal, sane") online model?? No? Has the time come?

Posted by: Jape at May 8, 2007 02:53 AM

> > e. Why did they use a weak crypto protocol? Because it is the one
> > delivered in the hardware.
> >
> > Question: Why is hardware often delivered with weak crypto?

Because of 2 simple reasons.

Firstly they failed to garner "real" crypto input when designing WEP and I believe the handshaking etc is attacked rather then the actual algorithm (RC4).

Secondly RC4 was cheap (in terms of CPU cycles), and only requires about 10 lines of code, but again no attacks brute force the actual encryption, but focus on the implementation of it.

Oh and they believed no one could attack it because no one would be able to get their hands on equipment that could do it, but of course mass producing and selling equipment to connect can also be used to break it.

Posted by: Duane at May 8, 2007 03:47 AM

Shmoocon 07 had a presentation on what went on in the WEP design commitee.
Al Potter, Renderman, and Russ Housley "Standard Bodies - What are these Guys Drinking?"

The process and incentives were wrong, simply put - security concerns were there but voted down.

Posted by: fluortanten at May 8, 2007 04:41 AM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.