There goes another one.

According to multiple sources, the Hannaford Brothers grocery chain suffered a major breach with 4.2 million credit cards exposed. Hannaford had published an FAQ for their customers. Odds are it will be months until we find out what really happened, but I’m going to speculate anyway, pick apart the press coverage and FAQ, and see if we can learn something from this now.

As usual, the information released is incomplete and contradictory.

PORTLAND, Maine (AP) - A security breach at an East Coast supermarket chain exposed 4.2 million credit and debit card numbers and led to 1,800 cases of fraud, the Hannaford Bros. grocery chain announced Monday.

Hannaford said credit and debit card numbers were stolen during the card authorization process and about 4.2 million unique account numbers were exposed.

The breach affected all of its 165 stores in the Northeast, 106 Sweetbay stores in Florida and a smaller number of independent groceries that sell Hannaford products.

This is interesting since there is a direct tie to fraud, as opposed to many other breaches. This often means the fraud was detected in the credit system and then traced back to the retailer, which seems to be what happened based on the FAQ. As a researcher it’s always helpful to be able to tie the breach to illegal activity. This does, of course, suck for the victims, but as long as it’s credit card fraud they are protected.

Since the information was stolen during the authorization process, and was distributed over many locations, it means a compromise of the central authorizations system or the credit card processor. It could be as simple as sniffing unencrypted communications, or a more complex compromise of a database or application. My money is 70% on sniffing, 30% on something in the database.

No personal data such as names, addresses or telephone numbers were divulged - just account numbers.

This can’t be true. Without names, the card numbers are unusable.

Hannaford became aware of the breach Feb. 27. Investigators later discovered that the data breach began on Dec. 7; it wasn’t contained until March 10, said Carol Eleazer, Hannaford’s vice president of marketing in Scarborough.

“We have taken aggressive steps to augment our network security capabilities,” Hannaford president and CEO Ronald C. Hodge said in a statement released Monday. “Hannaford doesn’t collect, know or keep any personally identifiable customer information from transactions.”

This reinforces the likelihood of a network breach and sniffing, assuming the statement is true. How was the network breached? Could be any one of hundreds of ways. Targeted phishing and compromise of the central network from a remote location are common. I can’t add anything more than pure speculation on this one.

The company urged its customers to monitor their credit and debit cards for unusual transactions and report any problems to authorities.

Actually, card issuers should reissue the cards and just eliminate the chance of greater fraud. This is irresponsible. Since this is just loss of credit cards, there is no need for identity theft protection.

Mark Walker, an attorney for the Maine Bankers Association, said his organization sent an advisory to member banks Friday after learning of the breach. Only a few had reported suspicious activity involving the credit and debit cards they had issued customers, Walker said.
“I had expected there would be more than we’ve heard of,” Walker said. “But it’s still too early for us to tell.”

Strange- I consider 1,800 to be a large number. It could be that the fraud was performed directly in the Hannaford system or something. Or this is an erroneous statement.

The FAQ gives us a little more information and narrows things down.

What happened?

Hannaford announced containment of a data intrusion into its computer network that resulted in the theft of customer credit and debit card numbers. This data was illegally accessed from Hannaford’s computer systems during the card verification transmission process in transactions. Further, Hannaford is cooperating with credit and debit card issuers to ensure those customers who may be affected by the theft are protected

Somewhat contradictory, with a mention of data security and network, but I don’t expect everyone to be as picky about those details as we are. I suspect the last sentence means fraud alerts are in place, and cards are probably being reissued to some extent.

When did you discover the intrusion?

Hannaford was first made aware of suspicious credit card activity on Feb. 27, and immediately initiated a comprehensive investigation with the assistance of leading computer security experts

Bingo. It was detected by the banks or credit card companies, then brought to Hannaford.

Is it safe to continue shopping in your stores?

We have continually devoted significant round-the-clock resources to ensure Hannaford has comprehensive data security systems in place. For example, our security measures meet industry compliance standards and many go above and beyond what is required by industry standards.

In other words, PCI is worthless.

In conclusion, it looks like some sort of a network breach (which could be anything from phishing/malware to compromise from a retail location to a full network hack). A sniffer was possibly installed, since it seems they don’t keep credit card information (again, assuming statements are true). The fraud was detected by the banks or credit card companies, then it took a little under two weeks to contain. Not great, and indicative of either a little sophistication on the attacker’s part, or a lack of sophistication on Hannaford’s part.

How to prevent this?

We won’t know until more information is out, but since they shouldn’t be PCI compliant if they transmitted credit card numbers in the clear, perhaps my guess of sniffing is off. I’m still laying odds on that, and if so, encryption is the answer.

Technorati Tags: Data Breach, Hannaford

Bruce Schneier is one of the more venerated figures in the information security world, and rightfully so. But reading his article in Wired today, I think he might want to stick to encryption. (I know and like Bruce, so this isn’t a personal attack.)

Bruce has long bragged that he runs a totally open home wireless network. He considers it a kind of “pay it forward” charity. I love open WiFi and don’t have a problem with free access. Someday I might even open up part of my own network, although it’s probably not worth it considering where I live.

Bruce breaks the potential security risks down into two categories:

1. Somebody abusing his network for illegal activity- spam, file sharing, attacking other systems, and so on.
2. Connecting to his network and attacking his home systems.

He evaluates these risks as acceptable:

1. Odds are a bad guy will use one of the five open, anonymous coffee shops down the street rather than parking in front of his house for (probably) hours on end. By saying that he instantly guarantees that some prankster will park their VW van out front and spam everyone from “Bruce Schneier’s House”. Perhaps not, but he does accurately outline the potential legal risks.
2. In his own words, “I’m also unmoved by those who say I’m putting my own data at risk, because hackers might park in front of my house, log on to my open network and eavesdrop on my internet traffic or break into my computers. This is true, but my computers are much more at risk when I use them on wireless networks in airports, coffee shops and other public places. If I configure my computer to be secure regardless of the network it’s on, then it simply doesn’t matter. And if my computer isn’t secure on a public network, securing my own network isn’t going to reduce my risk very much.”

While these risks might be acceptable to Bruce, I don’t recommend them for anyone else, including myself.

1. Depending on population density, your risk of abuse of an open network may be higher. I could open part of my network in my current location without much worry, but I’ve previously lived in places where the pedophile living below me would take advantage of an open network. That’s not an exaggeration- for most of the time I lived in a particular condo in Boulder the person below me was known for risky activity. Never convicted, but concerning enough I sure as hell wouldn’t want him on my network. The risk of the RIAA going after you might also be higher if you live someplace with enough close neighbors that it’s worth someone’s effort to use your network to mask their activity. It’s a low risk for me where I am now, but has been high in the past.
2. Very few people have the skills to secure their home network to the same degree as Bruce. I also suspect his network wouldn’t withstand a penetration test by a determined attacker. My home network is very secure; all systems are patched, firewalls turned on, and trust relationships are minimal. That said, I know I could crack it. I don’t encrypt all traffic (wireless is all WPA2 though) and I have some open file shares. Why? Because it’s “secure enough” for my home, and anything that leaves the walls and connects through the public Internet is totally locked down. In some cases, thanks to my consumer devices, I’m limited in the amount of security I can apply.

I wouldn’t make a big deal out of this, but Bruce is a role model to those interested in security. I can guarantee at least a few people will open up their networks to emulate Bruce, and be the worse for wear because of it.

He also mentions the risk of violating his ISP’s terms of service:

Certainly this does concern ISPs. Running an open wireless network will often violate your terms of service. But despite the occasional cease-and-desist letter and providers getting pissy at people who exceed some secret bandwidth limit, this isn’t a big risk either. The worst that will happen to you is that you’ll have to find a new ISP.

To give the press quote, if Bruce is doing this himself it looks like he has appropriately evaluated his personal risks and they are within his personal tolerance. If he’s recommending this to others, that’s just plain stupid.
I’ve thought about opening my own access up via a separate, segregated segment, but it’s not worth the effort since almost no one around me would need it.

Don’t follow Bruce’s example- he’s an industry pundit making a point. If you want to open up your wireless network, and are comfortable violating the terms of agreement with your ISP, please use a well-segregated open access point. Don’t just let anyone wander around and see what’s on your TiVo (since all TiVos have an open web server you can’t lock down without hacking, it ain’t that unusual a risk).

Oh, and the Chuck Norris thing?

Sears isn’t having much luck these days.

First, they install spyware on their customers’ computers. If you “join the Sears community”, they install a proxy on your computer and intercept all web traffic.

Ugly, ugly, idiocy.

Now, it turns out they have a major logic flaw on their website. As reported by Brian Krebs at Security Fix, anyone can see anyone else’s purchase history with just their name, address, and phone number. Have those white pages handy? It seems to cover both online and offline purchases.

If you’re not paying attention to logic flaws in your databases and applications, this is a great example. While it’s good to make life easy for your customers, it’s bad when you make it easy for your next door neighbor to figure out if you really bought those new hedging shears that coincidentally look just like the ones they lost out of their shed last month.

This exploit was easily preventable with just a modicum of thought and the most cursory security review. Sears is too big a company to make this kind of mistake.

And the spyware? Sheer stupidity by someone in marketing is my guess. Maybe they and whoever screwed up at Sony BMG went to the same marketing school.

Chris Hoff and I decided to have a little fun and fake some back and forth exploits to highlight some security risks. It’s nearing the end of the year; either crunch time for some of you, or boring time for the rest. We figured a little humor couldn’t hurt in either case. We decided to blow this open early so it doesn’t get away from us.

The attack Chris described could clearly work, but I’m surprised more people didn’t pick up the holes. While I do have a home automation system (but no cameras) I don’t know of any that use SCADA-based technologies. Then again, SCADA is going all IP so it might not be a stretch to define my system that way. For the record, I use an Insteon system but haven’t finished implementation yet.

Bonus points to the commenters that noticed there’s no way I’d have a yard with that much green in Phoenix.

The idea of the Quicktime rtsp attack was completely real. Until Apple released the patch a day or so ago, the only defense was avoiding clicking on potentially hostile links. I trust Chris, and would click on most things he sends me. Outbound filtering (which I do one one of my machines) could block the request unless it directed me to an unusual port; something Chris is capable of.

The idea of pwning my workstation is dead on- and one reason I often recommend SCADA workstations be isolated from the Internet. I don’t have to take over your SCADA network if I can take over the workstation and do whatever I want when you aren’t looking.

We were planning on highlighting a few other attack vectors in the next few days. Among them was a fake pretexting of Chris’s phone (we had a viable way for me to get his SSN) and username/password sniffing from wireless access points. All are common vectors that even us security pros are a little lax with sometimes.

I suspect most of you enjoyed this, and we’ll come up with something more creative for April 1.

My second monthly column is up over at Dark Reading; The Perils of Predictions & Predicting Perils.

This is not your ordinary year-end prediction special. Here’s an excerpt:

As the end of the year approaches, a strange phenomenon begins. As we relax and prepare for the holidays, we feel a strange compulsion to predict the future. For some, this compulsion is so overwhelming that it bursts the bounds of late night family dinners and explodes onto the pages of blogs, magazines, newspapers and the ever-dreaded year-end specials on TV.

Ah, year’s end. Legions of armchair futurists slobber over their keyboards, spilling obvious dribble that they either predict every year until it finally happens or is so nebulous that they claim success if a butterfly flaps its wings in Liechtenstein.

As you can tell, I’ve never been the biggest fan of these year-end predictions, especially in the security business. Since the days of the slide rule, scores of pundits have consistently, inaccurately predicted a devastating SCADA attack or the next big worm.

Instead, I focus on two major threat trends and the security innovation they are inspiring. My favorite line in the column is near the end, so I’ll pull it out:

Vulnerability scanning, secure software development, and programmer security training cannot solve the Web application security problem.

I’ll leave you with two words: anti-exploitation, but you should really go read the article.

Looks like the ipfw rules project that Chris is leading is pretty popular. We’ve set up a permanent link that we’ll redirect to the latest version as we keep refining this thing.

You can find it here.

Thanks again to everyone who has helped on this project:

windexh8er: http://www.slash32.com/
Rob
Lee: http://thnetos.wordpress.com/
Josh
Chris Pepper http://www.extrapepperoni.com/

Based on extensive feedback, these rules are now much improved over the initial draft. Thanks, all!

All the versions of this post are getting out of hand, so Rich has provided a permanent URL for the current Leopard ipfw post for future reference. Please use that link, so future visitors get the latest and greatest.

Chris

# DO NOT USE THESE RULES without customizing them first!
# Version: 2007/12/12

# For more information, see http://securosis.com/2007/11/15/ipfw-rules/
# & http://securosis.com/2007/11/16/ipfw-rules-20071116-revision/#comments

# These rules *MUST* be customized to your requirements.
# In particular, if you have a private home network (behind an AirPort
# Base Station, Linksys WRT54G, etc.), change “10.42.24.0/24″ below to
# your private network range; duplicate rules with different ranges, if use use this computer on multiple networks.
# Additionally, allow only ports you actually use; block unused ports.

# Thanks to:
# Rich Mogull http://securosis.com
# windexh8er: http://www.slash32.com/
# Rob
# Lee: http://thnetos.wordpress.com/
# Josh
# Chris Pepper http://www.extrapepperoni.com/
# Apple (Server Admin is a good way to create an ipfw ruleset)
# http://www.apple.com/server/macosx/
# FreeBSD (where Apple got ipfw) http://www.freebsd.org/

# We don’t really want this, but it’s unavoidable on Mac OS X Server, so
# document it here (serialnumberd).
# 100 allow udp from any 626 to any dst-port 626

# Let me talk to myself over the loopback.
add 200 allow ip from any to any via lo0

# Loopback traffic on a ‘real’ interface is bogus.
add 300 deny log logamount 1000 ip from any to 127.0.0.0/8

# Block multicast unless you need it.
# add 400 deny log logamount 1000 ip from 224.0.0.0/4 to any in

# If we let a conversation begin, let it continue.
# Let my clients go!
add 500 allow tcp from any to any out keep-state
add 510 allow udp from any to any out keep-state
# Block replies, if we don’t recall initiating the conversation.
add 520 deny log tcp from any to any established in

# Allow DHCP responses (keep-state can’t handle DHCP broadcasts).
add 600 allow udp from any to any src-port 67 dst-port 68 in

# Do you never need fragmented packets?
# add 700 deny udp from any to any in frag

# Let yourself ping.
# add 1000 allow icmp from 10.42.24.0/24 to any icmptypes 8

# Server Admin provides these by default.
add 1100 allow icmp from any to any icmptypes 0
add 1110 allow igmp from any to any

# mDNS (Bonjour) from trusted local networks (fill in your own,
# preferably non-standard, networks after ‘from’).
# For Back to My Mac, you might need this from ‘any’.
# add 5000 allow udp from 10.42.24.0/24 to any dst-port 5353
# add 5010 allow udp from 10.42.24.0/24 5353 to any dst-port 1024-65535 in

# ssh — should be restricted to trusted networks if at all possible; if
# open to the Internet, make sure you don’t have “PermitRootLogin yes”
# in sshd_config (at least use
# PermitRootLogin without-password“, please!)
add 5200 allow tcp from any to any dst-port 22

# iTunes music sharing
# add 5300 allow tcp from 10.42.24.0/24 to any dst-port 3689

# AFP
# add 5400 allow tcp from 10.42.24.0/24 to any dst-port 548

# HTTP (Apache); HTTPS
# add 5500 allow tcp from any to any dst-port 80
# add 5510 allow tcp from any to any dst-port 443

# L2TP VPN — is this complete?
# add 5600 allow udp from any to any dst-port 1701
# add 5610 allow esp from any to any
# add 5620 allow udp from any to any dst-port 500
# add 5630 allow udp from any to any dst-port 4500

# iChat: local
# add 5700 allow tcp from 10.42.24.0/24 to any dst-port 5298
# add 5710 allow udp from 10.42.24.0/24 to any dst-port 5298
# add 5720 allow udp from 10.42.24.0/24 to any dst-port 5297,5678

# Server Admin SSL (Mac OS X Server only)
# add 5800 allow tcp from 10.42.24.0/24 to any dst-port 311
# add 5810 allow tcp from 10.42.24.0/24 to any dst-port 427
# add 5820 allow udp from 10.42.24.0/24 to any dst-port 427

# syslog — uncommon
# add 5900 allow udp from 10.42.24.0/24 to any dst-port 514

# ipp (CUPS printing)
# add 6000 allow tcp from 10.42.24.0/24 to any dst-port 631

# MTU discovery
add 10000 allow icmp from any to any icmptypes 3

# Source quench
add 10100 allow icmp from any to any icmptypes 4

# Ping out; accept ping answers.
add 10200 allow icmp from any to any icmptypes 8 out
add 10210 allow icmp from any to any icmptypes 0 in

# Allow outbound traceroute.
add 10300 allow icmp from any to any icmptypes 11 in

# My default policy: log and drop anything that hasn’t matched an allow
# rule above
add 65534 deny log logamount 1000 ip from any to any

# Hard-coded default allow rule (compiled into Darwin kernel)
add 65535 allow ip from any to any

Rules revised.

As suggested by windexh8er, here’s a set of ipfw rules to customize for your own Macs or FreeBSD systems. Note that your private home network should have a non-standard IP range, both to support VPN across standard IP ranges, and for improved security, so your personal allow rules don’t match other networks you may find yourself wandering through.

The rules are below, but you’ll probably have an easier time if you download the rule file from http://securosis.com/wp-content/uploads/2007/11/ipfw-securosis.txt.

In WaterRoof, you can import these rules with “Tools > Rules Configuration > Import rules from file..”. To check your ipfw rules, use “sudo ipfw list“. When you’re satisfied with your rules, install them for future reboots with “Tools > Rules Configuration > Save to startup configuration” and “Tools > Startup Script > Install Startup Script”.

# DO NOT USE THESE RULES without customizing them first!
# Version: 2007/11/15

# For more information, see http://securosis.com/2007/11/15/ipfw-rules/

# These rules *MUST* be customized to your requirements.
# In particular, if you have a private home network (behind an AirPort
# Base Station, Linksys WRT54G, etc.), change "10.42.24.0/24" below to
# your private network range.
# Additionally, allow only ports you actually use; other ports should be
# blocked by the ipfw firewall.

# Thanks to:
# Rich Mogull http://securosis.com
# windexh8er: http://www.slash32.com/
# Lee: http://thnetos.wordpress.com/
# Chris Pepper http://www.extrapepperoni.com/
# Apple (Server Admin is a good way to create an ipfw ruleset)
#   http://www.apple.com/server/macosx/
# FreeBSD (where Apple got ipfw) http://www.freebsd.org/

# We don't really want this, but it's unavoidable on Mac OS X Server, so
# document it here (serialnumberd)
# 100 allow udp from any 626 to any dst-port 626 

# Let me talk to myself over the loopback
add 200 allow ip from any to any via lo0 

# Loopback addresses on non-loopback interfaces are bogus
add 300 deny log logamount 1000 ip from any to 127.0.0.0/8
add 310 deny log logamount 1000 ip from 224.0.0.0/4 to any in 

# Block multicast if you don't use it
# add 400 deny log ip from 224.0.0.0/4 to any in 

# Accept responses to my client programs
add 500 check-state 

# If we let the conversation begin, let it continue
add 600 allow tcp from any to any established 

# Let my programs get out.
add 700 allow tcp from any to any out keep-state
add 710 allow udp from any to any out keep-state 

# Change this to DENY fragments if you don't need them.
add 800 allow udp from any to any in frag 

# Block bogus inbounds that claim they were established
# add 900 deny log tcp from any to any established in 

# add 1000 allow icmp from 10.9.7.0/24 to any icmptypes 8 

# Server Admin provides these by default
add 1100 allow icmp from any to any icmptypes 0
add 1110 allow igmp from any to any 

# mDNS (Bonjour) from trusted local networks (fill in your own,
# preferably non-standard, networks after 'from')
# For Back to My Mac, you might need this from 'any'
# add 5000 allow udp from 10.42.24.0/24 to any dst-port 5353
# add 5010 allow udp from 10.42.24.0/24 5353 to any dst-port 1024-65535 in

# DNS (note TCP is required, but this one should scare you -- much
# better to only allow packets from your trusted nameservers, if you
# always use the same ones)
add 5100 allow tcp from any to any dst-port 53
add 5110 allow udp from any to any dst-port 53
add 5120 allow tcp from any to any dst-port 53 out keep-state
add 5130 allow udp from any to any dst-port 53 out keep-state 

# ssh
add 5200 allow tcp from any to any dst-port 22 

# iTunes music sharing
#add 5300 allow tcp from 10.42.24.0/24 to any dst-port 3689 

# AFP
#add 5400 allow tcp from 10.42.24.0/24 to any dst-port 548 

# HTTP (Apache); HTTPS
# add 5500 allow tcp from any to any dst-port 80
# add 5510 allow tcp from any to any dst-port 443 

# L2TP VPN
# add 5600 allow udp from any to any dst-port 1701
# add 5610 allow esp from any to any
# add 5620 allow udp from any to any dst-port 500
# add 5630 allow udp from any to any dst-port 4500 

# iChat: local
#add 5700 allow tcp from 10.42.24.0/24 to any dst-port 5298
#add 5710 allow udp from 10.42.24.0/24 to any dst-port 5298
#add 5720 allow udp from 10.42.24.0/24 to any dst-port 5297,5678 

# Server Admin SSL (Mac OS X Server only)
# add 5800 allow tcp from 10.42.24.0/24 to any dst-port 311
# add 5810 allow tcp from 10.42.24.0/24 to any dst-port 427
# add 5820 allow udp from 10.42.24.0/24 to any dst-port 427 

# syslog
# add 5900 allow udp from 10.42.24.0/24 to any dst-port 514 

# ipp (CUPS printing) 

# add 6000 allow tcp from 10.42.24.0/24 to any dst-port 631 

# MTU discovery
add 10000 allow icmp from any to any icmptypes 3 

# Source quench
add 10100 allow icmp from any to any icmptypes 4 

# Ping out; accept ping answers
add 10200 allow icmp from any to any icmptypes 8 out
add 10210 allow icmp from any to any icmptypes 0 in 

# Allow me to traceroute
add 10300 allow icmp from any to any icmptypes 11 in 

# My default policy: log and drop anything that hasn't matched an allow
# rule above
add 65534 deny log logamount 1000 ip from any to any

# Hard-coded default allow rule (compiled into Darwin kernel)
add 65535 allow ip from any to any

In a recent post at Security Ripcord, Cutaway says:

Let me elaborate on the second topic a little more. The days of hacking for fun are over. I think it is safe to say that nearly everybody has come to that realization (there may be a few holdouts in upper management but they will not last long). This means that the stakes are higher for the good guys and the bad guys.

Sure, the stakes might be higher, but don’t always equate hacking with security research. Hacking is fun. Research is work. Sometimes they overlap. Let’s not take the sense of wonder out of hacking, which is an exercise in exploration, just because the term also applies to the occasional transgressions of bad guys.

Of course I know Cutaway knows this (Mystery Challenge and all), but like any good blogger I’m taking something out of context to have a little fun and make a point.

No, I’m not calling all security researchers torturers. Before you flame me, read the post…

Not that I have any personal experience (beyond sitting through Black Dog the day my girlfriend dumped me), but torture is one of those things that rarely seems to give you the results you want, and even when it seems to work comes at an incredibly high cost

As I mentioned in the Three Dirty Secrets of Disclosure post, full disclosure, especially “no-knock” full disclosure (releasing everything before even reporting it to the vendor) helps the bad guys more than the good guys. End users don’t have the time or skill, in most cases, to protect themselves. They’re still beholden to their vendor to provide a solution, but now even the lesser-skilled bad guys have a new way to attack.

So how is full disclosure like torture?

It’s more valuable as a threat. Once used, you can’t take it back, it rarely gives you the results you want, and everyone involved is hurt. Actually, unlike torture full disclosure hurts any innocent bystanders in the process.

Some researchers think full disclosure forces vendors to respond and patch. Maybe; but in my experience vendors resist torture like James Bond and end up escaping and just getting really vengeful in the process.

I think we need full disclosure as a tool in our arsenal, and that most of the researchers dropping these vulnerabilities think they’re doing good, but full disclosure needs to be a last resort- not a first strike. It’s more powerful as an ever-present threat hanging over the heads of the most unresponsive of vendors. Dropping vulnerabilities and proof of concept code on a daily basis just hardens the vendors and lets them paint you as an out of control rogue.

You might think you’re saving the free world, but you’re no Jack Bauer.