Entries Tagged "vulnerabilities"

Page 43 of 49

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

Dangers of Reporting a Computer Vulnerability

This essay makes the case that there no way to safely report a computer vulnerability.

The first reason is that whenever you do something “unnecessary,” such as reporting a vulnerability, police wonder why, and how you found out. Police also wonders if you found one vulnerability, could you have found more and not reported them? Who did you disclose that information to? Did you get into the web site, and do anything there that you shouldn’t have? It’s normal for the police to think that way. They have to. Unfortunately, it makes it very uninteresting to report any problems.

A typical difficulty encountered by vulnerability researchers is that administrators or programmers often deny that a problem is exploitable or is of any consequence, and request a proof. This got Eric McCarty in trouble—the proof is automatically a proof that you breached the law, and can be used to prosecute you! Thankfully, the administrators of the web site believed our report without trapping us by requesting a proof in the form of an exploit and fixed it in record time. We could have been in trouble if we had believed that a request for a proof was an authorization to perform penetration testing. I believe that I would have requested a signed authorization before doing it, but it is easy to imagine a well-meaning student being not as cautious (or I could have forgotten to request the written authorization, or they could have refused to provide it…). Because the vulnerability was fixed in record time, it also protected us from being accused of the subsequent break-in, which happened after the vulnerability was fixed, and therefore had to use some other means. If there had been an overlap in time, we could have become suspects.

Interesting essay, and interesting comments. And here’s an article on the essay.

Remember, full disclosure is the best tool we have to improve security. It’s an old argument, and I wrote about it way back in 2001. If people can’t report security vulnerabilities, then vendors won’t fix them.

EDITED TO ADD (5/26): Robert Lemos on “Ethics and the Eric McCarty Case.”

Posted on May 26, 2006 at 7:35 AM • View Comments

Diebold Doesn't Get It

This quote sums up nicely why Diebold should not be trusted to secure election machines:

David Bear, a spokesman for Diebold Election Systems, said the potential risk existed because the company’s technicians had intentionally built the machines in such a way that election officials would be able to update their systems in years ahead.

“For there to be a problem here, you’re basically assuming a premise where you have some evil and nefarious election officials who would sneak in and introduce a piece of software,” he said. “I don’t believe these evil elections people exist.”

If you can’t get the threat model right, you can’t hope to secure the system.

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

Major Vulnerability Found in Diebold Election Machines

This is a big deal:

Elections officials in several states are scrambling to understand and limit the risk from a “dangerous” security hole found in Diebold Election Systems Inc.’s ATM-like touch-screen voting machines.

The hole is considered more worrisome than most security problems discovered on modern voting machines, such as weak encryption, easily pickable locks and use of the same, weak password nationwide.

Armed with a little basic knowledge of Diebold voting systems and a standard component available at any computer store, someone with a minute or two of access to a Diebold touch screen could load virtually any software into the machine and disable it, redistribute votes or alter its performance in myriad ways.

“This one is worse than any of the others I’ve seen. It’s more fundamental,” said Douglas Jones, a University of Iowa computer scientist and veteran voting-system examiner for the state of Iowa.

“In the other ones, we’ve been arguing about the security of the locks on the front door,” Jones said. “Now we find that there’s no back door. This is the kind of thing where if the states don’t get out in front of the hackers, there’s a real threat.”

This newspaper is withholding some details of the vulnerability at the request of several elections officials and scientists, partly because exploiting it is so simple and the tools for doing so are widely available.

[…]

Scientists said Diebold appeared to have opened the hole by making it as easy as possible to upgrade the software inside its machines. The result, said Iowa’s Jones, is a violation of federal voting system rules.

“All of us who have heard the technical details of this are really shocked. It defies reason that anyone who works with security would tolerate this design,” he said.

The immediate solution to this problem isn’t a patch. What that article refers to is election officials ensuring that they are running the “trusted” build of the software done at the federal labs and stored at the NSRL, just in case someone installed something bad in the meantime.

This article compares the security of electronic voting machines with the security of electronic slot machines. (My essay on the security of elections and voting machines.)

EDITED TO ADD (5/11): The redacted report is available.

Posted on May 11, 2006 at 1:08 PM • View Comments

When "Off" Doesn't Mean Off

According to the specs of the new Nintendo Wii (their new game machine), “Wii can communicate with the Internet even when the power is turned off.” Nintendo accentuates the positive: “This WiiConnect24 service delivers a new surprise or game update, even if users do not play with Wii,” while ignoring the possibility that Nintendo can deactivate a game if they choose to do so, or that someone else can deliver a different—not so wanted—surprise.

We all know that, but what’s interesting here is that Nintendo is changing the meaning of the word “off.” We are all conditioned to believe that “off” means off, and therefore safe. But in Nintendo’s case, “off” really means something like “on standby.” If users expect the Nintendo Wii to be truly off, they need to pull the power plug—assuming there isn’t a battery foiling that tactic. Maybe they need to pull both the power plug and the Ethernet cable. Unless they have a wireless network at home.

Maybe there is no way to turn the Nintendo Wii off.

There’s a serious security problem here, made worse by a bad user interface. “Off” should mean off.

Posted on May 10, 2006 at 6:45 AM • View Comments

Priority Cell Phones for First Responders

Verizon has announced that is has activated the Access Overload Control (ACCOLC) system, allowing some cell phones to have priority access to the network, even when the network is overloaded.

If you are a first responder with a Verizon phone, please visit the government’s WPS Requestor to provide the necessary information to have your handset activated.

Sounds like you’re going to have to enter some sort of code into your handset. I wonder how long before someone hacks that system.

Posted on May 1, 2006 at 1:29 PM • View Comments

The Security Risk of Special Cases

In Beyond Fear, I wrote about the inherent security risks of exceptions to a security policy. Here’s an example, from airport security in Ireland.

Police officers are permitted to bypass airport security at the Dublin Airport. They flash their ID, and walk around the checkpoints.

A female member of the airport search unit is undergoing re-training after the incident in which a Department of Transport inspector passed unchecked through security screening.

It is understood that the department official was waved through security checks having flashed an official badge. The inspector immediately notified airport authorities of a failure in vetting procedures. Only gardai are permitted to pass unchecked through security.

There are two ways this failure could have happened. One, security person could have thought that Department of Transportation officials have the same privileges as police officers. And two, the security person could have thought she was being shown a police ID.

This could have just as easily been a bad guy showing a fake police ID. My guess is that the security people don’t check them all that carefully.

The meta-point is that exceptions to security are themselves security vulnerabilities. As soon as you create a system by which some people can bypass airport security checkpoints, you invite the bad guys to try and use that system. There are reasons why you might want to create those alternate paths through security, of course, but the trade-offs should be well thought out.

Posted on April 26, 2006 at 6:05 AM • View Comments

Triple-DES Upgrade Adding Insecurities?

It’s a provocative headline: “Triple DES Upgrades May Introduce New ATM Vulnerabilities.” Basically, at the same time they’re upgrading their encryption to triple-DES, they’re also moving the communications links from dedicated lines to the Internet. And while the protocol encrypts PINs, it doesn’t encrypt any of the other information, such as card numbers and expiration dates.

So it’s the move from dedicated lines to the Internet that’s adding the insecurities.

Posted on April 17, 2006 at 6:48 AM • View Comments

1 … 41 42 43 44 45 … 49

Sidebar photo of Bruce Schneier by Joe MacInnis.