Shostack + Friends Blog Archive


Two On ID Theft

Newsfactor has a long story, “U.S. Passes the Buck on Identity Theft,” [link to no longer works] which discusses the Identity Theft Penalty Enhancement Act of 2004, some of a current crop of products designed to reduce ID theft risks at businesses, and the need to shift liability.

Speaking of shifting liability, in “Despite Claims of “Exceptional” Security, Acxiom’s Defenses Were Easily Sidestepped,” Chris Hoofnagle discusses the Acxiom case. He draws on a Wall St Journal article, “Trial Highlights Vulnerability of Databases.” Two key quotes:

The problem erupted when Mr. Levine and other Snipermail employees allegedly downloaded a file containing encrypted passwords, unscrambled about 40% of them and gained access to information from other Acxiom clients.

Mr. Jones, the company’s legal chief, says the password file shouldn’t have been accessible and that passwords should have been harder to decode.

“Oops.” No, actually, more than oops. In the 1996 edition of “Practical Unix and Internet Security,” Garfinkel and Spafford say “Replace the encrypted passwords with asterisks.” (Pg 491) Acxiom wasn’t following that decade-old, basic advice. I’m pretty sure that also in the first edition of Cheswick and Bellovin, amongst many other places.

Acxiom didn’t know it had been invaded until being contacted by investigators in Ohio following the 2003 arrest of a man who worked for an Acxiom subcontractor and was accused of illegally downloading information from a company computer server. Acxiom then detected more intrusions of the same server, which were traced to Snipermail.

So, they couldn’t configure their servers. They didn’t have effective log analysis or intrusion detection. What, precisely, was this “exceptional” security?

A transfer of liability to the public at large, and of investigative costs to the taxpayer? Nah. Even they’re not that cynical. So, what was this “exceptional” security?

5 comments on "Two On ID Theft"

  • Axel says:

    Hey, you know the answer! It was exceptionally bad, of course! 🙂

  • Chris Walsh says:

    Let me get this straight:
    these guys were running a non-anonymous, non-chrooted FTP server, *and* the system did not use shadow passwords? I refuse to believe it. It would be too hard to even *find* a box that doesn’t use shadow passwords these days.

  • Adam says:

    Hi Chris,
    Are you arguing that Acxiom’s lawyer is misinformed? Additional quotes from the Journal:

    “We should have known better,” concedes Jerry Jones, who leads Acxiom’s business-development and legal teams. Since the Snipermail incident, Acxiom has toughened its encryption and password protocols and enhanced intrusion-detection systems. Acxiom also conducted 82 security audits during the past year, noting that its quick response and other efforts to reassure customers have helped it keep every client affected by the breach. The company says that the vast bulk of its data was never at risk because the breach occurred at a server located outside its technology “firewall.”

  • Chris Walsh says:

    I do not know what information the lawyer in question has. That would be most interesting to learn!
    As far as I can tell, the situation is this:
    * they ran FTP on a box in their DMZ
    * a world-readable file on that box contained encrypted passwords actually useful for FTP login
    Since we know non-anon FTP was used (perhaps in conjunction with anon FTP), there are only four ways this can happen:
    1. /etc/shadow is world-readable.
    2. Anon FTP is used but for some reason ~ftp/etc/shadow exists and is legitimate.
    3. Someone with a UID of 0 left a copy of /etc/shadow lying around world-readable.
    4. Shadow passwords are unavailable.
    1 is BAD, but a very green sysadmin might let it happen. This sysadmin shouldn’t be admin on a bastion host.
    2 is BAD, and takes more work to have happen. It proves that whoever set up anon FTP doesn’t understand how authentication works for non-anonymous FTP. This person needs more experience and shouldn’t be the sole admin on a bastion host.
    3 is BAD, period.
    I like how the same guy does business development and legal.
    What the heck is “toughened encryption and password protocols”? So they use MD5 instead of crypt? For the user whose password is “sesame” it doesn’t matter, and with today’s CPUs unless the customers are using long, complex passwords, they are 0wned.
    I really cannot believe this machine wasn’t using shadow passwords — Dave Curry’s UNIX System Security, from 1992, refers to shadow passwords on Ultrix, HP-UX, Solaris, and BSD 4.3 (ahh..memories) for gosh sakes, so I conclude it can’t be 4.
    The key thing is that the one file which in many ways is the most important on the box (I won’t count /vmunix) had to have been grievously mistreated for this to happen. They could have had the mother of all IDSes — what is it going to do, send a forged RST when it sees RETR /etc/shadow? Harumph.
    “The bulk of our data isn’t at risk, Mr. Customer — we only allowed *yours* to be stolen” doesn’t strike me as reassurring.

  • Adam says:

    Nice analysis. What if they’re not using UNIX? I think your analysis still holds.

Comments are closed.