Preventing POS data breach

Background

Espresso? Sure why not!

With so many people talking about Point of Sale (POS) data breaches and so many of them happening over the known history of computer crime you have likely been lead to believe that POS is a hard thing to secure and that sophisticated crooks are chasing POS systems every day.  Welllllll like most things in life they are not always like what you think they are.  For those of you that have ever had to do Pen Testing or worked on a major incident you know that everything you read and see if the press and from Hollywood is just pure hokum.  The POS incidents are no different.  Bear in mind I'm not on the inside at the most recent one, but as per my previous post it's most likely yet another RAM dumper (YARD is my new acronym.  God knows the IT industry needs another acronym).  I hope this acronym demonstrates the lack of surprise I have when dealing with this type of malware.

I remember when I first saw this type of malware and thought "wow how the hell do you stop someone from stealing plain text data in memory".  After a bit of contemplation you realise the answers are pretty simple because I was asking the wrong question.  Firstly, like every piece of sensitive data, if you don't need it, don't store, process or transmit it.  Yep as I said - simple but not always achievable.  If your business is not able to live by the "golden rule", then you must live by the "silver rule" which is "keep the bad guys out of your sensitive data". This is all common sense really, but common sense is not often applied practice and business large and small get caught out every day.

The moment of realisation

Merchants that become a victim os POS data breach typically as at least one of the following statements:

1. We didn't know they had any sensitive data
2. My vendor told me there was nothing to worry about
3. It's been working for years why now?
4. Why would someone from <Eastern-Eurpoean-country-here> login to my computer in <anywhere>?
5. How did they find my computer/network in <anywhere> and how did they know where to look?
6. I didn't tell anyone so how did they know my password?

From this list of statements you can see the general understanding of most merchants is pretty low and they don't have much capacity to look for problems they didn't know existed.

Preventing and stopping RAM dumpers

In the previous blog entry I talked about RAM dumpers and scrapers. Given the US POS environment it is necessary for the card data to be in the RAM of the POS system in plain text, so we have to protect the system from having bad guys on it. Follow the PCI-DSS and you're almost certain to be good.  The PCI-DSS is a very large document and will take a lot of time to digest and even more to implement.  A more abridged list to maximise effectiveness of  controls is:

1. Do not use vendor default passwords especially for remote access (Yes this REALLY happens still today). This means use unique passwords for vendors as well.  In days gone past (I hope) support vendors used to use their company name as the password for the hundreds or thousands of POS devices.  What could possibly go wrong hey?
2. Run the POS systems as an unprivileged user. Seriously why in the world would a POS need to run as admin?  There's only three answers - stupidity, laziness and really bad software.  Neither are acceptable.  
3. Really restrict access to the payment network.  Most POS are protected by a single credential and a large proportion of POS have unfiltered outbound Internet access.
4. Remove Internet access from the POS network.  Why does a POS need Internet access?  If you are using Internet based payments, filter access to the necessary addresses/ports and nothing else.   I've seen POS' send data and alerts to drop servers via email, FTP and HTTP.  There is simply no need to provide a direct outbound path for malware to send data.
5. Any connections in/out of the POS network must be authenticated.  
6. Monitor your POS devices for new services and processes.  Most POS malware must remain memory resident and will be installed as a service or as an auto-start application.  A new service or auto-start application on a POS is a big red flag and must be investigated. If you have least privilege on  your POS this should not happen anyway.

Of course there are ways to circumvent many of these controls, but realistically very few bad guys want to put in a whole lot of effort when there is so much low hanging fruit out there.  It's back to the old saying, "when you are being chased by a bear you only have to out run one of your mates to be safe".  It's similar in cyber-crime, but the analogy does not hold true for ever so we have to continuously improve our defences and detection of events.

Read More

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

Read More