Numaan Huq and Richard Wang of SophosLabs have been keeping track of the evolution of Point-of-Sale malware.
We’ve recently been tracking a set of incidents involving malware attacking Point-of-Sale (PoS) equipment.
Your personally identifiable information (PII) flows into PoS devices, across PoS networks, and is processed by PoS servers, every time you pay for things without using cash.
As a result, PoS equipment and the local-area networks to support it are found all over the world, in both developed and developing countries.
When was the last time you tried to pay for a hotel stay in cash, for example?
Even if you settled the bill with cash, you probably swiped or waved a payment card when you checked in, just to avoid having to lay down a large cash deposit.
As a result, PoS systems are a lucrative target for crooks.
So it’s not surprising that we’ve written about this particular malware family, Troj/Trackr-Gen, and its thirst for credit card data before.
It seems the criminals behind it have added a few new tricks in the last 15 months.
The most interesting development is that some versions now include the ability to exfiltrate data directly rather than just dumping it to disk.
→ The Payment Card Industry has a set of Data Security Standards, known unsurprisingly as PCI-DSS. The standards specify, amongst other things, that credit card data must in general be encrypted if it is stored, and that some data, such as CVV numbers, mustn’t be stored at all once a transaction is complete. Ironically, the crooks have learned from this, and are avoiding reading from or writing to disk themselves.
Another change is found when examining some of the targets.
As before, the criminals are avoiding very large businesses but in addition to the commonly attacked hospitality industry and hotel targets there are smaller victims, including a single car dealership in Australia.
A couple of cosmetic changes have also been made.
There is a new generator for random filenames, creating completely random five-character names such as IXWIG.exe and KPAOE.exe.
For variants using hardcoded names the common use of rdasrv.exe has been extended to include filename options designed to hide in plain sight such as windowsfirewall.exe or msupdate.exe.
It seems that no victim is too small for Point-of-Sale malware.
The popularity of terms like “Advanced Persistent Threat” and “state-level malware actors” may make it sound as though only the biggest multinationals and parastatals are at risk these days.
But stealing $75 each from 1,000,000 people gives the same financial result as stealing $75 million from a megacorporation.
So you simply cannot assume that your business or organization is not a big enough target to worry about web attacks or targeted malware.
Remember this: there is no radar below which you can fly.
As a final thought, since we already know the how and the why of this latest round of PoS attacks, we invite you to consider the where.
There’s an intriguing hint buried in the code:
We don’t know if that’s where the crooks are from, or if it’s where they’ve been most successful in infiltrating PoS networks (Botswana, home to the astonishing inland Okavango Delta, has a strong hospitality industry), or perhaps just where they spent some of their ill-gotten gains on a vacation.
Do you run a small business that relies on PoS equipment?
If so, how much of a challenge are you finding it to stay ahead of crooks like this?
Have your say in the comments…
Image of PoS machine courtesy of Shutterstock.
How do they get the malware in the PoS system?
Depends. One way is to get in through the back door using an insecure setup of RDP (remote desktop protocol – Microsoft's "do it from a distance" network admin tool).
For example:
http://nakedsecurity.sophos.com/romanian-hackers-busted
http://nakedsecurity.sophos.com/microsoft-rdp-remote-desktop-protocol
Then there are USB keys, legit-sounding (targeted) emails, compromised websites…
I don't like using these PoS devices, perhaps it's partly due to my age. Only a few days ago, I purchased a new item for the house and was asked to input my PIN # into the device that looked just like the one in the picture above. What really bothered me about it was I noticed the salesperson watching me as I pressed each button. Perhaps that's not too uncommon, but all the same, I felt like saying, do you mind looking the other way.
The question asked was "do you run a small business that relies in PoS equipment?"
But as a consumer, I rarely feel comfortable using them. Too often the clerk or a customer behind me in line perhaps not intentionally but all the same, watches as I key in my #.
I hope these devices are soon to be on the way out & a new generation of devices replace them that takes prying eyes into account.
Thanks for letting me vent. 😉
Three things you can do.
1. Ask with disarming politeness that the salesperson look away.
2. Cover the keypad with your other hand, a magazine, or somesuch. (Easier said than done in some retail environments. But this helps ensure you're not on camera, either.)
3. Ask if you can swipe and sign, assuming you have a credit/debit card facilitity and are willing to use it.
Your discomfiture in using EFTPOS machines when you think others are watching is entirely reasonable. If it has to do with your age, it's because age has made you wiser…
Oh. There's a fourth way, too, which works really well.
4. Pay cash.
They can't get your money just by knowing your PIN. They have to have your card as well.
It is only a problem if they look at your PIN then mug you on the way out…
Your PIN is truly personal. No-one is supposed to know it but you, so anyone who seems overly inquisitive about it ought in my opinion to be treated with the utmost suspicion.
(I'm pretty sure I have experienced getting a card replaced and that the old PIN worked with the new card – the PIN isn't on the card, after all. Indeed, the bank doesn't need to know it, just how to verify that you do. Since fraudulently replacing a card is IMO a lot easier than getting someone's PIN, the latter should be considered the "big" secret…)
Usually if your card is just replaced after expiry, your PIN remains the same if you're card is stolen then your PIN is changed too.
Really!! You think the PIN is not on the card? Think on… those devices like a small calculator, which the bank provides to generate a code number, ask you to enter your PIN. Then they tell you whether it was correct… right. Well those gizmos are usable with just about anyone's chip and PIN bank card so don't go thinking that the bank hid you PIN in the gizmo before they sent it to you. Logically, it reads your card (or anyone elses) to determine the PIN, then checks with what you key in. My conclusion… the PIN is on the card.
As someone who has worked in banks on card cryptography I can tell you the PIN isn't on the card.
Not sure what you're talking about with the 'small calculator' but it sounds like either a challenge-response code generator or a time based pin encryptor (the time based code + PIN = working PIN). Either way there is no need for a bank to store the PIN on the card (or even at the bank as they just need to store a PIN verification value which the bank can generate from the PIN to validate the transaction).
Thank you for your reply. I can't match your professional experience in the field. The device I was referring to sounds like what you term a challenge-response code generator (key in the PIN and if correct it generates a code). I'll refer to it as a CRCG,
There is no need to register the CRCG with the bank; it responds to cards from different banks and different account holders, so it is what I would term 'account neutral', I take your word that the PIN is not stored on the card, but surely there must be information within the card chip, which is being read by the CRCG and which enables the CRCG to determine whether or not the PIN is correctly entered. It may well be that the PIN is not stored in its simple familiar form within the card, but I believe that it is there together with the account number in a form decipherable by the CRCG.
@ Robert, I think the first image at the top of the article is misleading. What the writer is referring to, I believe, is PoS software on a PC that does processing through the internet. If the software is out of date, not PCI compliant, or the network that the PC is connected to does not meet DSS standards, it can be compromised and then this malware/virus can harvest that info from the POS software. Most small to medium businesses utilize registers that are PC based where the merchant uses a PC as the register, with peripherals such as a scanner, credit card reader, receipt printer, etc. This creates a point of weakness for an attacker because it is a way in. If the merchant does any volume of transactions they will be required by the Credit Card company's to maintain a certain level of PCI-DSS compliance in order to accept their credit cards at that establishment, because the Credit Card companies do not want to eat the loss when the merchant is breached due to the merchants negligence.
A few comments if I may. The picture is perhaps a bit too cute – I didn't mean to imply that the crooks could inject the malware via the handheld device.
(Mind you, we have had cases where the malware was inside the device – in one case I know of, in Europe, the devices were compromised in the factory and delivered with keylogger software and a GSM modem to upload the data overseas. In Perth, Australia, crooks swapped regular devices for hacked ones at the drive-throughs at a chain of burger joints. The devices were handed into the car on a long cable; driver distracts, passenger signs, but not before switching the device for spares, probably bought online.)
But I did mention "PoS LANs." There are usually PCs and servers on the same network as the EFTPOS devices. That's how it works. For all you know, the PoS network might be connected to, or even part of, the company's regular office network.
The POS terminals that use standard phone lines to transmit data are not hackable. They do not store any information. Those that use highspeed internet are potentially risky.
The POS systems that also process card transactions can be hackable. There are PCI-DSS tests that will see how "non-sticky" a credit card processing POS system is to attacks; the less sticky they are, the better.
Merchants balk at paying a $300 PCI-DSS test fee, but if they are non-compliant and get hacked, the penalties are in the thousands of dollars for the first violation, and escalate after that.
From my personal experience, it is even worse in Iran, as many of PoS systems use plain text XML calls for money transfer …
Paul, have the bad guys yet gone after the network-based check (or cheque) verifier devices and their network communication?
I have to admit I am not sure. I live in Oz and apart from the occasional cheque from a public service agency (e.g. tax refund), I never see them, and have never seen anyone spending one…not in a retail setting, anyway. So I've never seen a cheque verifier, either.
How will a general user come to know about this.
Good question – it depends. Some countries don't have "mandatory disclosure" laws, so they can lose your personal data and keep it quiet.
One standard piece of advice that helps: check your statements carefully for transactions you didn't make…
How can a business owner check if they have been compromised and what can they do about it?
For this malware, a system scan with a freshly-updated anti-virus would be a god start…
If you find something suspicious along these lines, then you'll want to cleanup the malware, and perhaps also ask someone you know and trust to advise you on what else might have gone wrong…
A friend was asking the other day what people thought of the phone based card payment systems for small businesses. Any comments?
I have one when I do work outside of my day job, and im not overly impressed:
I thought they would work in a way that buyer places card into mobile reader, verifies amount and enters pin, returning device to seller. This is _not_ the case.
Buyer puts card in card reader, buyer then needs to insert phone number, transactions details are then sent in an sms to the number provided, which prompt the buyer to go to a webpage to complete the transaction.
If its a pinless card, then you can sign on the screen of the device.
A few questions were raised as to why need the reader in the first place if the rest of the transaction is made online, without needing the reader. It looks like your skimming the card when its placed in to the reader and then handed straight back to the customer for them to enter the details in manually.. why use this first step..
Also, you're not very well protected with these payment methods. You actually have to wait a long time to receive your money, as if there are any disputes or problems with the customers account, you lose out, not them. They have very little power over banks, so they cant really do much in terms of 'fighting your corner' if a transactions goes sour.
Also – with your finger, try accurately signing your signature.. its hard. And this apparently is enough evidence to reverse a transaction if the signatures are not close to identical.
I guess the plus side is the device/reader/app never knows your PIN, so whilst it might be able to extract the card details, it never has details + PIN.
Apparently it works in this way due to the regulations on PoS devices, smartphones are not allowed to accept PIN's – so the limitation is from the banking system rather then the apps developers.
"I didn't mean to imply that the crooks could inject the malware via the handheld device. "
Uh, they can actually:
http://www.wired.com/threatlevel/2012/07/pinpadpw…
In that article, the devices were pwned due to a vulnerability, but the malware (if I read correctly) was injected onto the device from some other host on the network, right?
The malware wasn't entered or uploaded *via* the device itself, merely onto it.
No, the exploit was executed simply by using a custom card inserted into the device.
"The attack the researchers used involved a stack-based buffer overflow vulnerability in the EMV protocol that is used to process chip-and-PIN cards. Using that vulnerability the researchers were able to install malware on the machines to take full control of the terminals, by simply inserting a rogue payment card containing the malware into the smartcard reader."
Ouch!
You're right…I didn't read correctly. "Pay-n-Pwn," indeed.
In many places these devices are now wireless…
How difficult would it be for someone with the expertise to sit outside with a laptop and get into that system?
Ask TK Maxx 🙂
That is a problem, which requires re-encyrption every year. Wireless devices reach an end-of-life status which means they will be useless after a certain date b/c criminals figure out ways around security systems. So every year, the wireless devices are re-encrypted, and the merchants are charged.
When wireless POS systems were introduced, it took a short while to hack the data. Then the data was split into 2 streams of data. Hackers figured out how to download and recombine them. Then the data was split into 3 streams, which hasn't been successfully hacked yet. But it's just a matter of time.
Beware of any wireless system that does not have encryption fees, each device needs its own encryption.
It's said that the PIN is not recorded/stored on the card. Can anyone explain how, when you insert the card in the POS terminal and enter your PIN, it then confirms the PIN is correct within a fraction of a second? Only way it can be that quick is if the PIN is on the card in some form as the data connection to the provider's server is not that quick.
Plus, why can't the provider update the PIN for that card by telephone? The card has to be inserted into a reader of some kind, usually at an ATM, for the change to be made. That allows the card data to be updated immediately by writing to the memory chip or the magnetic strip.
Comments?
I think that some sort of checksum generated from your PIN is stored on the card, but your PIN cannot be derived from this checksum. When you type in your PIN, a checksum is calculated and compared with that on the card.
Catch 22 situation.
Use electronic payments and you could open yourself up to theft, use cash and you get reported to Homeland Security!
Only way to see what is going on is to use some sort of behavioral analysis on your network communications. I.e. why is my pos PC trying to send data out of my network to a site in russia when all my bank authentications are done from a central device that communicates only with my bank/visa/etc (of which I know the IP's they are communicating with). You cannot rely on AV/IPS/Firewalls they don't work
I hear what you're saying, but it's slightly circular. "All you need to detect this sort of fraud is a system that knows how to detect it."
Incidentally, the "behavioral analysis" you describe is exactly the sort of thing that a decent combination of anti-virus and firewall (on your computer or at the network edge) does.
Yes, Sophos sells all those sorts of product, so "I would say that, wouldn't I?" But it's true 🙂
Sophos Endpoint Firewall, for instance (which is more of a network connectivity management tool than a traditional firewall, but we're stuck with the name) can do just what you're suggesting. "Hey, that software is new, flagged as unusual by the anti-virus engine, and trying to make network connections. That's not allowed."
Like any security solution of the behavioural sort, it can't and doesn't come with a 100% guarantee, but it does work in the way you describe.
There are programs out there that will analyze the source of the transaction and run it against a number of different metrics including the country of origin. If it hits any prohibited targets it is blocked.
Are there any utilities that check against the various hashes discussed in NCCIC | US-CERT TA14-212A?