Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Security IT

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."
This discussion has been archived. No new comments can be posted.

Details Emerge of 2006 Wal-Mart Hack

Comments Filter:
  • by SomeJoel ( 1061138 ) on Tuesday October 13, 2009 @06:37PM (#29739081)
    when you can just pay for everything with a million dollar bill [usatoday.com]?
  • by Shakrai ( 717556 ) on Tuesday October 13, 2009 @06:37PM (#29739083) Journal

    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!

  • by rodgster ( 671476 ) <rodgster@y[ ]o.com ['aho' in gap]> on Tuesday October 13, 2009 @06:41PM (#29739107) Journal

    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.

    • by syousef ( 465911 ) on Tuesday October 13, 2009 @06:49PM (#29739175) Journal

      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.

      • by Anonymous Coward on Tuesday October 13, 2009 @07:16PM (#29739377)

        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]:

        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)

        • by Anonymous Coward on Tuesday October 13, 2009 @09:16PM (#29740265)

          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.

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

          • by Anonymous Coward on Wednesday October 14, 2009 @10:51AM (#29745697)
            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.
      • by plover ( 150551 ) * on Tuesday October 13, 2009 @07:29PM (#29739477) Homepage Journal

        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.

        • by fast turtle ( 1118037 ) on Tuesday October 13, 2009 @08:09PM (#29739795) Journal

          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.

        • by syousef ( 465911 ) on Tuesday October 13, 2009 @08:13PM (#29739843) Journal

          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.

          • by plover ( 150551 ) * on Tuesday October 13, 2009 @08:35PM (#29739997) Homepage Journal

            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.

            • by syousef ( 465911 ) on Tuesday October 13, 2009 @08:46PM (#29740059) Journal

              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.

              • by plover ( 150551 ) * on Tuesday October 13, 2009 @11:01PM (#29740961) Homepage Journal

                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.

                • by syousef ( 465911 ) on Wednesday October 14, 2009 @12:38AM (#29741397) Journal

                  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.

                  • by plover ( 150551 ) * on Wednesday October 14, 2009 @07:04AM (#29743019) Homepage Journal

                    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.

  • by Tubal-Cain ( 1289912 ) on Tuesday October 13, 2009 @06:41PM (#29739109) Journal

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

  • by absurdist ( 758409 ) on Tuesday October 13, 2009 @06:48PM (#29739163)

    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]

  • Walhack? (Score:3, Funny)

    by fenix849 ( 1009013 ) on Tuesday October 13, 2009 @06:57PM (#29739251)
    Did anyone else jump to the same conclusion or have i been gaming too much? Now i might RTFA. :o
  • by Anonymous Coward on Tuesday October 13, 2009 @07:01PM (#29739277)

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

    Isn't that what the NSA does for him?

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

  • by bsDaemon ( 87307 ) on Tuesday October 13, 2009 @07:37PM (#29739531)
    But, why would the Attorney General have wanted to hack WalMart? What can this mean? Conspiracy theories abound...
  • Wal-mart's Chief Privacy Officer http://www.microsoft.com/presspass/features/2004/oct04/10-28privacy.mspx [slashdot.org]">took home a privacy innovation award for non-profits while Microsoft took home the corporate award when she worked for USPS.
  • by Jeian ( 409916 ) on Tuesday October 13, 2009 @08:11PM (#29739817)

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

  • by Lead Butthead ( 321013 ) on Tuesday October 13, 2009 @08:37PM (#29740015) Journal

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

  • by yourruinreverse ( 564043 ) on Tuesday October 13, 2009 @09:18PM (#29740279)

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

    • by thejynxed ( 831517 ) on Tuesday October 13, 2009 @11:23PM (#29741087) Homepage

      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.

  • p1n0y.net (Score:-1, Offtopic)

    by Anonymous Coward on Tuesday October 13, 2009 @09:26PM (#29740329)

    are we dofollow?
    lol
    http://p1n0y.net

  • by Anonymous Coward on Tuesday October 13, 2009 @09:39PM (#29740439)

    Welcome to our website: Http://www.tntshoes.com

    We can supply women shoes, brand shoe, safety shoe, clothes, sports products, craftwork and electronic products.
    (1) Material:100% authentic leather
    (2) High quality sports shoes with reasonable prices
    (3) Small trial orders accepted
    (4) With original box,
    (5) Size: US 8-13, Euro 41-47
    (6) Inner packing:1cardoard box

    We have various styles sport shoes on the company website. If you ask for details,
    please visit our website or contact us directly

      OUR WEBSITE:
                                                            YAHOO:shoppertrade@yahoo.com.cn

                                                                    MSN:shoppertrade@hotmail.com

                                                                    Http://www.tntshoes.com

  • by corychristison ( 951993 ) on Tuesday October 13, 2009 @10:58PM (#29740937)

    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.

  • by master_p ( 608214 ) on Wednesday October 14, 2009 @06:41AM (#29742879)

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

  • by hesaigo999ca ( 786966 ) on Wednesday October 14, 2009 @08:00AM (#29743385) Homepage Journal

    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.

  • by j00r0m4nc3r ( 959816 ) on Wednesday October 14, 2009 @11:00AM (#29745837)
    confirmed that no customer data was lost in the hack

    That's exactly what the data thieves wanted them to confirm.
  • by TheMaTrIxBEL ( 1269288 ) on Thursday October 15, 2009 @09:08AM (#29756751)
    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.

In every hierarchy the cream rises until it sours. -- Dr. Laurence J. Peter

Working...