Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: One More Day of Trolling in POS Memory - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
One More Day of Trolling in POS Memory

Further to the recent story on Memory Trolling for PCI data, I was able to spend one more day fishing in memory, I dug a bit deeper and come up with more fun Credit Card / Memory goodness with our friend the Point of Sale application.

First of all, just searching for credit card numbers returns a lot of duplicates, as indicated in yesterday's story.  In the station and POS application I was working with, it turns out that if you search for the card number string plus the word "Approved", a single line was returned per transaction, with the credit card and PIN.  For instance, to find all Visa card transactions (one record per transaction):

strings memdump.img | grep VISA | grep -i APPROVED  | wc -l         
     323       

In addition, I was able to find several hundred debit card numbers, simply by using those same search concept, but using the term "INTERAC" instead.  Note that this search gets you both the approved and not approved transactions.

strings memdump.img | grep INTERAC | grep -i APPROVED | wc -l
     200

With that done, I started looking at the duplicate data, and realized that some of the duplicate "records" I was tossing out looked interesting - sort of XML-like.   Upon closer inspection, it turns out that they were fully formed MS SQL posts (and no, just as the credit card numbers themselves, I won't be sharing the text of any of those)

Interestingly, the SQL post formatted the credit card numbers as 123456******1234, such that the first 6 and last 4 digits are in clear text,but the middle digits are masked out.  

This lines right up with the PCI 2.0 spec, section 3.3, which indicates that if you mask a PAN (Primary Account Number) that way, it is no longer considered sensitive. (https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf).  I'm not sure how keen I am on 3.3 -  - I can see that storing this info allows the merchant to use that as a "pseudo customer number", so that they can track repeat purchases and so on, but I'm not sure that the benefits outweigh the risks in this case.   I'd much prefer encrypting on the reader itself, so that the merchant and POS software never sees the card number at all - it's encrypted right from the reader to the payment processor (or gateway).

As I said when I started this, I'm not the expert memory carver that some of our readers are - please, use our comment section and tell us what interesting things you've found in a memory image!

===============
Rob VandenBrink
Metafore

Rob VandenBrink

458 Posts
ISC Handler
Dead on with the last comment. If there is encryption performed on the pin pad/PED and the merchant does not have access to the encryption key then memory scrapers at the OS level are irrelevant since all the card data is transiting as pseudo-random noise. Remove the thing of value from the merchant. This would leave the merchant open only to physical skimming attacks, at least for card present transactions.

This shifts the burden to the PED manufacturers and owners of the end to end encryption (banks) who would have to be careful on key injections using hardware security modules (HSM) for initial and remote key injection (RKI) for rotations.

Lastly if all merchants required entry of the last 4 digits printed on the card into POS and it programmatically compared them to track1/track2 data, fraud would drop due to complexity.
Anonymous

Posts

Sign Up for Free or Log In to start participating in the conversation!