Criminal attacks against Point-of-Sale systems get right to the heart of a retail organisation.
The POS (Point-Of-Sale) system resident in retail environments across the world, representing the front end of interaction between the customer and the merchant, has been consistently exposed as a high value target for criminals looking to recover cardholder data.
The POS is one of, if not the most, critical systems for any retail environment. With a high degree of connectivity to other systems, highly sensitive (cardholder) data, and many varied inputs, thePOS should really be protected by imposing security controls deep in the heart of an impenetrable data centre. Instead, it is publically accessible (by necessity), and the security controls afforded to it are often limited. Its uniqueness is often incorrectly considered as suitable protection, security through obscurity, and POS systems are increasingly becoming the target of malware attacks designed to extract sensitive information.
Reedum, Decebal, Alina, Stardust, Dexter, Chewbacca…
Perhaps the most terrifying scenario for any retailer, and one that is seeing increasing attention, is the case of malware infecting a POS system. Silently infecting some, or all, of the deployed systems, the malware harvests card details and other sensitive information. Retrieving more than just card data can provide continued access to the attackers and even more data protection headaches for the merchant.
Most modern POS systems no longer store cardholder data directly, a move pushed forward by both infamous breaches early this century and ease of compliance with PCI DSS. In order to interact with back-end payment processing systems however, that cardholder data still has to be handled by the POS. This point has been exploited by malware that makes use of ‘memory scraping’ techniques.
Data is stored in memory whilst being processed and payment application guidelines require that this data is purged securely once it has been processed. This period of residence in memory is normally no longer than a few seconds whilst authorisation for payment is obtained from back-end systems. Memory scraping is the process of examining the memory at regular intervals to extract the sensitive information. Though normally a jumble of data essential to the running of the system, the malware is able to extract cardholder details by checking for matching patterns of digits and other data through regular expressions.
Figure 1 Matching Card values with Regular Expressions 1
Once captured, the data must be returned to the criminals. In small scale breaches this could be as simple as an attacker returning to the compromised device and extracting the data directly, in larger breaches an automated (and remote) method must be implemented. Where Internet access is available, the devices can be programmed to periodically send data to a server under the attacker’s control. To evade detection further the traffic can be routed through the TORnetwork – a series of shifting proxy servers used to disguise the location of a system, as used in the latest malware variant, Chewbacca 2.
Figure 2 TOR Network Example
For criminals without access to such infrastructure a more low-tech approach is often employed – the dumped data is stored on a server owned by the merchant and accessed by the attacker to simply read the data at regular intervals. This is normally trivial to achieve where the initial compromise was via a merchant owned and connected server, as it is already under the attacker’s control.
The attack vector most commonly used in large scale breach is a remote compromise. Payment terminals are not often connected to the Internet directly, however they interface with a number of back-end systems. Without adequate network segmentation, an attacker may be able to compromise an Internet facing machine and use that to conduct further attacks against internal systems. This approach is often doubly effective as the initial compromised server can be used to host all of the stolen card details (to be retrieved by an attacker over the Internet at a later date).
It is believed (though unconfirmed) that the malware Dexter came to be present on a number ofPOS terminals in the fast-food chain KFC through a remote attack. The system used to manage these terminals was also being used for a number of other functions, including hosting company email, and a phishing attack made it possible for malware to be installed on the server. A flat network structure made it possible to conduct attacks against POS systems centrally.
In 2013 MWR examined a number of commercial payment terminals – often known as PEDs (Pin Entry Device) or PDQ Terminals. These terminals were unique in that they had been infected by malware directly, allowing cardholder data to be captured onto the terminal and read at a later date by the criminals.
Exploiting a payment terminal directly is possible, evidenced by the ‘PinPadPwn’ research produced by MWR 4, but it is difficult and has certain limitations on what is possible. The level of functionality seen in the malware resident on a payment terminal is likely to have been a result of modified software being loaded onto the terminal before deployment – this could only have been done by resourceful criminals and with the help of an insider.
Insiders that are bribed, blackmailed or coerced into enabling cardholder data thefts have been commonly used for some time – the combination of low wages and high staff turnover make them an attractive target for criminals. These are typically localised attacks however, capturing cardholder data from one location or for a short period of time. More worrying is the ability for criminals to obtain support from insiders closer to the source of POS systems, sending out devices with malicious capabilities before they are even installed in a merchant environment.
Local attacks against POS terminals directly take advantage of their public location – exposed interfaces such as network and USB ports could allow malicious software to be loaded onto a device.
More common attacks involve replacing terminals for malicious copies that record cardholder data – these terminals may not function correctly so the window of attack is limited but can still net criminals a number of cards. Since these malicious devices are connected directly to the network on which the legitimate payment terminals are also placed, these devices could launch further attacks against other devices or be used by an attacker for remote wireless or GSMaccess (as seen in successful attacks against some banks in 2013 5).
As discussed above, POS systems are some of the most critical and yet publically accessible systems in the merchant’s environment. As an entry point to the rest of the network, POSsystems (and the data transmitted by them) should be considered untrusted, or better still compromised, when designing network security. Isolating the POS systems not only helps to reduce the scope of PCI DSS compliance but reduces the risk that they can be used to attack other systems. Restricting outbound network also makes it much more difficult for an attacker to exfiltrate data, and repeated trips to a compromised system are not scalable for serious criminal operations.
Windows XP will become unsupported on the 8th of April 2014, around two months from the time of writing. This immediately places merchants in a position where their PCI DSS compliance is invalidated – a good enough reason for most to upgrade but there is a far greater risk.
An unsupported operating system will not receive updates from the vendor, which means no patches for critical security issues. Any systems still in use will therefore remain vulnerable to attack until they are upgraded or decommissioned. History tells us two important factors:
Dedicated POS systems may be running versions of Windows Embedded which will remain in extended support for a number of years. Merchants should pay special attention to applying security patches in the following years however, as the increase in malware targeting Windows XP would also affect these POS systems until the appropriate security patches have been applied.
From the PCI Council’s PTS (Pin Transaction Security) standard – “SRED stands for secure reading and exchange of data. The SRED module ensures that cardholder account data is protected at the point of acceptance”. Merchants accepting payments using PTS approved terminals from more recent versions of the standard (V2.0+) should find that this functionality is already included in the device. This is particularly relevant in Europe where the majority of transactions take place using Chip and Pin, such that the POS never has access to the information that would be required to clone a card, unlike magnetic stripe transactions (common in North America) where the full track data is sufficient.
The P2PE (Point-to-Point-Encryption) standard provides certification for solutions that take this functionality a step further, ensuring through rigorous cryptographic controls that cardholder data is completely unrecoverable until it reaches the payment processor. Not only does this protect cardholder data but also has added benefits from a compliance perspective, as it can significantly reduce the scope of the cardholder data environment. Currently only a handful of solutions exist but as the standard matures so too do the offerings, and we predict that in the future nearly all terminals will be P2PE enabled.
Version 3.0 of the PCI DSS introduced new controls under Requirement 9: Restrict physical access to cardholder data, focussing on protecting payment terminals from physical attacks. This includes maintaining a list of devices, period inspection and staff training, all designed to limit the risk of tampered or substituted terminals.
The guidance is only considered best practice until June 2015, at which point it becomes a mandatory requirement, though it is highly recommended that these procedures are implemented as soon as possible. In particular, training operators to identify not just terminals that may have been tampered with but also any peculiar behaviour with POS systems. The most important part of this training is having the correct communication channels so that further investigation is timely and effective.
The wave of malware sweeping POS systems may not be unique in its goals or even in some of the basic techniques used. What is most concerning is the sophistication of these attacks – the scale of penetration, customisation of code, established infrastructure, and execution across multiple countries. These types of attacks are not the domain of ‘script-kiddie’ style attacks with off-the-shelf malware or even local criminal gangs looking to exploit a merchant, but are executed by organised and talented groups.
Developments in this sector are coming thick and fast, with mobile point-of-sale (mPOS) devices enabling more merchants to accept card payments than ever before, and presenting exciting opportunities for established merchants to interact with their customers. With retail environments so keen to enable sales to be as swift and enjoyable as possible, security of new features can get overlooked.
POS systems need to be well protected, more so even than conventional network devices, due to the nature of information they handle and their exposure to the public. This takes a range of skills in network architecture, system hardening, regular maintenance, compliance and incident response. Don’t rely on a vendor to provide an out-of-the-box secure system for your environment, test those critical systems yourself.
Look out for the next article in this series examining the anatomy and attack surface of a POSsystem.