Slashdot Mirror


Details Emerge of 2006 Wal-Mart Hack

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."

66 comments

  1. Why hack 'em... by SomeJoel · · Score: 5, Funny

    when you can just pay for everything with a million dollar bill?

    --
    <Complete your profile by adding a signature!>
    1. Re:Why hack 'em... by Anonymous Coward · · Score: 5, Funny
    2. Re:Why hack 'em... by Shakrai · · Score: 3, Funny

      I want to personally thank you for ruining my dinner......

      --
      I want peace on earth and goodwill toward man.
      We are the United States Government! We don't do that sort of thing.
    3. Re:Why hack 'em... by Anonymous Coward · · Score: 0

      That might save you from looking like some of them ;)

  2. must have been a windows server.... by Shakrai · · Score: 4, Funny

    Someone had installed L0phtcrack, a password-cracking tool, onto the system, which crashed the server when the intruder tried to launch the program.

    Linux would not have crashed from a mere userspace program ;) Windows saved the day! Hooray!

    --
    I want peace on earth and goodwill toward man.
    We are the United States Government! We don't do that sort of thing.
    1. Re:must have been a windows server.... by Hyppy · · Score: 4, Informative

      One word: Forkbomb.
      :(){ :|:& };:
      Yeah, I know any competent admin can protect against it, but still.

    2. Re:must have been a windows server.... by blhack · · Score: 4, Informative

      Linux would not have crashed from a mere userspace program ;)

      I have a forkbomb that disagrees with you.

      --
      NewslilySocial News. No lolcats allowed.
    3. Re:must have been a windows server.... by cigawoot · · Score: 2, Insightful

      Any idiot who knows about the /etc/security/limits.conf file can fix that

    4. Re:must have been a windows server.... by andreyvul · · Score: 2, Interesting

      That, and grsec patchset. I tested it on a Athlon XP and it kills a forkbomb after 32000 forks.

      --
      proud caffeine whore
    5. Re:must have been a windows server.... by blhack · · Score: 1, Insightful

      That doesn't mean it isn't impossible. Claiming that it is is misinformation.

      --
      NewslilySocial News. No lolcats allowed.
    6. Re:must have been a windows server.... by AmberBlackCat · · Score: 0, Redundant

      That means with Linux the poor hackers would have been stuck with using the compromised VPN account to take over the entire system, with no crash or any other evidence...

    7. Re:must have been a windows server.... by Anonymous Coward · · Score: 0

      Since when do employers hire competent people as opposed to cheap almost capable ones?

    8. Re:must have been a windows server.... by melmut · · Score: 1

      I don't think this is true. And I don't think linux is safer. Just give some evidence, please. Or don't say talk about what you don't know. Please.

    9. Re:must have been a windows server.... by drinkypoo · · Score: 3, 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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    10. Re:must have been a windows server.... by cigawoot · · Score: 1

      Because at our Cyber Defense Competitions that we run, I cannot have any fun being an end user by blowing up their sservers in 10 seconds.

    11. Re:must have been a windows server.... by Runaway1956 · · Score: 1

      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 has been the total cost of Linux exploits in the past 10 years? A mere drop in the bucket, compared to Windows exploited systems.

      --
      "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
    12. Re:must have been a windows server.... by melmut · · 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.

    13. Re:must have been a windows server.... by w0lo · · Score: 1

      To dump the SAM hashes from a live system, you need debug priv (admin) and inject a dll or some code into a key windows process, if anything goes wrong and the process dies, windows BSoD's to protect itself

  3. I don't get it by rodgster · · Score: 1

    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.

    --
    Who will guard the guards?
  4. Why? by Tubal-Cain · · 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?

    1. Re:Why? by Tubal-Cain · · Score: 2, Informative

      [l0phtCrack] crashed the server when the intruder tried to launch the program.

      Nevermind

    2. Re:Why? by FooAtWFU · · Score: 3, Informative

      The technical term isn't lols, it's lulz.

      Now someone mod me informative. :)

      --
      The World Wide Web is dying. Soon, we shall have only the Internet.
    3. Re:Why? by cigawoot · · Score: 3, Funny

      Done!

    4. Re:Why? by Korin43 · · Score: 3, Informative

      Plus, you don't just do something for lulz, you do it "for the lulz". You'd think Slashdot users would be more literate..

    5. Re:Why? by Anonymous Coward · · Score: 0

      and undone by posting...

    6. Re:Why? by Anonymous Coward · · Score: 0

      It's "for teh lulz".

      LURK MOAR

  5. $200,000 Cash Theft by absurdist · · Score: 0, Offtopic
    1. Re:$200,000 Cash Theft by cbiltcliffe · · Score: 1

      The server hack took place in 2006.

      The $200K cash theft took place in 2009.

      You figure it out.

      --
      "City hall" in German is "Rathaus" Kinda explains a few things......
  6. Secure software isn't so easy by syousef · · Score: 4, 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.

    --
    These posts express my own personal views, not those of my employer
    1. Re:Secure software isn't so easy by plover · · Score: 4, 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.

      --
      John
    2. Re:Secure software isn't so easy by fast+turtle · · Score: 1

      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 charges.

      --
      Mod me up/Mod me down: I wont frown as I've no crown
    3. Re:Secure software isn't so easy by syousef · · Score: 2, 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.

      --
      These posts express my own personal views, not those of my employer
    4. Re:Secure software isn't so easy by plover · · Score: 1

      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.

      --
      John
    5. Re:Secure software isn't so easy by Bill,+Shooter+of+Bul · · Score: 1

      Yeah, that's not always true, depending on the processor. But, yes merchants should find a processor that limits the merchant's need to store that info.

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
    6. Re:Secure software isn't so easy by bendodge · · Score: 1

      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.

      --
      The government can't save you.
    7. Re:Secure software isn't so easy by Chaos+Incarnate · · Score: 1

      Then it would store it until the batch is processed—which would be the point at which you have the payment authorization and transaction ID.

      --
      Benford's Corollary to Clarke's Law: "Any technology distinguishable from magic is insufficiently advanced."
  7. Walhack? by fenix849 · · Score: 3, Funny

    Did anyone else jump to the same conclusion or have i been gaming too much? Now i might RTFA. :o

    1. Re:Walhack? by Eil · · Score: 1

      Now i might RTFA. :o

      This is heresy! This is madness!

    2. Re:Walhack? by otterpopjunkie · · Score: 0

      banned.

  8. I guess they might have been funding Al-Qaeda... by Anonymous Coward · · Score: 0

    It seems kind of silly for the US Attorney General to hack into Marshall's.

    Isn't that what the NSA does for him?

  9. Wal-Mart did not follow basic security practices by Anonymous Coward · · 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:

    housed complete backup copies of transaction logs on network-connected UNIX servers, which included at least four years’ worth of unencrypted credit card numbers, cardholder names and expiration dates

    used the same usernames and passwords across every Wal-Mart store nationwide

    And ofcourse, the intrusion could be traced back to the VPN account of a system administrator who had left the company but his account was not shut down (the report does not implicate the employee)

  10. This what they for have the lowest cost IT workers by Joe+The+Dragon · · Score: 1

    This what they for have the lowest cost IT workers and outsourcing IT work.

  11. Albert Gonzales? by bsDaemon · · Score: 1

    But, why would the Attorney General have wanted to hack WalMart? What can this mean? Conspiracy theories abound...

  12. Walm-mart secure like Microsoft, CPOs share awards by GoodNicksAreTaken · · Score: 1

    Wal-mart's Chief Privacy Officer http://www.microsoft.com/presspass/features/2004/oct04/10-28privacy.mspx">took home a privacy innovation award for non-profits while Microsoft took home the corporate award when she worked for USPS.

  13. Albert Gonzalez by Jeian · · Score: 3, Funny

    Albert Gonzalez, not to be confused with the former US Attorney General, Alberto Gonzalez.

  14. All the more reason... by Lead+Butthead · · Score: 1

    to use green backs. Also cultivate the habit of not spending the money you don't have...

    --
    ELOI, ELOI, LAMA SABACHTHANI!?
  15. You've proven you have no idea by syousef · · Score: 1

    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 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.

    First as you've probably conceded unless you replace the certificates at both ends, you won't authenticate or encrypt/decrypt the message or both so that it's recognised at the other end. So the funds don't get transfered.

    As for merchandise leaving the store, once your POS is compromised, it's compromised. You can replace the entire set of certificates. You can even make the terminal pretend it has gone out and connected with the bank and transfered the money. There is NOTHING you can do to ensure that the certificates you have cached and the software you have aren't compromised to allow the sale to go through, since anything you are relying on to authenticate can itself be compromised.

    I'm pretty certain you don't know what you're talking about, and that's dangerous if you're advising others on security.

    --
    These posts express my own personal views, not those of my employer
    1. Re:You've proven you have no idea by plover · · Score: 1

      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 my possession.

      If I'm on-line and a customer gives me their credit card, I will use the cert, establish an authenticated connection to the authorizer, send the encrypted credit info, receive an approval, and send the customer off with his merchandise.

      If I'm off-line, I'm taking my chances because I have to proceed without credit approval. Perhaps if it's just a one dollar bottle of soda, I'll accept the risk and approve it. But I still need to assure myself that I'll get paid by the customer's bank, and I also need to protect the customer's data. So I check the certificate I have on the local machine, walk its chain up to the root CA (which I also have on the local machine), and use the cert's key to encrypt the customer's credit info. I then have to store the encrypted data until such time that I'm back on-line and can send it forward. I may be too late to get the credit approved, but I still need to send the credit data to the customer's bank in order to get paid.

      At this point it's still all about trust. I have to trust that the certs and key in my possession are not forgeries. If they are, I will have no way of recovering the credit info and getting paid. And if the attacker who replaced my valid certificates with forgeries is somewhere in the system harvesting the data, he alone will have the ability to decrypt the credit info, and use it for his evil purposes. As you said, there is nothing else that can be done at this point. An attacker who owns the system owns the whole system.

      As I think we both agreed above, an HSM is about the most reliable way to protect a secret in this case. The best solution would be to perform all encryption in the HSM. That helps defend against the man-in-the-middle attack, again assuming the attacker can't tamper with or replace the HSM. But an HSM can be an expensive option when you're talking about many thousands of cash registers. A TPM chip can securely store enough data to verify a cert, though, and could be used to spot forgeries. (Again, assuming the attacker hasn't replaced the HSM or TPM drivers. An attacker with that level of access is certainly capable of any level of mischief. It always comes down to trusting the systems at some level or another.)

      I'm pretty certain you don't know what you're talking about, and that's dangerous if you're advising others on security.

      Don't be so quick to take offense if you don't understand the way someone else is going with a conversation. Take a moment to figure out what they mean before you descend into slander. You've been pretty hostile in this little conversation, and I've tried to be civil. Reciprocation would be appropriate.

      --
      John
    2. Re:You've proven you have no idea by syousef · · Score: 1

      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 go on line, you can authenticate the certificate definitively, but if you're saying by then it's too late, you shouldn't be accepting the transaction. So as you said for soda, perhaps. For a Rolls Royce, certainly not.

      Don't be so quick to take offense if you don't understand the way someone else is going with a conversation.

      Take a look into my initial message and your response. You made the first attack on what I'd said.

      --
      These posts express my own personal views, not those of my employer
    3. Re:You've proven you have no idea by plover · · Score: 1

      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 them to work in the normal, non-attack scenario. I need a high level of confidence that the data I generate now will be readable later.

      I certainly meant no offense with that first posting. It was not intended as an attack. I'm sorry it came across that way.

      --
      John
    4. Re:You've proven you have no idea by syousef · · Score: 1

      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.

      --
      These posts express my own personal views, not those of my employer
  16. Re:Wal-Mart did not follow basic security practice by Anonymous Coward · · Score: 0

    housed complete backup copies of transaction logs on network-connected UNIX servers, which included at least four years’ worth of unencrypted credit card numbers, cardholder names and expiration dates

    The POS controllers only store the current day and the day prior. Complete transaction logs (electronic reciept transcriptions, basically) were kept containing full account numbers up until a few years ago, but have now been purged of all but the last 4 digits of any sort of financial data (credit/debit, gift card, check routing numbers).

    Any paper copies of this data should also have cycled to the shredder by now, too.

  17. SCO Unix success story? by yourruinreverse · · 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 :
    "Nearly all of the 350 chains using PDI/RMS are deployed on SCO UNIX® technology [...]"

    "McLane Co., Wal-Mart's wholesale subsidiary, acquired PDI in 1991. Fischer says one goal of the acquisition was to achieve tighter integration with some of the 30,000 c-stores that McLane serves. However, PDI continues to operate as a stand-alone entity and many of its customers are served by other wholesalers."

    --
    JeR
    1. Re:SCO Unix success story? by thejynxed · · 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.

      --
      @Mindless Drivel: 100% of Twitter posts ever Tweeted.
  18. Re:Wal-Mart did not follow basic security practice by Nefarious+Wheel · · Score: 1

    ... 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?

    --
    Do not mock my vision of impractical footwear
  19. Oblig. by corychristison · · Score: 1

    mainpc cory # emerge walmart-hack
    Calculating dependencies... done!
     
    emerge: there are no ebuilds to satisfy "walmart-hack".
     
    mainpc cory # _

    Damnit!

    Oh well, I tried. I guess I have to pay for stuff now.

  20. compromised VPN account? by master_p · · Score: 1

    What does "compromised VPN account" mean? did the hackers find the password of the user? the article does not explain that.

  21. Active accounts after being let go... by hesaigo999ca · · Score: 1

    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.

  22. Re:This what they for have the lowest cost IT work by Dragonslicer · · Score: 1

    This what they for have the lowest cost IT workers

    I that you a verb or two.

  23. Re:Wal-Mart did not follow basic security practice by Anonymous Coward · · Score: 0

    Posting AC because Wal-Mart is one of our customers... they may have a fuckton of money, but they are VERY stingy with it. They demand all kinds of documentation on support hours over and above what most other places do, and try to play major hardball with us to try to get the price down, which doesn't happen with ANY of our other clients because they realize we provide a unique service that they just can't get anywhere else. The cheapness at Wal-Mart is endemic. And cheapness is a very different beast from thrift.

  24. user data by j00r0m4nc3r · · Score: 1

    confirmed that no customer data was lost in the hack

    That's exactly what the data thieves wanted them to confirm.

  25. Re:This what they for have the lowest cost IT work by cbiltcliffe · · Score: 1

    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.

    --
    "City hall" in German is "Rathaus" Kinda explains a few things......
  26. No need to warn because no customer data lost? by TheMaTrIxBEL · · Score: 1

    Ehm, WTF, I don't think customers wouldn't be all to miffed about all that data these chains collect on them being lost. I wouldn't care, I would actually love the option to have them NOT KEEP DATA ON ME. What customers would love to hear and need to be made aware about is if the hackers copied all that data, who gives a freck if it was lost.