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."
Why hack 'em... (Score:5, Funny)
Re:Why hack 'em... (Score:5, Funny)
http://www.peopleofwalmart.com/ [peopleofwalmart.com]
Comment removed (Score:4, Funny)
Comment removed (Score:5, Funny)
Re:must have been a windows server.... (Score:5, Informative)
:(){
Yeah, I know any competent admin can protect against it, but still.
Re:must have been a windows server.... (Score:5, Informative)
Linux would not have crashed from a mere userspace program ;)
I have a forkbomb that disagrees with you.
Re: (Score:2, Insightful)
Re: (Score:2, Interesting)
That, and grsec patchset. I tested it on a Athlon XP and it kills a forkbomb after 32000 forks.
Re: (Score:2, Insightful)
That doesn't mean it isn't impossible. Claiming that it is is misinformation.
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.
Re: (Score:1)
Re: (Score:1, Redundant)
Re: (Score:1)
Re: (Score:2)
The evidence is in the billions of dollars that corporate America has spent on prevention and recovery from exploits. For more evidence, tally up the cost that homeowners have paid for prevention and recovery - and don't forget to attach some value to all the time spent re-installing Windows. Again, we are looking at billions of dollars. Every time a Windows based online bank is exploited, you can add to the overall figure.
Only a fool would try to convince you that Linux can't be exploited - but, what ha
Re: (Score:2, Insightful)
Only a fool would try to convince you that Linux can't be exploited - but, what has been the total cost of Linux exploits in the past 10 years? A mere drop in the bucket, compared to Windows exploited systems.
Again, there isn't any evidence. Why would this be? I use the same basic rules for every os I manage, and guess what? I never have to reinstall. Never.
Re: (Score:1)
I don't get it (Score:2)
Surely they could have dumped the user accounts from AD (like the SAM under NT) and crack all the accounts on a remote machine. Then maybe it wouldn't have even been noticed. And if the POS software was secure, it should not matter if someone downloaded the source code.
Secure software isn't so easy (Score:5, Informative)
And if the POS software was secure, it should not matter if someone downloaded the source code.
That depends on whether the source code was stored separately to certificates/key files and how well the passwords were externalised. You'd be surprised how modern security systems allow and even encourage awful practices in this regard. For example Spring web services and spring security have a bad tendancy of including such things in their config file, which are often bundled up in the application.
It's actually not a trivial problem. If you include everything required for the app to run in the application package/bundle, you inevitably include such things somewhere they shouldn't be (even if that's just a build machine). The best solution I've seen is hardware security modules that don't allow keys and certificates to be exported. They aren't cheap but if you're running a large organisation and have been trusted with potentially millions of credit card numbers it's not exactly beyond the call.
Wal-Mart did not follow basic security practices (Score:4, Informative)
Forget the POS software and whether it was secure or not.. looks like Wal-Mart did not follow some basic security practices
According to this blog [blogspot.com]:
Re:Wal-Mart did not follow basic security practice (Score:2)
... looks like Wal-Mart did not follow some basic security practices...
Oh, that's so funny it hurts. I think my ears are bleeding.
This wouldn't be a case of "you get what you pay for" now would it?
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: (Score:2)
Even Better: Don't store CC numbers once you have the payment authorization and transaction ID. It's that damn simple. Once Visa/Master Card/Dinner Club/AmEx authorizes the transaction, the only thing you need is the transaction Authorization ID along with the amount and it's what I don't understand about the entire Credit Card PCI process. Push for this and you'd eliminate many of the reasons to hack Merchant systems for card numbers and I suspect Visa/MasterCard/AmEx would save lots of money on bad charge
Re: (Score:2)
Re: (Score:2)
What about a system like the one at my workplace that doesn't charge the card right there, but rather does it in a batch at the end of the day? It's useful because I can easily invalidate a transaction a few minutes later if I key in an error, without swiping the card again, instead of having to issue a chargeback. Also, what about machines that are operated offline (eg. a travelling booth). They're pretty common.
Re: (Score:2)
Re: (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 certif
Re: (Score:2)
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.
You're assuming the certificate is used immediately to establish a connection. Point of sale terminals are not always on-line, and when they are off-line they must encrypt the authorization request and store it until it can be sent to the settlement system once they're back on-line. In that case, the terminal really needs to assure itself that the certificate is valid, because it might not be able to attempt the decryption until long after the customer has left with your merchandise and their charge card.
You've proven you have no idea (Score:2)
You're assuming the certificate is used immediately to establish a connection.
No, I'm not. Where did I say that?
Point of sale terminals are not always on-line, and when they are off-line they must encrypt the authorization request and store it until it can be sent to the settlement system once they're back on-line.
Encryption and authentication (signing) are two different things. You almost certainly want both but you can encrypt without authenticating and vice versa.
In that case, the terminal really needs
Re: (Score:2)
I don't think we're speaking on the topic in exactly the same way here.
I'm trying to solve the problem of "how do I know if this certificate (and signing CA root cert) on this cash register are good? How do I know they are not forgeries?" If I'm on-line, I can use the cert to authenticate a connection to a host, and assuming* I'm not also the victim of a simultaneous man-in-the-middle attack, I can trust that the cert is valid.
*Big assumption here.
But if I'm off-line, I simply have to trust the certs in m
Re: (Score:2)
But if I'm off-line, I simply have to trust the certs in my possession.
You are way too focused on the cers. If you're off line and your certs have been compromised, so could your code. In which case game over. Any test can be bypassed. If you don't trust your register is secure, require it to be online.
Yes a HSM is the best test you can have. It provides non-repudiation provided you're willing to do forensics to prove the POS terminal hasn't been compromised. So it's a very partial solution. As soon as you
Re: (Score:2)
For the most part I'm not worried about attackers because I can't worry about them. As you say, the attacker could bypass any test. Even on-line isn't a guarantee of assurance, as the attacker could be providing me with a false host that matches my false certs. There is no way to determine (or even prevent) compromise on a box I don't physically control. And cash registers aren't of any business value if they're locked up in a secure data center.
The reason I focus on the certs is mostly because I need t
Re: (Score:2)
I certainly meant no offense with that first posting. It was not intended as an attack. I'm sorry it came across that way.
I think for the most part we agree and I'm also sorry if I defended my position too vigorously and made it more personal than it needed to be.
Why? (Score:1)
...no customer data was lost in the hack.
Surely they didn't simply notice it quickly enough that the hacker didn't have time to grab anything... So why go through all the trouble if he's not going to take anything?
Was it just for lols?
Re: (Score:2, Informative)
[l0phtCrack] crashed the server when the intruder tried to launch the program.
Nevermind
Re: (Score:3, Informative)
The technical term isn't lols, it's lulz.
Now someone mod me informative. :)
Re: (Score:3, Funny)
Re:Why? (Score:4, Informative)
$200,000 Cash Theft (Score:1, Offtopic)
I can't help but wonder if it was related to this:
http://www.orlandosentinel.com/news/local/breakingnews/orl-bk-walmart-safe-heist-100909,0,3026268.story [orlandosentinel.com]
Re: (Score:2)
The server hack took place in 2006.
The $200K cash theft took place in 2009.
You figure it out.
Walhack? (Score:3, Funny)
Re: (Score:2)
This is heresy! This is madness!
This what they for have the lowest cost IT workers (Score:2)
This what they for have the lowest cost IT workers and outsourcing IT work.
Re: (Score:2)
This what they for have the lowest cost IT workers
I that you a verb or two.
Re: (Score:2)
I hope English isn't your first language.
This what they for have....
I assume you mean "This is what they get for having...."
In which case, you're absolutely right.
Albert Gonzales? (Score:2)
Walm-mart secure like Microsoft, CPOs share awards (Score:2)
Albert Gonzalez (Score:4, Funny)
Albert Gonzalez, not to be confused with the former US Attorney General, Alberto Gonzalez.
All the more reason... (Score:2)
to use green backs. Also cultivate the habit of not spending the money you don't have...
SCO Unix success story? (Score:2, Insightful)
Is this information about POS backends still valid?
FTA:
"Wal-Mart has thousands of servers nationwide, and any one of them crashing would ordinarily be a routine event."
"Someone had installed L0phtcrack, a password-cracking tool, onto the system, which //crashed the server// when the intruder tried to launch the program." [emph. added]
From http://www.sco.com/company/success/story.html?ID=21 [sco.com] :
"Nearly all of the 350 chains using PDI/RMS are deployed on SCO UNIX® technology [...]"
"McLane Co., Wal-Mart's wh
Re: (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.
Oblig. (Score:2)
Damnit!
Oh well, I tried. I guess I have to pay for stuff now.
compromised VPN account? (Score:2)
What does "compromised VPN account" mean? did the hackers find the password of the user? the article does not explain that.
Active accounts after being let go... (Score:2)
One of the first things that stood out, they said was, that a Canadian employee that was let go that still had an active account.
Then another, then another, seems the Canadian admins are not doing their jobs properly, hopefully this was rectified, and scripts were created for easy deletion / or suspension of accounts of employees let go.
user data (Score:2)
That's exactly what the data thieves wanted them to confirm.
No need to warn because no customer data lost? (Score:1)