How cardholder data can be stolen before it reaches the Merchant

In a couple of recent attacks cardholder data has been stolen even before it entered the merchant's or payment processors systems. In fact it is stolen from within the browser the cardholder was using to enter their payment card details. This attack, even although the card data theft is not actually occurring in a merchant's system is the result of a security weakness with the merchant's security.

The attack is a Cross Site Scripting Inclusion (XSSI) attack and on a simply level it occurs where a payment page has a link to a script hosted on another domain that provides functionality the merchant required. Due to the nature of how the script is called, it bypasses the principle of the same-origin policy and allows the script which is from a different domain to the hosted page, to read the document object model (DOM) of the page it is called from, giving it the ability to read the contents of forms such as those contain card holder data. If that script is malicious or compromised through a security failing on the part of the provider who is hosting it then the merchant's page is compromised. The merchant's security failure is failing to recognizing the risk of using an external hosted script and ensuring it is secured. There are techniques such as Sub-Resource Integrity (SRI) that can be used to determine if a called script has been compromised through the use of cryptographic hashes. Additionally the supplier of the script is part of the supply chain and the security of the script and hosting paltform should be part of the due diligence checks on the supplier.

A typical attacker scenario would be an attacker looking to compromise card data will find a merchant with payment page, examine the source code and DOM of the page using a web proxy and other tools and identify the use of an externally hosted script. The attacker will then examine the security of script hosting platform and if possible compromise any vulnerabilities and replaced the existing script with a malicious script designed to scrape the payment forms and send the harvested data to systems the attacker has access to, often other compromised systems.

The flow of the attack is described below

1)     Attackers compromised the 3^rd party’s server through a vulnerability and replace scripts on that server that are used by merchants with malicious code.

2)     A cardholder clicking on checkout caused their browser to request the payment page to be called from the merchant’s server.

3)     The page contained a link to the 3^rd party’s hosted JavaScript is rendered in the browser the link is executed and the browser requests the JavaScript

4)     The previously compromised script is loaded from the 3^rd party’s server and executed in the browser

5)     As cardholder details are entered in to the fields within the payment form the malicious script reads them and sends them to the attacker’s server

The scenario and diagram show how XSSI can be used to compromise data in a browser rather than a merchants own systems and often through a system that does not belong to the merchant. It shows how attackers are looking at end points where security may be lower than an internal system owned by a merchant. Merchants recognize having an internal systems processing card data is at high likelihood of being attacked and outsource payment processing using techniques such as silent order posting to send data direct from a form within a browser to the payment processor but a simple script can provide the foothold an attacker needs to steal payment cards before reaching the merchant or payment processor.

PCI DSS: Are you meeting the new mandatory requirements.

On the 31st January 2018 a number of the requirements in the PCI DSS v3.2 become mandatory; which means since that date you should have the relevant controls in place to meet those requirements. The standard requires for the controls to be in place from at least the end of January and not left until your certification renewal date.
For all organisations you should have implemented the following if applicable

• Requirement 6.4.6 requires your change management processes be enforcing that upon the completion of a change, all relevant PCI DSS requirements on any in-scope system, process or documentation has been updated as applicable 
• Requirement 8.3.1 requires all administrative access to the CDE across your own network should have multi-factor authentication (MFA) in place that meets the requirements of the PCI DSS. The SSC have published a guide on the use of MFA, the implement MFA should be using at least two out of the three authentication methods and not the same method twice and there needs to be independence between the authentication methods used.

For service providers the following should be in place if applicable

• Requirement 3.5.1 requires a documented description of your cryptographic architecture that details all the algorithms, protocols and keys used to protect the storage of card data that includes details such as the key strength and expiry dates of keys and certificates. It should detail what the keys are used for to ensure the correct strength keys are being applied and you need an inventory of all components used in protecting keys ie Secure Cryptographic Device (SCD) or hardware security module (HSM).
• Requirements 10.8 and its sub requirement 10.8.1 require a policy, procedure and process in place to detect and respond to failures in your critical security controls, a list of common critical security controls is given in the requirement, but the list is not definitive and other security controls such as patching should be monitored. The response should include how security functions are restored, documented, analysed, risk assessed, remediation requirements and lessons learnt.
• Requirement 11.3.4.1 requires service providers to perform penetration testing on segmentation controls; if there are used; at least every six months. All service providers will need to of completed a penetration test of their segmentation controls within six months of the requirement becoming effective and August 1, 2018. 
• Requirement 12.4.1 requires the establishment of a PCI compliance programme with responsibilities for the programme defined, it should also define how the executive management are informed of the state of the compliance programme by periodic updates. There is a requirement for a charter document to cover the establishment of accountability and communication to the executive management that is signed by the executive management.
• Requirement 12.11 requires you to be holding at least quarterly reviews to confirm personal are following security policies and operational procedures.  It is now coming up to 3 months after deadline when the requirement became mandatory. Have you held you first review yet? Your compliance status is in jeopardy if you haven’t. A QSA conducting a RoC on a service provider is expecting to see evidence of the quarterly reviews since 31st January 2018 for you to be compliant even if the audit is being conducted in December of this year.

PCI DSS requirement 10.8 and physical hosting services

One of the now mandatory requirements since 31 January 2018 of the PCI DSS standard is requirement 10.8 which requires service providers to implement a process for the timely detection of failures of critical security controls systems. Historically service providers that just provide a physical hosting service where they provide the physical space for a client to put their own equipment in and the service provider gives physical security, power and internet connection to the empty racks have certified to meeting just requirements 9 and 12 of the PCI DSS and their clients are responsible for all the other requirements. Since the end of January service providers should also be implementing processes where the access control systems are monitored to provide timely detection of failure.

A common failure of CCTV is where the storage of recordings to meet the 3 months requirement (9.1.1) is based on the frequency of triggering of the camera and the resulting clip being saved to disk, the issue occurs when the frequency is higher than expected and the disk space is used quicker than estimated and roll around occurs before the end of the 90 day period with new files overwriting the oldest files such the 90 storage period is not meet causing a failure of the access control system to meet the requirements. A hosting provider can implement a check on CCTV access control systems for the oldest date of recording and ensure this exceeds the storage requirements either programmatically or by physically viewing the oldest clip for each of the cameras.