Malware Versus Us: We're (Auto)Running Out of Time
Many of the biggest attacks of the last few years share a few common threads--the virus entered systems through a USB stick, and AutoRun is to blame.
September 28, 2010
This month's issue of Foreign Affairs contains an article by US Deputy Secretary of the Department of Defense, William J. Lynn, wherein he chronicles a 2008 cyberattack by another government upon the US military's computer systems—an attack that Lynn characterizes as the worst breach of those systems ever. In that same year, Spanair flight JK 5022 took off for the last time, crashing immediately and killing 155 people. Nearly two years of investigation lay the blame at the feet of a compromised airport network bogged down by trojans. In December of that year, most of us will remember a worm named "Conficker" that spread like wildfire, creating a bot army of at least seven million machines that is probably a tool for various kinds of electronic crime.
What do they all have in common? Well, to read the various news and comment on these seemingly disparate bits of bad news, they all share the same villain—the ubiquitous USB stick. As is so often the case when the media covers our business, however, they got it wrong. As I'll bet most readers of this piece already know, USB sticks were merely the unwitting henchmen of the real Lex Luthor in this story: Windows' AutoRun feature.
AutoRun has been with us since Windows 95, if I recall right. Whenever you plug a new drive of some kind into Windows (pop a CD or DVD into an optical drive, plug in a USB storage device, or the like), then Windows looks for a text file named "AutoRun.inf" in the root of that drive. AutoRun.inf can contain instructions to automatically run a program, with the intention of making application installation a snap. Instead of having to insert an installation CD or DVD, wait for the drive to spin up and then having to find the "setup.exe" or similar installation file on the disc, you just pop the disc in, walk away, and come back to find that the Setup program for the new application is already underway. (I'm simplifying here, as the feature can actually support a variety of newly plugged-in devices in a range of ways, like automatically playing an inserted music CD or movie DVD or activating a photo download tool when a digital camera is plugged in.)
Although AutoRun sounds like an intuitive tool, AutoRun.inf's ability to tell a system, "run such-and-such program" has led to situations where malware on an infected system waits for a user to pop a USB stick into that system, and then the malware first copies itself onto the USB stick and then creates an AutoRun.inf file that says, "automatically run me when inserted in a new system," and so merely inserting the now-infected USB stick into a PC causes that PC to install the malware on itself.
AutoRun also provides a great way for bad guys to penetrate an organization's network: just put a Trojan of some kind on a USB stick and an AutoRun.inf that contains instructions to install the Trojan. Then drop the USB stick (or, better, several dozen such USB sticks) around the organization's parking lot. Unsuspecting employees will pick up the USB sticks, carry them into the building and then shove them into their PCs, wondering, "what's on this USB stick?" Result: the AutoRun.infs get executed by Windows' helpful AutoRun system, and voila, several infected PCs are now gathering information off the victim organization's network and forwarding it back to the bad guys in some manner.
What can organizations do to combat this? Well, it's easy to remove threats of this kind altogether, as Windows includes a Group Policy setting that, when enabled, tells all of the PCs in a domain, "ignore any AutoRun.inf files." The problem is that most organizations don't seem to have implemented that Group Policy setting, and it's not enabled by default. Thus, Windows users are in a situation where plugging a simple USB stick into our computers could lead to a range of quite awful things, and, again, that's no idle the-sky-is-falling sensationalism, as my three opening examples show.
Don't misunderstand me; Microsoft's heart was in the right place with AutoRun. Designers and users of products of all kinds must make difficult—heck, often painful—choices between ease of use versus ease of attack in those products. No one likes having to live with the annoyance of house keys and car keys, but that annoyance is tiny compared to having to deal with lost cars and burgled houses, and so keyless houses and cars are essentially nonexistent.
Fortunately, I think there's an answer, and it may be the simplest answer to a really scary vulnerability in computing history. Microsoft, how about issuing a security update next month that turns off AutoRun by default? Don't kill the feature, and don't override any existing Group Policies—I mean, if someone has taken the time to create a Group Policy that explicitly enables AutoRun, then hey, they must know what they're doing. Just use Windows Update to change AutoRun from "on by default" to "off by default."
For that matter, maybe only apply it to the Professional/Business/Ultimate/Enterprise versions of desktop Windows. After all, AutoRun seems intended for users who are unable or unwilling to read documentation—folks for whom perusing README.TXT or AUTORUN.INF would be out of the question. I hope we can all agree that all of those would be home users.
But, just in case our friends in Redmond don't happen to agree with me about the wisdom of, or the need for, an anti-AutoRun security update, consider doing it on your network via group policies. You'll find the setting in
Computer Configuration/Administrative Tools/Windows Components/AutoPlay Policies
for Vista and Windows 7, and in
Computer Configuration/Administrative Tools/System
in XP—it's directly inside the System folder. Trust me, eventually all of us will have to live through having a user plug the wrong USB stick into an unfortunate PC, and honestly I suspect we've all just about "AutoRun" out of time to put on our anti-USB protection gear!
More commentaries from Mark Minasi:
About the Author
You May Also Like