Details Emerge of 2006 Wal-Mart Hack 66
plover writes "Kim Zetter of Wired documents an extensive hack of Wal-Mart that took place in 2005-2006. She goes into great detail about the investigation and what the investigators found, including that the hackers made copies of their point-of-sale source code, and that they ran l0phtCrack on a Wal-Mart server. 'Wal-Mart uncovered the breach in November 2006, after a fortuitous server crash led administrators to a password-cracking tool that had been surreptitiously installed on one of its servers. Wal-Mart's initial probe traced the intrusion to a compromised VPN account, and from there to a computer in Minsk, Belarus.' Wal-mart has long since fixed the flaws that allowed the compromise, and confirmed that no customer data was lost in the hack — which is why they did not need to report the breach publicly earlier." This intrusion happened around the same time that Albert Gonzalez's gang was breaking into Marshall's and its parent company, TJX. The MO was quite similar: researching and closely targeting the point-of-sale systems in use. But the article notes that "There's no evidence Wired.com has seen linking Gonzalez to the Wal-Mart breach."
Re:Secure software isn't so easy (Score:5, Interesting)
There's never a reason to have the private keys stored in the Point-Of-Sale application. The credit card data should be encrypted in the POS system using a public key borne on a verified certificate. It doesn't ever have to be decrypted at POS for any reason. Decryption should happen only at the point of authorization, and at the point of settlement with the bank. Those private keys are only in centrally located machines that can be much more easily secured than the thousands of cash registers located in thousands of stores.
The hardest part is ensuring the certificate signatures are valid. You have to ensure the encryption certs weren't replaced with evil certs, and that no rogue root certificate was installed on the POS system.
Now, if you are encrypting at a PIN Entry Device (PED), it's a bit different. PINs are most commonly encrypted using TDES, not public key cryptography. Because those devices actually store secret keys, they fall under the PCI PED guidelines. They store a master key used in a protocol called DUKPT (Derived Unique Key Per Transaction.) The device must pass various tests and analysis, and be physically hardened against an attacker attempting to retrieve the master key. The older ones I've examined used a combination of trip wires, sensor switches, epoxy, 10-layer PC boards, and soldering techniques (BGA packaging) to thwart the bad guys. I'm not saying they're impregnable, but they're physically pretty well secured.
Re:must have been a windows server.... (Score:2, Interesting)
That, and grsec patchset. I tested it on a Athlon XP and it kills a forkbomb after 32000 forks.
Re:Secure software isn't so easy (Score:3, Interesting)
There's never a reason to have the private keys stored in the Point-Of-Sale application.
Way to mis-read what I said. I gave an example that wasn't strictly related to POS terminals of how frameworks encourage poor security practices. Whether it's a certificate, key or password having it embedded in the configuration or the application package is poor security design but also the standard way things work.
The credit card data should be encrypted in the POS system using a public key borne on a verified certificate. It doesn't ever have to be decrypted at POS for any reason. Decryption should happen only at the point of authorization, and at the point of settlement with the bank. Those private keys are only in centrally located machines that can be much more easily secured than the thousands of cash registers located in thousands of stores.
And you shouldn't have to write custom code to get this kind of behaviour, yet you often do.
The hardest part is ensuring the certificate signatures are valid. You have to ensure the encryption certs weren't replaced with evil certs, and that no rogue root certificate was installed on the POS system.
Huh? That's the whole point of a certificate. If it's replaced with an "evil" certificate it won't authenticate at the other end. You'd have to replace them at both ends. Very difficult to do if you're talking about a Hardware Security Module (HSM) that doesn't allow certificate export. You basically have to steal the hardware.
Re:SCO Unix success story? (Score:2, Interesting)
Dunno, but I know Walmart switched over to RHEL a few years ago for servers and using Fedora/CentOS for workstations.
Even their computerized applicant system is running a modified version of Fedora in many locations. It crashes quite a bit though, so that's how I found out - they run a Windows-based VB6 program via WINE.
I think in some of the newer stores, they've just swapped over to running a Win2k VM inside of VirtualBox or something on Linux and running the app that way.
Re:must have been a windows server.... (Score:4, Interesting)
Why don't linux distributions come with this file already configured? you know, with some reasonable limits to prevent fork bombs and the like. I understand why you wouldn't have minimums in there. Seems like a big missed opportunity.