How The Crooks Hit Target

Sean Michael Kerner is a senior editor at eWeek and contributor to TechWeek

Follow on: Google +

What can we learn from the Target hack? Sean Michael Kerner says we can’t blame any single technology

The security breach at US retailer Target in December has been the subject of intense scrutiny and speculation over the course of the last month.

Few details were made public when Target first admitted to the security breach on 19 December, 2013. This month, little by little, scraps of information have emerged, including the disclosure that some form of point-of-sale (POS) malware, identified as a RAM scraper, was involved.

Over the course of this month, there have been multiple reports and claims about the Target breach from security vendors and experts—what can people do? What should Target have done? Do we need more secure credit cards?

TargetThere was no single flaw

The simple truth is that Target should not have been breached by any one technology failure or vulnerability. Security in the modern world should never just be one thing, and it is not defined by any single vendor, product or technology.

The truth is that security must always be a continuous process. That’s not just a motherhood and apple pie truism either.

You have to think like an attacker first to understand what’s going on here. First of all, for an attacker to get data from a network, he or she has to infiltrate the network. In a typical enterprise environment, defences for infiltration include access controls and perimeter defences, such as a firewall.

In Target’s case, the perimeter is the POS device, so the attacker needed to infiltrate that device. As part of compliance to the Payment Card Industry (PCI) standards, there are rules in place that are supposed to ensure the physical integrity of the device, such that an attacker couldn’t easily open and tamper with the device’s internal circuitry.

However, there was a Black Hat USA presentation in 2012 in which a pair of security researchers were able to infect a POS payment terminal using a malicious card. While some have argued that “Chip and PIN” or EMV cards (widespread in Europe and used by Europay, MasterCard, Visa) could have prevented the breach, there have also been public exploits of that technology. In 2011, a Black Hat researcher demonstrated how to hack into EMV machines as well.

So let’s assume the Target attacker used a technique to infiltrate the network by way of the POS devices. Proper security procedures and technologies should have been in place to prevent unauthorised, fake cards from being able to load code and infiltrate the network.

Block, and stop exploitation

That’s step one: Stop the point of entry.

Step two in any attack is exploitation. Just because an attacker gets access to a network doesn’t mean anything, unless there is a vulnerability that can be exploited. That’s where the RAM scraper bit comes in.

RAM scraper is a known vulnerability that could enable an attacker to remove data from memory (RAM) on a POS device. The obvious fix for any type of vulnerability is to patch the issue (if there is one), but in some cases, patching is neither easy nor possible.

There potentially could have been other avenues of exploitation. Man-in-the-middle attacks are a common attack vector, whereby the attacker intercepts traffic along the network path. Such attacks can be mitigated with the proper use of encryption and network configuration. In the Target incident, it is unknown if any network communications avenues were exploited, but given that so many devices were likely infected, the network might well have played a role.

Access controls and user privileges can also play a role in the exploitation phase. A super user or system root user gets access to everything on a network, but with proper role-based access control (RBAC)-type techniques and technologies, each individual user and device should be limited to only the data and access that is needed for their specific tasks. So, for example, a single POS device (exploited or not) should not have be able to access much on the network. A common attack vector in the enterprise space is a privilege escalation attack, which can give a regular user more control, akin to what a root user gets.

In the Target case, we don’t know what access controls or limits were in place on POS devices or if any kind of privilege elevation attack was involved, but an attack vector might be considered.

Prevent the data leaving

Step three in any attack is data exfiltration—that is, the attackers had to get the data out of the network. Just because an attacker somehow infiltrates a network, finds a vulnerability and gets the access he or she needs doesn’t necessarily mean that the attacker can get data out of the network. That’s where data loss prevention (DLP) types of technology come into play. DLP-type solutions can and should enforce controls on what types of data can leave the network and who can access that data.

So to recap, the Target attackers had to infiltrate the network, find a known vulnerability and then get out with data. A proper IT security program should have mitigations in place for all three of those things, meaning an attack doesn’t just have to beat any one single technology to be successful, it has to beat three of them.

To be fair, a retail environment is a challenge because the perimeter is very large (every POS terminal) and credit card data is supposed to move across the network. That said, a continuous security policy framework that enforces controls for entry, limits the risk of software vulnerabilities and monitors data exiting the network is how modern security should be deployed.

It is somewhat disingenuous to ascribe any one single technology failure at Target as being the reason why 70 million of its customers had their data stolen. Data protection should never be the domain of a single technology or process. While we don’t know the full details yet about how Target was breached, we know that three things (entry, vulnerability, exit) have to happen in every breach.

While the POS terminal is a potential weak link, a complete process should make it just one-third of the risk chain and not 100 percent of it. Security is a process that demands rigor and vigilance at every level. Application vulnerabilities will always exist, but if those vulnerabilities can’t be exploited because attackers can’t access or exit a network, the risks will be significantly reduced.

Sean Michael Kerner is a senior editor at eWEEK and Follow him on Twitter @TechJournalist.

Originally published on eWeek.