Entries Tagged "computer security"

Page 25 of 33

Load ActiveX Controls on Vista Without Administrator Privileges

This seems like a bad idea to me:

Microsoft is adding a brand-new feature to Windows Vista to allow businesses to load ActiveX controls on systems running without admin privileges.

The new feature, called ActiveX Installer Service, will be fitted into the next public release of Vista to provide a way for enterprises to cope with the UAC (User Account Control) security mechanism.

UAC, formerly known as LUA (Limited User Account), is enabled by default in Vista to separate Standard User privileges from those that require admin rights to harden the operating system against malware and malicious hacker attacks.

However, because UAC will block the installation of ActiveX controls on Standard User systems, enterprise applications that use the technology will encounter breakages. ActiveX controls are objects used to enhance a user’s interaction with an application.

Posted on July 3, 2006 at 8:31 AM • View Comments

Economics and Information Security

I’m sitting in a conference room at Cambridge University, trying to simultaneously finish this article for Wired News and pay attention to the presenter onstage.

I’m in this awkward situation because 1) this article is due tomorrow, and 2) I’m attending the fifth Workshop on the Economics of Information Security, or WEIS: to my mind, the most interesting computer security conference of the year.

The idea that economics has anything to do with computer security is relatively new. Ross Anderson and I seem to have stumbled upon the idea independently. He, in his brilliant article from 2001, “Why Information Security Is Hard—An Economic Perspective” (.pdf), and me in various essays and presentations from that same period.

WEIS began a year later at the University of California at Berkeley and has grown ever since. It’s the only workshop where technologists get together with economists and lawyers and try to understand the problems of computer security.

And economics has a lot to teach computer security. We generally think of computer security as a problem of technology, but often systems fail because of misplaced economic incentives: The people who could protect a system are not the ones who suffer the costs of failure.

When you start looking, economic considerations are everywhere in computer security. Hospitals’ medical-records systems provide comprehensive billing-management features for the administrators who specify them, but are not so good at protecting patients’ privacy. Automated teller machines suffered from fraud in countries like the United Kingdom and the Netherlands, where poor regulation left banks without sufficient incentive to secure their systems, and allowed them to pass the cost of fraud along to their customers. And one reason the internet is insecure is that liability for attacks is so diffuse.

In all of these examples, the economic considerations of security are more important than the technical considerations.

More generally, many of the most basic security questions are at least as much economic as technical. Do we spend enough on keeping hackers out of our computer systems? Or do we spend too much? For that matter, do we spend appropriate amounts on police and Army services? And are we spending our security budgets on the right things? In the shadow of 9/11, questions like these have a heightened importance.

Economics can actually explain many of the puzzling realities of internet security. Firewalls are common, e-mail encryption is rare: not because of the relative effectiveness of the technologies, but because of the economic pressures that drive companies to install them. Corporations rarely publicize information about intrusions; that’s because of economic incentives against doing so. And an insecure operating system is the international standard, in part, because its economic effects are largely borne not by the company that builds the operating system, but by the customers that buy it.

Some of the most controversial cyberpolicy issues also sit squarely between information security and economics. For example, the issue of digital rights management: Is copyright law too restrictive—or not restrictive enough—to maximize society’s creative output? And if it needs to be more restrictive, will DRM technologies benefit the music industry or the technology vendors? Is Microsoft’s Trusted Computing initiative a good idea, or just another way for the company to lock its customers into Windows, Media Player and Office? Any attempt to answer these questions becomes rapidly entangled with both information security and economic arguments.

WEIS encourages papers on these and other issues in economics and computer security. We heard papers presented on the economics of digital forensics of cell phones (.pdf)—if you have an uncommon phone, the police probably don’t have the tools to perform forensic analysis—and the effect of stock spam on stock prices: It actually works in the short term. We learned that more-educated wireless network users are not more likely to secure their access points (.pdf), and that the best predictor of wireless security is the default configuration of the router.

Other researchers presented economic models to explain patch management (.pdf), peer-to-peer worms (.pdf), investment in information security technologies (.pdf) and opt-in versus opt-out privacy policies (.pdf). There was a field study that tried to estimate the cost to the U.S. economy for information infrastructure failures (.pdf): less than you might think. And one of the most interesting papers looked at economic barriers to adopting new security protocols (.pdf), specifically DNS Security Extensions.

This is all heady stuff. In the early years, there was a bit of a struggle as the economists and the computer security technologists tried to learn each others’ languages. But now it seems that there’s a lot more synergy, and more collaborations between the two camps.

I’ve long said that the fundamental problems in computer security are no longer about technology; they’re about applying technology. Workshops like WEIS are helping us understand why good security technologies fail and bad ones succeed, and that kind of insight is critical if we’re going to improve security in the information age.

This essay originally appeared on Wired.com.

Posted on June 29, 2006 at 4:31 PM • View Comments

Hacking Computers Over USB

I’ve previously written about the risks of small portable computing devices; how more and more data can be stored on them, and then lost or stolen. But there’s another risk: if an attacker can convince you to plug his USB device into your computer, he can take it over.

Plug an iPod or USB stick into a PC running Windows and the device can literally take over the machine and search for confidential documents, copy them back to the iPod or USB’s internal storage, and hide them as “deleted” files. Alternatively, the device can simply plant spyware, or even compromise the operating system. Two features that make this possible are the Windows AutoRun facility and the ability of peripherals to use something called direct memory access (DMA). The first attack vector you can and should plug; the second vector is the result of a design flaw that’s likely to be with us for many years to come.

The article has the details, but basically you can configure a file on your USB device to automatically run when it’s plugged into a computer. That file can, of course, do anything you want it to.

Recently I’ve been seeing more and more written about this attack. The Spring 2006 issue of 2600 Magazine, for example, contains a short article called “iPod Sneakiness” (unfortunately, not on line). The author suggests that you can innocently ask someone at an Internet cafe if you can plug your iPod into his computer to power it up—and then steal his passwords and critical files.

And here’s an article about someone who used this trick in a penetration test:

We figured we would try something different by baiting the same employees that were on high alert. We gathered all the worthless vendor giveaway thumb drives collected over the years and imprinted them with our own special piece of software. I had one of my guys write a Trojan that, when run, would collect passwords, logins and machine-specific information from the user’s computer, and then email the findings back to us.

The next hurdle we had was getting the USB drives in the hands of the credit union’s internal users. I made my way to the credit union at about 6 a.m. to make sure no employees saw us. I then proceeded to scatter the drives in the parking lot, smoking areas, and other areas employees frequented.

Once I seeded the USB drives, I decided to grab some coffee and watch the employees show up for work. Surveillance of the facility was worth the time involved. It was really amusing to watch the reaction of the employees who found a USB drive. You know they plugged them into their computers the minute they got to their desks.

I immediately called my guy that wrote the Trojan and asked if anything was received at his end. Slowly but surely info was being mailed back to him. I would have loved to be on the inside of the building watching as people started plugging the USB drives in, scouring through the planted image files, then unknowingly running our piece of software.

There is a defense. From the first article:

AutoRun is just a bad idea. People putting CD-ROMs or USB drives into their computers usually want to see what’s on the media, not have programs automatically run. Fortunately you can turn AutoRun off. A simple manual approach is to hold down the “Shift” key when a disk or USB storage device is inserted into the computer. A better way is to disable the feature entirely by editing the Windows Registry. There are many instructions for doing this online (just search for “disable autorun”) or you can download and use Microsoft’s TweakUI program, which is part of the Windows XP PowerToys download. With Windows XP you can also disable AutoRun for CDs by right-clicking on the CD drive icon in the Windows explorer, choosing the AutoPlay tab, and then selecting “Take no action” for each kind of disk that’s listed. Unfortunately, disabling AutoPlay for CDs won’t always disable AutoPlay for USB devices, so the registry hack is the safest course of action.

In the 1990s, the Macintosh operating system had this feature, which was removed after a virus made use of it in 1998. Microsoft needs to remove this feature as well.

EDITED TO ADD (6/12): In the penetration test, they didn’t use AutoRun.

Posted on June 8, 2006 at 1:34 PM • View Comments

Economics and Information Security

I would like to bring your attention to two conferences. The Workshop on Economics and Information Security is now in its fifth year. The next one will be held on June 26-28 in Cambridge (England, not Massachusetts). The paper selections have been announced, and it looks like a great conference.

The The Workshop on the Economics of Securing the Information Infrastructure will be held on October 23-24 in Washington, DC. This is a new workshop, and papers are still being solicited.

WEIS is currently my favorite security conference. I think that economics has a lot to teach computer security, and it is very interesting to get economists, lawyers, and computer security experts in the same room talking about issues.

I am on the program committee for both WEIS and WESII.

Posted on May 16, 2006 at 3:10 PM • View Comments

Man Sues Compaq for False Advertising

Convicted felon Michael Crooker is suing Compaq (now HP) for false advertising. He bought a computer promised to be secure, but the FBI got his data anyway:

He bought it in September 2002, expressly because it had a feature called DriveLock, which freezes up the hard drive if you don’t have the proper password.

The computer’s manual claims that “if one were to lose his Master Password and his User Password, then the hard drive is useless and the data cannot be resurrected even by Compaq’s headquarters staff,” Crooker wrote in the suit.

Crooker has a copy of an ATF search warrant for files on the computer, which includes a handwritten notation: “Computer lock not able to be broken/disabled. Computer forwarded to FBI lab.” Crooker says he refused to give investigators the password, and was told the computer would be broken into “through a backdoor provided by Compaq,” which is now part of HP.

It’s unclear what was done with the laptop, but Crooker says a subsequent search warrant for his e-mail account, issued in January 2005, showed investigators had somehow gained access to his 40 gigabyte hard drive. The FBI had broken through DriveLock and accessed his e-mails (both deleted and not) as well as lists of websites he’d visited and other information. The only files they couldn’t read were ones he’d encrypted using Wexcrypt, a software program freely available on the Internet.

I think this is great. It’s about time that computer companies were held liable for their advertising claims.

But his lawsuit against HP may be a long shot. Crooker appears to face strong counterarguments to his claim that HP is guilty of breach of contract, especially if the FBI made the company provide a backdoor.

“If they had a warrant, then I don’t see how his case has any merit at all,” said Steven Certilman, a Stamford attorney who heads the Technology Law section of the Connecticut Bar Association. “Whatever means they used, if it’s covered by the warrant, it’s legitimate.”

If HP claimed DriveLock was unbreakable when the company knew it was not, that might be a kind of false advertising.

But while documents on HP’s web site do claim that without the correct passwords, a DriveLock’ed hard drive is “permanently unusable,” such warnings may not constitute actual legal guarantees.

According to Certilman and other computer security experts, hardware and software makers are careful not to make themselves liable for the performance of their products.

“I haven’t heard of manufacturers, at least for the consumer market, making a promise of computer security. Usually you buy naked hardware and you’re on your own,” Certilman said. In general, computer warrantees are “limited only to replacement and repair of the component, and not to incidental consequential damages such as the exposure of the underlying data to snooping third parties,” he said. “So I would be quite surprised if there were a gaping hole in their warranty that would allow that kind of claim.”

That point meets with agreement from the noted computer security skeptic Bruce Schneier, the chief technology officer at Counterpane Internet Security in Mountain View, Calif.

“I mean, the computer industry promises nothing,” he said last week. “Did you ever read a shrink-wrapped license agreement? You should read one. It basically says, if this product deliberately kills your children, and we knew it would, and we decided not to tell you because it might harm sales, we’re not liable. I mean, it says stuff like that. They’re absurd documents. You have no rights.”

My final quote in the article:

“Unfortunately, this probably isn’t a great case,” Schneier said. “Here’s a man who’s not going to get much sympathy. You want a defendant who bought the Compaq computer, and then, you know, his competitor, or a rogue employee, or someone who broke into his office, got the data. That’s a much more sympathetic defendant.”

Posted on May 3, 2006 at 9:26 AM • View Comments

Microsoft's BitLocker

BitLocker Drive Encryption is a new security feature in Windows Vista, designed to work with the Trusted Platform Module (TPM). Basically, it encrypts the C drive with a computer-generated key. In its basic mode, an attacker can still access the data on the drive by guessing the user’s password, but would not be able to get at the drive by booting the disk up using another operating system, or removing the drive and attaching it to another computer.

There are several modes for BitLocker. In the simplest mode, the TPM stores the key and the whole thing happens completely invisibly. The user does nothing differently, and notices nothing different.

The BitLocker key can also be stored on a USB drive. Here, the user has to insert the USB drive into the computer during boot. Then there’s a mode that uses a key stored in the TPM and a key stored on a USB drive. And finally, there’s a mode that uses a key stored in the TPM and a four-digit PIN that the user types into the computer. This happens early in the boot process, when there’s still ASCII text on the screen.

Note that if you configure BitLocker with a USB key or a PIN, password guessing doesn’t work. BitLocker doesn’t even let you get to a password screen to try.

For most people, basic mode is the best. People will keep their USB key in their computer bag with their laptop, so it won’t add much security. But if you can force users to attach it to their keychains—remember that you only need the key to boot the computer, not to operate the computer—and convince them to go through the trouble of sticking it in their computer every time they boot, then you’ll get a higher level of security.

There is a recovery key: optional but strongly encouraged. It is automatically generated by BitLocker, and it can be sent to some administrator or printed out and stored in some secure location. There are ways for an administrator to set group policy settings mandating this key.

There aren’t any back doors for the police, though.

You can get BitLocker to work in systems without a TPM, but it’s kludgy. You can only configure it for a USB key. And it only will work on some hardware: because BItLocker starts running before any device drivers are loaded, the BIOS must recognize USB drives in order for BitLocker to work.

Encryption particulars: The default data encryption algorithm is AES-128-CBC with an additional diffuser. The diffuser is designed to protect against ciphertext-manipulation attacks, and is independently keyed from AES-CBC so that it cannot damage the security you get from AES-CBC. Administrators can select the disk encryption algorithm through group policy. Choices are 128-bit AES-CBC plus the diffuser, 256-bit AES-CBC plus the diffuser, 128-bit AES-CBC, and 256-bit AES-CBC. (My advice: stick with the default.) The key management system uses 256-bit keys wherever possible. The only place where a 128-bit key limit is hard-coded is the recovery key, which is 48 digits (including checksums). It’s shorter because it has to be typed in manually; typing in 96 digits will piss off a lot of people—even if it is only for data recovery.

So, does this destroy dual-boot systems? Not really. If you have Vista running, then set up a dual boot system, Bitlocker will consider this sort of change to be an attack and refuse to run. But then you can use the recovery key to boot into Windows, then tell BitLocker to take the current configuration—with the dual boot code—as correct. After that, your dual boot system will work just fine, or so I’ve been told. You still won’t be able to share any files on your C drive between operating systems, but you will be able to share files on any other drive.

The problem is that it’s impossible to distinguish between a legitimate dual boot system and an attacker trying to use another OS—whether Linux or another instance of Vista—to get at the volume.

BitLocker is not a panacea. But it does mitigate a specific but significant risk: the risk of attackers getting at data on drives directly. It allows people to throw away or sell old drives without worry. It allows people to stop worrying about their drives getting lost or stolen. It stops a particular attack against data.

Right now BitLocker is only in the Ultimate and Enterprise editions of Vista. It’s a feature that is turned off by default. It is also Microsoft’s first TPM application. Presumably it will be enhanced in the future: allowing the encryption of other drives would be a good next step, for example.

EDITED TO ADD (5/3): BitLocker is not a DRM system. However, it is straightforward to turn it into a DRM system. Simply give programs the ability to require that files be stored only on BitLocker-enabled drives, and then only be transferrable to other BitLocker-enabled drives. How easy this would be to implement, and how hard it would be to subvert, depends on the details of the system.

Posted on May 2, 2006 at 6:54 AM • View Comments

1 … 23 24 25 26 27 … 33

Sidebar photo of Bruce Schneier by Joe MacInnis.