Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC Internet Storm Center

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Latest Diaries

ISC StormCast for Thursday, August 28th 2014

One More Day of Trolling in POS Memory

Published: 2014-08-27
Last Updated: 2014-08-27 23:36:35 UTC
by Rob VandenBrink (Version: 1)
0 comment(s)

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         

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

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. (  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

Keywords: carving memory
0 comment(s)
ISC StormCast for Wednesday, August 27th 2014

If you have more information or corrections regarding our diary, please share.

Recent Diaries

One More Day of Trolling in POS Memory
published 7 hours ago by Rob VandenBrink (0 comments)

Point of Sale Terminal Protection - "Fortress PCI at the Mall"
published 2 days ago by Rob VandenBrink (3 comments)

Trolling Memory for Credit Cards in POS / PCI Environments
published 2 days ago by Rob VandenBrink (2 comments)

UDP port 1900 DDoS traffic
published 2 days ago by Jim (3 comments)

Unusual CRL traffic?
published 2 days ago by Jim (2 comments)

NSS Labs Cyber Resilience Report
published 5 days ago by Guy (1 comment)

OCLHashCat 1.30 Released
published 5 days ago by Richard (0 comments)

Now supporting OpenIOC via our API!
published 6 days ago by Alex Stanford (0 comments)

View All Diaries →

Latest Discussions

Brown Breach.. . UPS
created 1 day ago by ICI2Eye (0 replies)

So, how dead is antivirus exactly?
created 1 week ago by Safensoft (0 replies)

recommender system for network intrusion detection
created 1 week ago by Anonymous (2 replies)

Stale prefixes associated with our AS
created 3 weeks ago by cj (0 replies)

DSHIELD with fail2ban
created 1 month ago by Ernest (0 replies)

View All Forums →

Latest News

View All News →