Co-authored by David Byrne.

As fans converge on major sporting events this summer and throughout the year, criminals are acutely aware that many of the attendees come from high income brackets. The temporary collection of wealthy targets is likely very enticing, and robbing travelers is a global and ancient custom. Travelers around the world are at high risk of robbery, and while payment cards can be much simpler than cash, there is still risk stemming from point-of-sale hazards.

When you hand your card to a clerk to run through a point-of-sale (POS) system, how do you know if the data is safe? The truth is, consumers don’t really know. No one can gauge the security of a modern cash register just by looking at it, and even the friendliest merchants will quickly kick you out for trying your own security testing.

The Point Is Not Lost on the Industry

Over a decade ago, the Payment Card Industry Data Security Standard (PCI DSS) was created to merge the separate standards of five of the world’s largest payment card companies. Since then, it has played a major role in the operations of merchants across the world, from one-person setups to the world’s largest retailers. The end goal of the PCI DSS is to keep people using their cards.

But there’s another side to PCI DSS: If the requirements become too burdensome (i.e., too expensive), merchants will become unhappy. Large merchants could use their clout to demand change, and small merchants may just stop accepting cards. As a result, PCI DSS is somewhat like a negotiated truce where neither side is completely happy. Many of the concessions are about how closely assessors look at a merchant’s habits to determine if they comply with the standard.

Just because a merchant is able to pass a PCI DSS assessment doesn’t mean it is actually secure or even in true compliance. The true determination of compliance occurs after a breach actually happens. Forensics investigations routinely reveal implementation flaws — a merchant’s network segmentation is insufficient, default credentials are being used for remote access, not all payment card numbers were encrypted and so on.

What Is a Merchant to Do?

To start, don’t conflate security and compliance. There’s certainly overlap, but aim higher than just convincing your PCI DSS assessor that you’re compliant. In keeping with the theme from earlier, let’s consider your POS environment. Your vendors may have promised that their software is secure and thoroughly tested. But what was tested, and how thorough is thorough?

It’s common for some vendors to take shortcuts by only performing rudimentary testing in an idealized mock environment. That demonstrates that it is technically possible to deploy the product without any obvious flaws, but not much else. When performing tests in actual production environments, it’s very common to see misconfigurations that create major vulnerabilities. Similarly, in-depth testing invariably reveals vulnerabilities too complex for automated tools to find.

Software and Hardware Skimmers

Vulnerable software isn’t the only threat to POS systems. Poor deployment practices can leave retailers open to card skimmers, both software- and hardware-based.

Software skimmers are specialized malware packages that monitor POS memory for plaintext card data. Because they may be custom built (or at least custom obfuscated) for a specific attack, they can slip by standard antivirus software. An attacker that has compromised multiple store locations can install the skimming software on hundreds of registers and just wait for the data to start rolling in.

At the very least, merchants should require that their vendors provide detailed documentation about the scope and intensity of security testing. Ideally, penetration testing should be performed against the actual point-of-sale deployment, even if the administration is performed by a third party.

Hardware skimmers are even more devious. Criminals have designed miniature monitoring devices that fit inside normal card readers. When a customer or clerk swipes a card, the monitoring device reads the magnetic stripe at the same time as the legitimate reader. The attacker can wirelessly retrieve the stolen data using a smartphone, perhaps even from the store’s parking lot.

The good news for merchants is that physical skimmers don’t scale well. Installing a physical skimmer is very difficult and must be repeated for every device that’s being attacked. Installation requires that the legitimate card reader be dismantled and physically modified to accommodate the skimmer, making it nearly impossible for the attack to be launched while the store is open.

As a result, hardware skimmers are usually installed in a shipment of new or replacement card readers. This is where the good news for merchants ends. A sophisticated card skimmer will never communicate directly to the POS system, making it completely invisible from a software point of view.

Protecting Against Point-of-Sale Hazards

Hardware skimmers can be prevented by strong physical security in stores and throughout the POS hardware supply chain. Some card reader vendors feature tamper-resistant designs that will provide visual or electronic notification when cases are opened.

Read the documentation for these features and use them! Train your staff to carefully inspect all new POS hardware and to periodically inspect existing hardware. Distribute photographs from multiple angles of what the card readers should look like.

Athletes are rigorously tested for signs of cheating. Ultimately, this is the same strategy that can protect merchants from point-of-sale hazards: Design a secure environment and rigorously test it.

Learn more about other cyber hazards at large sporting events by reading the “IBM X-Force Special Report: 2016 Brazilian Threat Landscape.”

More from X-Force

Hive0147 serving juicy Picanha with a side of Mekotio

17 min read - IBM X-Force tracks multiple threat actors operating within the flourishing Latin American (LATAM) threat landscape. X-Force has observed Hive0147 to be one of the most active threat groups operating in the region, targeting employee inboxes at scale, with a primary focus on phishing and malware distribution. After a 3-month break, Hive0147 returned in July with even larger campaign volumes, and the debut of a new malicious downloader X-Force named "Picanha,” likely under continued development, deploying the Mekotio banking trojan. Hive0147…

FYSA – Critical RCE Flaw in GNU-Linux Systems

2 min read - Summary The first of a series of blog posts has been published detailing a vulnerability in the Common Unix Printing System (CUPS), which purportedly allows attackers to gain remote access to UNIX-based systems. The vulnerability, which affects various UNIX-based operating systems, can be exploited by sending a specially crafted HTTP request to the CUPS service. Threat Topography Threat Type: Remote code execution vulnerability in CUPS service Industries Impacted: UNIX-based systems across various industries, including but not limited to, finance, healthcare,…

Getting “in tune” with an enterprise: Detecting Intune lateral movement

13 min read - Organizations continue to implement cloud-based services, a shift that has led to the wider adoption of hybrid identity environments that connect on-premises Active Directory with Microsoft Entra ID (formerly Azure AD). To manage devices in these hybrid identity environments, Microsoft Intune (Intune) has emerged as one of the most popular device management solutions. Since this trusted enterprise platform can easily be integrated with on-premises Active Directory devices and services, it is a prime target for attackers to abuse for conducting…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today