Mar 22, 2008

Hannaford Supermarkets


This is going to get very interesting. Hannaford Supermarkets announced on Mar 17 that they lost 4.2 million card numbers to a hacker (Began Dec 7, discovered on Feb 27) . They also claim to be certified as compliant with PCI DSS. So what value does the certification hold ?

Instead of saying PCI is worthless, lets step back for a minute and think about this. If this was an inside job, PCI Co can't be blamed. Also, as it stands today, the QSAs/ASVs can claim that their assessment was a point in time and as such, they shouldn't be held responsible for a company getting hacked after they gave it a clean chit. Change that and watch the number of QSAs/ASVs drop like a brick, and PCI Co get better value out of these QSAs and ASVs.

Lets see what the Hannaford CEO Ron Hodge said
"
Hannaford has contained a data intrusion into its computer network that resulted in the theft of customer credit and debit card numbers. No personal information, such as names or addresses, was accessed. Hannaford doesn’t collect, know or keep any personally identifiable customer information from transactions.

We sincerely regret this intrusion into our systems, which we believe, are among the strongest in the industry. The stolen data was limited to credit and debit card numbers and expiration dates, and was illegally accessed from our computer systems during transmission of card authorization.

"

Huh ?

No personal information such as names or addresses was accessed.

If that is the case, the authorizations should fail for most transactions of medium to high value when those numbers are reused since they don't have the name (I say most - because most auth engines typically use a complicated formula depending on location of purchase, amount of purchase, a margin for errors in reads during swipes etc before authorizing a transaction).

[Interesting Update: According to this article, there are around 1800 cases of related fraud so far, and they talk about a $1270 charge going through. Which really means there are authorization engines out there that don't seem to care about the customer name in a transaction. Either that, or someone is lying.]

Could there be a sniffer installed on the network ?

Track data has your name, card number, expiration date and encrypted IPIN among other things. If a sniffer was present at the swipe location, it surely would've got the name. But he clearly states no names were accessed. But what if it was in the scenario described a few posts below - about the ATM authorizations ? If you look at the message formats, they have card numbers and expiration dates. What was compromised ? Card numbers and expiration dates. (ISO 8583 seems to have track data in its message transmissions - but not until a long way into the stream, and for some reason, I didn't notice it in my raw transaction data log review. The attackers probably just captured the initial bytes of the transmission ?)

"But they were PCI Compliant and hence would've had to encrypt their data in transmission" you say.

Thanks to the vagueness of PCI, even if rule 4.1 were to be applied -
Use strong cryptography and security protocols such as secure sockets layer (SSL) / transport layer security (TLS) and Internet protocol security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks.

Could they have used the excuse that the network was not open or public ? And then - they could always use the compensating controls excuse to not encrypt.

I'm willing to bet there was some form of sniffing involved - and this probably is sniffing of the POS/ATM transaction in the ISO8583 format. (a scenario I was afraid of in this post)



2 comments:

Dave said...

"If a sniffer was present at the swipe location, it surely would've got the name."

Many terminals and point of sale systems send Track 2 data instead of Track 1. Track 2 doesn't contain the name:
See: http://www.acmetech.com/documentation/credit_cards/magstripe_track_format.html

DB
www.paymentsystemsblog.com

Random InfoSec Guy said...

Good point, dave. I was under the assumption that Track 1 data is read at swipe. If it is indeed only Track 2 that is sent, it would imply that name matching is *never* done at auth for "Card Present" transactions ... wow.