Risk
3/28/2008
03:44 PM
Connect Directly
LinkedIn
Google+
Twitter
RSS
E-Mail
50%
50%

Hundreds Of Servers Compromised In Hannaford Breach

More details about the credit breach at the Hannaford grocery chain are becoming known, and they aren't pretty.

More details about the credit breach at the Hannaford grocery chain are becoming known, and they aren't pretty.The Boston Globe reports that malware was installed on servers at every store in the Hannaford chain -- approximately 300 locations.

The details of the breach come from a letter sent by Hannaford's general counsel to authorities in Massachusetts.

According to the letter, the malware intercepted the credit card number and expiration date at the point of sale as it was being sent for authorization. The malware then sent batches of card numbers over the Internet to a foreign ISP.

The article calls the attack "new and sophisticated," but was it really? I'll grant that compromising hundreds of servers and then sniffing the point-of-sale traffic to gather the account data is pretty slick.

But it also seems to me that Hannaford's security processes failed in several areas where security processes just shouldn't these days.

First is the sheer number of servers compromised. There aren't any details in the Globe article about how the malware got onto the servers. If it was a remote intrusion, did the attackers exploit a known vulnerability? If so, how did Hannaford's vulnerability scanners miss it? The scale of the attack prompted some security professionals quoted in the article to speculate that it might have been an inside job.

And how about the malware? Perhaps this was a custom-written package, and so evaded anti-malware detection. But then there's fact that internal servers were transmitting outside the network to strange IPs. This should've raised flags somewhere -- server logs, IDS logs, firewall logs.

I realize it's easy to say the barn door should've been closed after the cow gets out, but server hardening and log review and analysis are Security 101.

PCI And The Law As if the breach weren't enough fun, Hannaford has to deal with two class-action lawsuits, including a suit filed by Berger & Montague, a firm that was also involved in a class action suit against TJX -- which TJX settled.

The suit alleges that Hannaford was "negligent for failing to maintain adequate computer data security of customer credit and debit card data."

Here's where things get interesting. Hannaford says it was certified PCI compliant in February 2008. If Hannaford is following industry best practices, that will make it harder, though not impossible, for the plaintiff to prove its case. (In fact, the lawyers don't really have to prove anything as they are probably gunning for a settlement. Given that every store in the chain was compromised and as many as 4.2 million card numbers could have been exposed, I'd wager they'll get it.)

Even more interesting is Hannaford's compliance status. The company says it was certified compliant a year ago, and was recertified compliant on Feb. 27 -- at the same time the breach was ongoing.

If Hannaford is a Level 1 merchant, that means a third-party assessor had to certify Hannaford as compliant. If this assessor certified Hannaford compliant while a breach was ongoing, does the assessor share any liability? You can bet the folks at Berger & Montague, and Hannaford's in-house lawyers, will be asking that question.

If Hannaford is Level 2 or 3, certification means filling out a self-assessment questionnaire and undergoing quarterly vulnerability scans. Maybe Hannaford's scanning vendor could get dragged in here.

We'll have to watch how these cases proceed. In any case, the whole mess should be very instructional to retailers everywhere.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2037
Published: 2014-11-26
Openswan 2.6.40 allows remote attackers to cause a denial of service (NULL pointer dereference and IKE daemon restart) via IKEv2 packets that lack expected payloads. NOTE: this vulnerability exists because of an incomplete fix for CVE 2013-6466.

CVE-2014-6609
Published: 2014-11-26
The res_pjsip_pubsub module in Asterisk Open Source 12.x before 12.5.1 allows remote authenticated users to cause a denial of service (crash) via crafted headers in a SIP SUBSCRIBE request for an event package.

CVE-2014-6610
Published: 2014-11-26
Asterisk Open Source 11.x before 11.12.1 and 12.x before 12.5.1 and Certified Asterisk 11.6 before 11.6-cert6, when using the res_fax_spandsp module, allows remote authenticated users to cause a denial of service (crash) via an out of call message, which is not properly handled in the ReceiveFax dia...

CVE-2014-7141
Published: 2014-11-26
The pinger in Squid 3.x before 3.4.8 allows remote attackers to obtain sensitive information or cause a denial of service (out-of-bounds read and crash) via a crafted type in an (1) ICMP or (2) ICMP6 packet.

CVE-2014-7142
Published: 2014-11-26
The pinger in Squid 3.x before 3.4.8 allows remote attackers to obtain sensitive information or cause a denial of service (crash) via a crafted (1) ICMP or (2) ICMP6 packet size.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?