"It wasn't me. It was that POS system that swiped my card!"
Banks, like insurers, always seek a way out without paying up!
You could be getting more than you bargained for when you swipe your credit card this holiday shopping season, thanks to new malware that can skim credit card info from compromised point-of-sale (POS) systems. First spotted by security firm Seculert, the malware dubbed "Dexter" is believed to have infected hundreds of POS …
Banks, like insurers, always seek a way out without paying up!
This is where the other, more profane version of the POS acronym is rather accurate.
How many times the banks have known about this kind of thing but have never bothered telling the customer. The onus is on the customer to find and then prove the loss.
Oh, it was me when I bought my groceries, but it definitely wasn't me in the offie next door. Hic.
Using "pled" should be considered as big a crime as credit card skimming.
Technically, there is nothing wrong with "pled". It is a fine old English word dating from the 16th century. Granted it is nearly obsolete in British English, and is not considered quite standard in American English; it is however a common variant in legal usage.
What next? Whilst?
Absolutely, nothing wrong with "pled". I nearly leapt out of my chair when I saw that good old English word dissed. I wouldn't regard it as obsolete either.
Through a payment card used as a carrier of some kind to place this trojan on a POS.
Either that, or I would start looking at the technicians who have installed or serviced Dexter-infected POS, and whether any of those technicians just bought a new Mercedes....
Shouldn't all card information be encrypted on the pinpad before it's sent to the POS?
Yes, but then the POS has to decrypt the information and then RE-Encrypt it the backend's key so that the backend can then in turn decode and then re-encode it with the payment processor's key. Plus there's the fact the first step can be skipped if the POS itself has a stripe reader.
In any event, threat exposure depends on how the POS is connected. I know some retail POS systems don't connect to the Internet but rather go through corporate intranets that don't touch the greater Internet. This limits their threat exposure since it would take an insider or someone at the update system to get the malware in.
No, you can't transmit malware through a stripe reader--not enough data, plus it doesn't get treated as code. Same for contactless payments in their present incarnation. Chip transactions I'm no too sure about; may depend on the capacity of the card itself.
A bit pointless trying to "clone" a chip transaction because the information is dynamic and one time. Much more of a problem for magstripe cards or where the terminal is used for card no present transasctions.
With suitably hacked cards might there be a buffer overflow somewhere?
I doubt there is enough data in the mag stripes to be able to take advantage of a buffer overflow even if there was one. Also, there seem to be quite a few different mag stripe readers in use so a buffer overflow in one model probably wouldn't be exploitable on any others, limiting your effectiveness.
On a related note, I've not seen where any of the standard anti-virus software are able to detect it, has anyone else seen anything about detection methods?
Fuck these internet crims.
Blindfold them, have them kneel down, and fire off a 10ga shotgun to the back of the head. Be sure to use 4/0 buck, too.
Not 4690 then?
I know these are dynamic, but the ad that showed up on the page while I was looking through these posts was for "LightSpeed - POS on iPad." It's good to know that once the current spate of attacks is shut down, there will be new and fertile ground for the thieves to move on to.
But when I used to write EPOS systems (and helped debug one of the first Verifone Chip & PIN interfaces) the Chip&PIN verification was reasonably secure. Unfortunately all the encrypted data was also secured in unencrypted ASCII including TRACK2 (Card Number, expiry date etc) which was sent via a 1200/75 MODEM link to the bank at the end of each day. When things went wrong the support team used to copy files with 64,000 or so Valid credit card numbers around on floppy. Back then all you had to do was bribe a few minimum wage support desk guys to net you a nice pile of valid numbers.
"...running Windows Server, which makes it unlikely that the malware was installed using typical social-engineering or drive-by web download methods."
I have a bud who does POS work for a franchise of a well known fast food chain. Each of their stores has a Windows server for the 4 to 8 PCs being used for the POS system in the rest of the store. While some of the maintenance is done remotely, because of their hours and "criticality" from time to time they have to have to call the local shop and have either the owner or on duty manager login to the system and be eyes and hands. You know the type - they'd call to get the cup holder fixed. do you REALLY think just because it's a SERVER it's IMMUNE to social engineering and drive-byes?
This. And in addition, just because it is a server doesn't keep the manager/owner from logging on and sufing the web to get their pr0n fix. You wouldn't believe how many thoroughly compromised servers I've seen in retail POS systems.
You misunderstand (the article is unclear). Here's the relevant quote from the Seculert blog post:
Seculert was able to identify that over 30 percent of the targeted POS systems were using Windows Servers (See Figure 4). This is an unusual number for regular "web-based social engineering" or "drive-by download" infection methods.
Their point is that the large fraction of systems that were running Windows suggest a Windows-specific attack vector was among those used to install the software, whereas social-engineering or WiFi attacks would have a weaker correlation to OS type. I'm not sure I buy that argument (for example, social engineering attacks are often specific to OSes, if they involve convincing someone to perform OS-specific steps), but they're not claiming that Windows systems are less vulnerable to social engineering or drive-by WiFi penetration.
Windows XP, Windows Home Server, Windows Server 2003, Windows 7, Windows 2000, Windows Server R2, Windows Vista, Windows Server 2008, Windows Server 2008 ...
Allow me to re-format that for you:
Windows Home Server,
Windows Server 2003,
Windows Server R2,
Windows Server 2008,
Windows Server 2008
Notice the common link?
fscked by SHA-1 collision? Not so fast, says Linus Torvalds