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 Software Vulnerabilities

X-Force Prevents Zero Day from Going Anywhere

8 min read - This blog was made possible through contributions from Fred Chidsey and Joseph Lozowski. The 2023 X-Force Threat Intelligence Index shows that vulnerability discovery has rapidly increased year-over-year and according to X-Force’s cumulative vulnerability and exploit database, only 3% of vulnerabilities are associated with a zero day. X-Force often observes zero-day exploitation on Internet-facing systems as a vector for initial access however, X-Force has also observed zero-day attacks leveraged by attackers to accomplish their goals and objectives after initial access was…

8 min read

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

12 min read - ‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

12 min read

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

17 min read - Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

17 min read

Dissecting and Exploiting TCP/IP RCE Vulnerability “EvilESP”

10 min read - September’s Patch Tuesday unveiled a critical remote vulnerability in tcpip.sys, CVE-2022-34718. The advisory from Microsoft reads: “An unauthenticated attacker could send a specially crafted IPv6 packet to a Windows node where IPsec is enabled, which could enable a remote code execution exploitation on that machine.” Pure remote vulnerabilities usually yield a lot of interest, but even over a month after the patch, no additional information outside of Microsoft’s advisory had been publicly published. From my side, it had been a…

10 min read