Two On ID Theft
Newsfactor has a long story, “U.S. Passes the Buck on Identity Theft,” 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?
Hey, you know the answer! It was exceptionally bad, of course! 🙂
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.
Hi Chris,
Are you arguing that Acxiom’s lawyer is misinformed? Additional quotes from the Journal:
Adam:
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.
Nice analysis. What if they’re not using UNIX? I think your analysis still holds.