Visa typically releases security alerts based on their findings when breaches occur. A recent Security Alert issued July 27, 2020, provided information on new malware variants identified in a Point of Sale (POS) compromise of a North American Merchant. If you are a merchant with point of sale systems (POS) accepting the EMV® Chip, and/or if you have implemented a Point-to-Point Encryption (P2PE) solution, you may want to have a quick read and then confirm the security posture of your POS implementation.

The exploits found during the forensics investigation of this North American Merchant included:

• • • Alina POS -  Dating back to late 2012, uploaded throughout 2018 and most recently May 2019
    • Dexter POS - Approx. since December 2012
    • TinyLoader - First seen in November 2015
      
      

The threat actor successfully gained access into the Merchant’s environment though it still has not been determined how they entered the environment. Once there, they were able to take cardholder data from the POS memory (RAM).

Visa released this statement:

“The implementation of secure acceptance technology, such as EMV® Chip, significantly reduced the usability of the payment account data by threat actors as the available data only included personal account number (PAN), integrated circuit card verification value (iCVV) and expiration date. Thus, provided iCVV is validated properly, the risk of counterfeit fraud was minimal.”

Upon an initial reading of Visa’s statement, someone not as familiar with the way an EMV® Chip works may have had a lifted eyebrow as to why the usability of the data was only significantly reduced since the threat actors would have the PAN, iCVV, and expiration date. Let’s dig into how the EMV® Chip reduces risk, and look at what could go wrong.

The iCVV is different from the CVV in that the iCVV is a dynamically-generated, one-time use only code. The iCVV is similar to multi-factor authentication – a threat actor would have a very narrow period of time to use a one-time password due to how quickly it changes. For a dynamically-generated, one-time use code, one would assume the code couldn’t be used in a second transaction, so there wouldn’t be a risk because the transaction would be declined, right? Well, as with so many things, it depends.

What’s the catch, and where is the vulnerability? You may have guessed this - not all transactions being authorized actually perform validation against the iCVV. Therefore, the fact that the iCVV is a one-time use only code doesn’t buy you security because the implementation doesn’t validate this information properly. For the iCVV to be effective, it must be checked for each transaction to make sure an attempt at a second use would not work.

This security alert went on to state:

“Additionally, many of the merchant locations employed point-to-point encryption (P2PE) which encrypted the PAN data and further reduced the risk to the payment accounts processed as EMV® Chip.”

As Visa’s security alert states, the other bit of good news is that many merchants now use P2PE. With a P2PE solution in place, the card is immediately encrypted upon swipe/dip/tap and the decryption key is held by a third party. Therefore, the credit card data in RAM is in an encrypted state, and the Merchant does not have access to the key. Even if the threat actor has infiltrated the environment of the Merchant and can scrape RAM to take this encrypted card data, they cannot obtain the key from this Merchant’s environment.

What security systems could have identified this issue? A vulnerability scan might pick up a vulnerability that is being exploited by malware, but generally speaking, scanners do not look for malware. Anti-virus software should have found the malware, logging should have detected the creation of the system-level objects, and change-detection monitoring should have sent an alert for the change.

So what’s the moral of this story?

If you do the following, less can go wrong:

• Best case - properly implement a PCI-approved P2PE POS solution.
  • Confirm the encryption is working at swipe so that the card number is encrypted before data is passed to the POS.
  • Add tight, explicit egress rules in the firewall to help prevent data exfiltration.
  • Ensure you are logging and monitoring traffic and reviewing it on a continuous basis.
• If you are using an E2EE solution, confirm where and how the encryption is occurring. Keep in mind that both P2PE and E2EE solutions encrypt payment data at point-of-interaction with the payment type Swipe/MSR, Dip/EMV, and Tap/NFC. The difference is what happens after the transaction leaves the Merchant’s environment. With E2EE, the encryption should be at the POI through to the processor of the transaction. For P2PE, once the data gets to the payment gateway, the packet is decrypted and then sent in an encrypted, clear-text manner to the relevant processor for processing.
• Minimally - properly implement EMV® Chip.
  • Ensure the transactions validate the iCVV.
  • Ensure proper detection and alerting procedures are in place from security systems.

This threat would have been minimal to the Merchant, even with the malware on their systems, if the steps above had been followed. Organizations that have implemented the EMV® Chip and P2PE are way ahead of the game; however, always keep in mind that if not implemented correctly, you won’t reap the benefit of the implementation, and you could still be in a vulnerable state.

For all of your PCI and infosecurity-related needs, our team of security experts is here to help! Contact us today with your questions.