March 24, 2004

Used Hard Disks Packed with Confidential Information

Simson Garfinkel has an eye-opening piece in CSO magazine about the contents of used hard drives. Simson bought a pile of used hard drives and systematically examined them to see what could be recovered from them.

I took the drives home and started my own forensic analysis. Several of the drives had source code from high-tech companies. One drive had a confidential memorandum describing a biotech project; another had internal spreadsheets belonging to an international shipping company.

Since then, I have repeatedly indulged my habit for procuring and then analyzing secondhand hard drives. I bought recycled drives in Bellevue, Wash., that had internal Microsoft e-mail (somebody who was working from home, apparently). Drives that I found at an MIT swap meet had financial information on them from a Boston-area investment firm.

...

One of the drives once lived in an ATM. It contained a year's worth of financial transactions—including account numbers and withdrawal amounts—from a organization that had a legal requirement to not divulge such information. Two other drives contained more than 5,000 credit card numbers—it looked as if one had been inside a cash register. Another had e-mail and personal financial records of a 45-year-old fellow in Georgia. The man is divorced, paying child support and dating a woman he met in Savannah. And, oh yeah, he's really into pornography.

It's shouldn't be a secret anymore than when you "delete" a file, it's not really gone. Yes, the file is unreachable by ordinary means, but virtually all of the information is still there on the hard disk, recoverable by anybody with the right tools. If you really want to destroy data, you have to use special disk scrubbing tools that overwrite the "empty" disk space with random data. It's not rocket science, but you do need to be careful.

In Simson's study, between one-third and one-half of the drives had significant amounts of confidential data that could be recovered. Only ten percent of the used drives had been properly scrubbed.


[Link credit: Michael Froomkin at discourse.net]

Posted by Ed Felten at 06:09 AM | Comments (87)

March 22, 2004

Security Attacks on Security Software

A new computer worm infects PCs by attacking security software, according to a Brian Krebs story in Saturday's Washington Post. The worm exploits flaws in two personal firewall products, made by Black Ice and Real Secure Internet. Just to be clear: the firewalls' flaw is not that they fail to stop the worm, but that they actively create a hole that the worm exploits. People who didn't buy these firewalls are safe from the worm.

This has to be really embarrassing for the vendor, ISS. The last thing a security product should do is to create more vulnerabilities.

This problem is not unique. Last week, another security product, Norton Internet Security, had a vulnerability reported.

Consumers are still better off, on balance, using PC security products. On the whole, these products close more holes than they open. But this is a useful reminder that all network software caries risks. Careful software engineering is needed everywhere, and especially for security products.

Posted by Ed Felten at 07:01 PM | Comments (119)

March 10, 2004

Detecting scams

Yesterday when I got home there was a message on my answering machine from AT&T Wireless. They told me that if I called an 800 number I could get a $30 credit for my cell phone service. For $30 I figured it was worth a few minutes of my time to call the number so I did. I was mildly suspicious that this was a scam, however. When I dialed the number, I got to talk to a computer, which asked me to enter my cell phone number, which I did. Then it asked me to enter the last four digits of my social security number for security purposes. Still concerned that this might be a scam, I hit the pound sign instead, and was transferred to a customer service representative. The customer rep asked me for my cell phone number again, and I gave it to her. She entered it into the computer and then reported it wasn't coming up. She asked me if I had any other numbers on this account. I did, so I gave her another number. Still, she reported, nothing came up. Next she said she would need my name and address. At this point I told her I was not going to give her any more information until she told me what this whole promotion was about. What exactly did I have to do to get this $30 credit. She said she didn't know for sure until she pulled my account up, but usually they would give this credit in exchange for a one-year contract renewal. I asked her why she couldn't pull up my information from the wireless phone number, and she told me the computer was down and she was going to write down my name and address information so they could get back to me. At that point I told her I would call back later and try again when the computer was up. If this really was AT&T Wireless I was talking to, my cell phone number, alone, should be sufficient to identify me when the computer came back up.

Was this a scam or was I really talking to AT&T Wireless? I am still not sure. I suspect this really was AT&T Wireless, in which case I think this is a really bad practice. There have been so many scams of late that involve similar tactics, that it seems to me to be bad form for any company to run an offer that requires its customers to divulge personal information without any way of verifying who they are talking to. I am somewhat of an expert and I cannot tell whether I was dealing with a scammer or a legitimate company. How can we train the average person not to fall for scams if legitimate companies engage in these sorts of practices?

Posted by Lorrie Cranor at 02:48 PM | Comments (110)

March 02, 2004

Constrained by Others' Shortcuts

Last year, Vivek Pai and some of my other colleagues at Princeton wrote an interesting paper called "The Dark Side of the Web: An Open Proxy's View", describing what happened when they deployed a large web proxy service. This useful and well-intentioned service was quickly discovered and used by a surprising variety of scammers and parasites who wanted to hide their activities.

A web proxy, of course, is a network service that acts as an intermediary for web requests. It receives a request from a browser, and passes that request on to the destination server; when the server replies, the proxy passes the reply back to the original requester. The authors' system, called CoDeeN, teamed up a large number of machines, scattered around the net, to act like a single mega-proxy. This is useful in various ways to web surfers.

It's also useful to the bad guys, since it puts an innocent intermediary between a malicious web user and the sites with which he interacts. Some the bad guys started using CoDeeN, which then allowed the CoDeeN team to see what the bad guys are up to. The list of attacks is surprisingly long and makes interesting reading.

Another lesson of the paper is that a surprising number of sites use a requester's IP address to authenticate the requester's identity or affiliation, or to blacklist bad actors. This is not a good practice, but it's surprisingly widespread. And it's a problem for web proxies, since requests that are funneled through a proxy seem to come from the proxy's IP address rather than that of the original requester. If the proxy is, say, within Princeton's IP address range, then anybody making a request through the proxy might (mistakenly) be assumed to be affiliated with Princeton. Or if a malicious request is funneled through the proxy, the targeted site might put the proxy's IP address onto a blacklist of "bad addresses", which would block access to the target site by the proxy's legitimate users.

Even though sites aren't supposed to be using IP addresses for authentication, many do; and the design of CoDeeN had to be changed to accomodate these other sites' bad practice. This sort of thing happens all the time in security: somebody's lazy decision makes it harder for somebody else to innovate later, because innovation tends to upset the fragile assumptions used by earlier developers.

Posted by Ed Felten at 04:24 PM | Comments (155)