RAM scraping/dumping in the payment card industry - or being a target

There's too much talk and not enough information about this topic in my opinion.  Many people and experts are getting spun up about the Target breach.  It's a lot of cards and from a major US brand, but we've been down the road before and with the same type of malcode.  I haven't seen the malcode yet, but everything points to it being a RAM scraper/dumper of which I've seen plenty in the past.  This malcode has been around in various guises since 2009 in the payment card space.  There's not a lot that can be done from an infrastructure point of view in the US given the current merchant payment architecture.

I want to try to take some the of the mystique away from this issue by explaining it simply.  Hopefully I can achieve that.  Most payment applications in the US take the payment card data from the magnetic stripe in the form of what is called Track 2.  This is a standard format for reading/writing the necessary information on a credit card.  It has many different components which are not that important in this discussion.  The important thing to note is that Track 2 data follows a standard pattern that is well known, repeatable and predictable.  Couple that with over time equipment to reproduce magnetic stripe credit cards has become very inexpensive, so the barriers to entry for bad guys have reduced dramatically.

The PCI-DSS addressed the vulnerabilities in plain text payment card data processing by requiring data at rest (on a disk) or being transmitted (on the wire/Internet) to be encrypted.  PCI-DSS also requires all access to the payment system to be authorised.  The problem is that in many POS environments (like most in the USA) the payment card data cannot be encrypted when it is being processed.  For the POS the vulnerable point is when the swipe is made of the mag stripe card.  The data from the mag stripe is read and in the memory of the POS system for processing the payment.  Most POS are Windows based and have the same well known flaws as any Windows system.  In addition the poor old POS tends to be overlooked for maintenance as they are hidden under a desk, difficult to get at, and if you break them you literally stop the cash register from ringing.  In short many POS are often old machines that are barely functional.  You couldn't even play a decent PC game on them or run a video on YouTube, but they are serviceable for their intended purpose.

Back to the malware that is installed on the POS by bad guys with unauthorised access.  Simply put this malware does a 3 stage process:

1. Dump the memory for the POS process - i.e. the process that received the Track 2 data
2. Run a regular expression (a search for Track 2 pattern) on the output of the POS process
3. Stores the extracted data locally for manual collection by the bad guys or send it out of the network

Believe it or not this is not terribly difficult to do and can be done with a few simple standard tools.  I made a video of this on a test system in my lab.  I used a two Microsoft tool (Sysinternals) tools procdump.exe and strings.exe to access the memory from my process MSR605 that received the Track 2 data. Then I used grep.exe from UnxUtils to find the Track 2 data.  Once you have the process it becomes a repeatable, cookie cutter approach to access memory, use the regular expression to find and extract the data.

The link to the video is here if you want to see how easily this can be done.

In this test I did not bother to use a real POS application as this would simply be a cosmetic update to the proof of concept and likely got me sued by the POS vendor.  Rather I used the card reader/writer software that came with my MSR605 reader and writer I purchased off eBay for under $200.  This also came with a number of blank cards that can be written to emulate a legitimate payment card.  I used this equipment to make a fictitious card with test data for the late, great Joey Ramone.  Then with the data that I was able to extract from memory I would be able to make a copy of my fictitious card with test data.  Fraudsters use the same process to steal payment card data from POS devices and make fake cards for purchasing goods from stores.

The card looks like a white piece of plastic with my writing on the front side.

Front of fictitious test card

Back of fictitious test card showing magnetic stripe

Test card in reader about to be swiped/read

Of course the fraudsters do this on an industrial scale and write far better code than I can to ply their trade.  But we need to keep our heads and remember that this is nothing new or frightening and it's going to take a change by merchants to keep bad guys out of the POS environment to make this problem go away in the short term.  Let's face it, if you have people with unauthorised access in your payment channel bad stuff is going to happen eventually.  If you have plain text cashable data and bad guys in your payment channel it's going to get stolen sooner rather than later, and if you have a LOT of this cashable data, like a US based retail giant, then you are a giant TARGET.

Hope this is readily digestible to the community and helps demystify some of the discussion.

goma