Did you swipe your card through one of these UPS Store tills? You may have been pwned UPS has discovered an outbreak of debit and credit-card-reading malware in 51 of its branches in the US. Exactly which strain of malware was involved is not known; a spokesperson told The Register today: "We're still investigating the infection." It's hoped the identity of the malware will be revealed once that probe is …
Any idea what the OS and server platform that was infected with the Malware was? This kind of data is crucial for readers to understand the most prolific and lowest cost solution may expose them to criminal and civil liabilities. If they take on the responsibility of handling customer data they need to go with a reliable and *secure* platform from the start.
The local franchise appears to use Windows on the POS machines. I'm not sure about the servers as I've never asked. Seems that if you ask out of curiosity. someone gets curious right back about your motives. Best not to ask the store folks in my experience.
"Any idea what the OS and server platform that was infected with the Malware was?"
No. I did ask the UPS PR team on the phone as desk editor. They wouldn't tell me the malware type. When I asked: "This is Windows malware, right?" There was a pause and the reply: "I couldn't possibly comment."
As soon as I find out, I will push out an update. UPS right now is in alert-affected-customers mode. Once they've got through the financially tricky stage of supporting pwned citizens, they'll release the techy details – or so they tell me.
C.
I've worked with (not for) a lot of retailers & F&B outlets, and talking to their POS vendors. The 5 POS vendors I've dealt with, which account for most of the worldwide market (4 out of 5 were global vendors) use Windows, with the only differences being the flavour of database (MSSQL, OpenSQL, MySQL, whatever).
This goes for the POS systems in the front-end as well as the back-end.
I even came across one restaurant where all 5 payment positions were using the public wifi, and could be accessed by just going to //[insert terminal position]/ and using default passwords, and found entire partitions as shared.
Anonymous, obviously
FTA "...to date it hasn't identified any evidence of fraudulent activity as a result of the breach."
If someone did get a fraudulent transaction how would they prove it was due to this breach at UPS and not due to the usual stuff the banks claim as the cause (1. You were reckless with your details online, 2. You wrote down your PIN, 3. It's all your fault as you're the little guy and our systems are 100% secure LaLaLaLa).
That's even assuming it affected someone who checks their CC statement at the end of the month, AND does something about a transaction they don't recognise.
Even if they did prove it was UPS would UPS even admit it?
However advanced the security model used by a retailer's point of sale terminals, whether it be biometrics, EMV cards, one time passwords or any other kind, the single point of failure is the fact that useful data is left behind on the retailer's system.
This makes it an attractive target for hackers, who bypass the authentication system, by hacking the network, or the operating system, steal the database, and re-use the card details, user information and whatever else was there for the taking.
To perform identity authentication, only two pieces of information are needed. A form of user ID, and an associated secret, known only to the user and the authentication system.
In most cases, the user ID is implied by a credit card number, and the secret is passed from the user, to the retailer, and then to the credit card company, possibly in encrypted form. All of this information is recorded, together with the transaction details, in the log files on systems belonging to the retailer and the credit card company.
This is the flaw. The systems contain data worth stealing. It doesn't matter that it is encrypted, since the thieves have plenty of time, and adequate computing resources.
Let us postulate a point of sale terminal which doesn't need to read a credit card number, but is content to take a simple user ID.
Let us further postulate that the terminal doesn't pass a secret to the credit card company, but merely sends metadata, i.e information related to the secret. Now, we don't even need encryption.
Finally, let us postulate that the metadata is different with each transaction performed by the customer, but relates to the same secret.
Both the customer and the credit card company know the secret, so deciphering the metadata is a simple matter. The retailer doesn't need to know the secret, and just retransmits the metadata from customer to credit card company. If the whole transaction is stored on the retailer's system, and is then stolen, it is useless to the thief, since he can't decipher the metadata.
The creation of the metadata is the crucial part of this security model, and the following is one approach.
Both the customer and the credit card company agree on a word or phrase, or even an arbitrary collection of letters, as the secret.
When the customer wishes to authenticate, the POS terminal presents him with an alphabet, paired with a random array of numbers, like this:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
10011000100001011110001111
The customer then enters the numbers corresponding to his secret, which are sent to the credit card company. It doesn't matter if the retailer stores this together with the transaction details since, the next time the customer performs a transaction, the numbers will all be different, and the previous numbers will be useless to the thief.
The numbers will also be useless to any spy cameras, skimming devices, network snoopers and key logging malware.
To add a further level of security, it isn't even necessary to transmit the numbers. A SHA256 hash is irreversible, but the credit card company can reconstruct the hash of the secret, and match this with the incoming hash from the retailer. Metadata of metadata.
Point of sale terminals can be made secure. Very secure. It's just a matter of wanting to.
To add a further level of security, it isn't even necessary to transmit the numbers. A SHA256 hash is irreversible, but the credit card company can reconstruct the hash of the secret, and match this with the incoming hash from the retailer. Metadata of metadata.
If you're going to do that, it would make more sense to use a proven Zero-Knowledge Proof system, such as SRP or PAK-RY. ZKP gives you additional protection against things like replay attacks.
I once mooted a system based on a similar hash-with-shared-secret (basically an HMAC) for authentication, to avoid an extra round trip while still being able to employ salt and nonces, by using a one-way accumulator to provide an outer "hash" that's associative and commutative. But I didn't take it any further than the initial design because the 1WA doesn't really provide any benefits that aren't in a ZKP system, and the latter are better-studied, standardized, and available in existing implementations.
One of the worst things to do in applied cryptography is reinvent the wheel.
All that said, I agree with your general point that existing POS systems expose far more information than is necessary, in all sorts of ways, and much better protocols could be employed. As usual, we're treating this sort of thing symptomatically instead of systemically.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
