07. February 2014 · Comments Off on Jumping to conclusions about the Target breach · Categories: Uncategorized · Tags: , , , ,

On Feb 5, 2014 Brian Krebs published a story which provided more details about the Target breach entitled, Target Hackers Broke in Via HVAC Company. The story connects the Target breach to the fact that Target allowed Fazio Mechanical Services, a provider of refrigeration and HVAC systems to remotely connect to Target stores in the Pennsylvania area. Fazio provides these same services to Trader Joe’s, Whole Foods, and BJ’s Wholesale Club in Pennsylvania, Maryland, Ohio, Virginia, and West Virginia. Krebs goes on to say that this practice is common and why.

Krebs rightly never jumps to a conclusion about how this remote access resulted in the breach because there are no known facts on which to base such a conclusion. However that did not stop Network World from publishing a story on Feb 6, 2014 that the Target breach happened because of a basic network segmentation error. The problem with the story is that no one has shown, much less stated, that the attackers’ ability to move around the network was due to an error in network segmentation in the Target stores.

In fact, one of the commenters, “LT,” in the Krebs story actually stated:

Target does have separate VLANs for Registers, Security cameras, office computers, registry scanners/kiosks, even a separate VLAN for the coupon printers at the registers. The problem is not lack of VLAN’s, they use them everywhere and each VLAN is configured for exactly the number of devices it needs to support. The problem is somehow lateral movement was allowed that allowed the hackers to enter in through the HVAC system and eventually get to the POS VLAN.

So there are really TWO possible conclusions one can draw from this, not just the one Network World jumped to:

  1. There were in fact VLAN configuration errors that more easily allowed the attackers to move around undetected.
  2. The attackers knew how to circumvent VLAN control. For some reason Network World failed to consider this possibility. To me, this is a reasonable alternative. VLAN hopping is a well-understood attack vector.

So one might ask, why was Target relying on VLANs for network segmentation rather than firewalls? Based on my interpretation of the PCI DSS 3.0 Requirements and Security Assessment Procedures published in November 2013, there is no requirement to deploy firewalls in stores. Requirement 1.3 is fairly clear that firewalls are only relevant when there is an Internet (public) connection present. Based on my experience, retail stores do not have direct Internet access. They communicate on “private” networks to internal datacenters. Therefore, the use of VLANs to segment store traffic is not a violation of PCI DSS requirements.

Finally, even if PCI DSS specified “stateful inspection” firewalls were deployed in stores, they do not provide adequate network security control against attackers, as I wrote previously,

 

 

 

 

20. January 2014 · Comments Off on How Palo Alto Networks could have prevented the Target breach · Categories: blog · Tags: , , , , ,

Brian Krebs’ recent posts on the Target breach, A First Look at the Target Intrusion, Malware, and A Closer Look at the Target Malware, provide the most detailed and accurate analysis available.

The malware the attackers used captured complete credit card data contained on the mag stripe by “memory scraping.”

This type of malicious software uses a technique that parses data stored briefly in the memory banks of specific POS devices; in doing so, the malware captures the data stored on the card’s magnetic stripe in the instant after it has been swiped at the terminal and is still in the system’s memory. Armed with this information, thieves can create cloned copies of the cards and use them to shop in stores for high-priced merchandise. Earlier this month, U.S. Cert issued a detailed analysis of several common memory scraping malware variants.

Furthermore, no known antivirus software at the time could detect this malware.

The source close to the Target investigation said that at the time this POS malware was installed in Target’s environment (sometime prior to Nov. 27, 2013), none of the 40-plus commercial antivirus tools used to scan malware at virustotal.com flagged the POS malware (or any related hacking tools that were used in the intrusion) as malicious. “They were customized to avoid detection and for use in specific environments,” the source said.

The key point I want to discuss however, is that the attackers took control of an internal Target server and used it to collect and store the stolen credit card information from the POS terminals.

Somehow, the attackers were able to upload the malicious POS software to store point-of-sale machines, and then set up a control server within Target’s internal network that served as a central repository for data hoovered by all of the infected point-of-sale devices.

“The bad guys were logging in remotely to that [control server], and apparently had persistent access to it,” a source close to the investigation told KrebsOnSecurity. “They basically had to keep going in and manually collecting the dumps.”

First, obviously the POS terminals have to communicate with specific Target servers to complete and store transactions. Second, the communications between the POS terminals and the malware on the compromised server(s) could have been denied had there been policies defined and enforced to do so. Palo Alto Networks’ Next Generation Firewalls are ideal for this use case for the following two reasons:

  1. Palo Alto Networks enables you to include zone, IP address, port, user, protocol, application information, and more in a single policy.
  2. Palo Alto Networks firewalls monitor all ports for all protocols and applications, all of the time, to enforce these polices to establish a Positive Control Model (default deny or application traffic white listing).

You might very well ask, why couldn’t Router Access Control Lists be used? Or why not a traditional port-based, stateful inspection firewall? Because these types of network controls limit policy definition to ports, IP addresses, and protocols, which cannot enforce a Positive Control Model. They are simply not detailed enough to control traffic with a high degree of confidence. One or the other might have worked in the 1990s. But by the mid-2000s, network-based applications were regularly bypassing both of these types of controls.

Therefore, if Target had deployed Palo Alto Networks firewalls between the POS terminals and their servers with granular policies to control POS terminals’ communications by zone, port, and application, the malware on the POS terminals would never have been able to communicate with the server(s) the attackers compromised.

In addition, it’s possible that the POS terminals may never have become infected in the first place because the compromised server(s) the attackers initially compromised would not have been able to communicate with the POS terminals. Note, I am not assuming that the servers used to compromise the POS terminals were the same servers used to collect the credit card data that was breached.

Unfortunately, a control with the capabilities of Palo Alto Networks is not specified by the Payment Card Industry (PCI) Data Security Standard (DSS). Yes, “Requirement #1: Install and maintain a firewall configuration to protect cardholder data,” seems to cover the subject. However, you can fully meet these PCI DSS requirements with a port-based, stateful inspection firewall. But, as I said above, an attacker can easily bypass this 1990s type of network control. Retailers and e-Commerce sites need to go beyond PCI DSS to actually protect themselves. You need is Next Generation Firewall like Palo Alto Networks which enables you to define and enforce a Positive Control.