You’ve heard this story before. A major credit card company has experienced a massive breach. Tons and tons of data was stolen during the incident. They think they have it under control and are working with law enforcement. You should check your statements. Blah, blah, blah…

Once again, though, in this case, the company was certified as PCI compliant by their PCI auditors. If they were all compliant and filled to the brim with “fluffy, compliant goodness” then the attackers must have used some uber-hacking technique, right? Some bleeding edge tool or 0-day exploit that cut right through their defenses and rendered their compliant protections useless? Ummm…. NO…. The mighty technique that caused the damage? A sniffer!!!! (Some of the best technology that the late 80’s/early 90’s had to offer…)

How did I reach this conclusion? From their own press release:

“Last week, the investigation uncovered malicious software that compromised data that crossed Heartland’s network.” — sounds like a sniffer to me….(and a lot of other infosec folks…)

That’s right, the mighty sniffer strikes again. In the last couple of years, this same attack footprint has occurred over and over again. It has been largely successful. Why? Because companies don’t encrypt credit card data in transit across networks. Sure, many of them encrypt the database (not all, but many.) and some use various forms of endpoint protection, but many (way too many apparently) don’t encrypt the credit card data in transit across their networks.

Even worse, the PCI DSS DOES NOT REQUIRE THIS. That is how they can be compliant with PCI and still have this issue. What a cruel joke for consumers.

The DSS requires that organizations encrypt credit card data when it flows across “open, public” networks. Well, guess what, when your network gets compromised, even your “internal, private LAN”, it becomes “public” at least for the attackers. Misconfigure a firewall rule, get a workstation popped, allow a social engineer into the environment and that “private network” is not so private anymore, is it?

But, that never happens, right? Except when it does.

In my opinion, it is high time that organizations realize that compliance is not security. Compliance is a false goal set in sand. The real goal is risk management and data protection. In order to accomplish these goals, you have to make rational decisions and account for real threats, not just checklists compiled by some nebulous group of people in a “one size fits all fashion”. That is a fool’s errand.

As I have been saying for a while now, we have to start thinking differently about security. We have to forget the baselines and look at our risk from the view of a threat agent (a hacker, cyber-criminal, attacker, whatever!). We have to make rational choices that really do protect that which needs to be protected. We have to hope for the best and architect for abject failure. Anything less than that, and this is a story you we will just get to keep on telling….

Interested in learning more about “sniffing”? Click here for a great FAQ.

I also did an interview with Secure Computing Magazine about this. You can read that here.

For those organizations who have decided not to patch their DNS servers because they feel protected by implemented controls that only allow recursion from internal systems, we just wanted to point out that there a number of ways that an attacker can cause a recursive query to be performed by an “internal” host.

Here is just a short list of things that an attacker could do to cause internal DNS recursion to occur:

Send an email with an embedded graphic from the site that they want to poison your cache for, which will cause your DNS to do a lookup for that domain if it is not already known by your DNS

Send an email to a mail server that does reverse lookups on the sender domain (would moving your reverse lookup rule down in the rule stack of email filters help minimize this possibility???)

Embed web content on pages that your users visit that would trigger a lookup

Trick users through social engineering into visiting a web site or the like

Use a bot-net (or other malware) controlled system in your environment to do the lookup themselves (they could also use this mechanism to perform “internal” cache poisoning attacks)

The key point here is that many organizations believe that the fact that they don’t allow recursion from external hosts makes them invulnerable to the exploits now circulating in the wild for the DNS issue at hand. While they may be resilient to the “click and drool” hacks, they are far more vulnerable than they believe to a knowledgeable, focused, resourced attacker who might be focused on their environment.

The bottom line solution, in case you are not aware, is to PATCH YOUR DNS SYSTEMS NOW IF THEY ARE NOT PATCHED ALREADY.

Please, do not wait, active and wide scale exploitation is very likely in the very near future, if it is not underway right now!