Slashdot Mirror

← Back to Stories (view on slashdot.org)

Details Emerge of 2006 Wal-Mart Hack

Posted by kdawson on from the if-sam-were-alive-he'd-be-spinning-in-his-grave dept.

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

22 of 66 comments (clear)

  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

      http://www.peopleofwalmart.com/

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

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

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

    Nevermind

  4. 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.
  5. 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 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
  6. 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

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

  8. Re:Why? by cigawoot · · Score: 3, Funny

    Done!

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

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

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

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