Security WatchIsland Hopping: The Infectious Allure of Vendor Swag

Jesper M. Johansson

The technique of island hopping—penetrating a network through a weak link and then hopping around systems within that network—has been around for years. But it continues to take on new dimensions. In today's security-conscious IT environments, people are often the weakest link, and malicious users are

finding ways to use this to their advantage (think phishing and other forms of social engineering). This combination of carbon and silicon can prove fatal to your network.

One of my favorite implementations of leveraging the human element was perpetrated by Steve Stasiukonis of Secure Network Technologies during a penetration test for a customer. He seeded the customer's parking lot with USB flash drives, each of which had a Trojan horse installed on it. When the employees arrived for work in the morning, they were quite excited to find the free gadgets laying around the parking lot. Employees eagerly collected the USB drives and plugged them into the first computers they came across: their own workstations.

Maybe some employees were wise enough to ignore these USB drives, and perhaps some of the USB drives were discarded, but it really only took one user with one drive to infect his own system and provide a gateway into the network. Stasiukonis did this exercise as a test, of course, but this technique has been used by real criminals to infiltrate large corporate networks.

USB flash drives are everywhere these days. At almost every conference, some vendor is giving them away like candy. Those drives may not have a lot of capacity, but you don't need a lot of storage space to take over an entire network. In this two-part series, I will investigate this type of attack and show ways you can help mitigate the risk. In this month's installment, I will discuss what exactly USB flash drives can do and what you can do to control them. In next month's issue of TechNet Magazine, I will show you how to contain an attack to a single or small set of systems on the network.

The technical details of the attack are actually quite simple. It all starts with an infected USB flash drive being inserted into a single computer. What happens then depends on the payload on that drive and, of course, how gullible the user is.

In the Beginning

On the podium was an unattended laptop. The speaker was busily trying to ingratiate himself with the audience before beginning his presentation. The laptop itself was locked, but that hardly mattered. The attacker went up to the podium and lingered a bit, looking like he was just waiting for the speaker to return. Since those podiums are designed to hide ugly things like computers, the USB ports and the attacker's hands were shielded from view. Once the USB flash drive was inserted into the computer, it took only a few seconds to complete the attack.

There are some obvious variations on this particular theme. For example, when I used to travel the world doing presentations on a weekly basis, almost every time I finished, there were a few people asking for a copy of my slides. My answer was always to hand them a business card and ask them to send me an e-mail message. Why would I do that when every one of them was eagerly holding a USB flash drive toward me? Because I know about tools like USB Hacksaw and Switchblade. (If you aren't familiar with these, look them up at wiki.hak5.org.)

Basically, these tools make it really easy for just about anyone to exploit people who leave their USB ports unprotected. For example, Switchblade can dump the following:

• System information
• All network services
• A list of ports that are listening
• All product keys for Microsoft products on the computer
• The local password database
• The password of any wireless networks the computer uses
• All network passwords the currently logged on user has stored on the computer
• Internet Explorer®, Messenger, Firefox, and e-mail passwords
• The Local Security Authority (LSA) secrets, which contain all service account passwords in clear text
• A list of installed patches
• A recent browsing history

All of this goes into a log file on the flash drive, and takes about 45 seconds.

Hacksaw is a slightly modified version; it installs a Trojan on the computer, which monitors all USB flash drive insertion events. It then e-mails all documents from all flash drives subsequently inserted into the computer to the attacker.

The tools I have discussed so far use U3 (u3.com), a technology designed to enable users to bring programs with them on a flash drive. In a nutshell, a U3-enabled flash drive lies about itself. It tells the OS that it is actually a USB hub with a flash drive and a CD plugged into it. Windows® versions prior to Windows Vista® will, by default, automatically run programs designated in the autorun.inf file on CDs, but not on USB drives. By lying about itself, the U3-enabled USB flash drive fools the OS into autorunning something called the U3 launcher. The U3 launcher, in turn, can start programs, give you a menu, or do pretty much anything that you could do with the computer yourself.

All the exploit tools do is replace the launcher with the exploit code. As soon as the flash drive is plugged into a Windows XP system, the exploit tool automatically runs. On Windows Vista, the AutoPlay decision flow works differently. AutoRun is actually enabled on removable devices, just like on CDs. That means you will have some sort of action happen when the device is inserted. By default, the AutoPlay dialog will appear, as shown in Figure 1.

Figure 1** Default AutoPlay dialog appears when a user inserts a removable drive with pictures **

Notice that the dialog in Figure 1 has an option to "Always do this for pictures." This sets an AutoPlay option, which can be configured in the Control Panel, shown in Figure 2.

Figure 2** AutoPlay configuration on Windows Vista **(Click the image for a larger view)

The AutoPlay configuration is particularly interesting for "Software and games." By definition, it means the removable drive has an autorun.inf file that specifies some program to be executed. The settings in Figure 2 related to "Software and games" are stored in the following registry key:

Hive:    HKEY_CURRENT_USER
Key:    \Software\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\
UserChosenExecuteHandlers\AutorunINFLegacyArrival 
Value: (Default)
Data:
MSAutoRun – automatically executes the program specified in the autorun.inf file
   
MSPromptEachTime – prompts the user, using strings specified in the autorun.inf file, if available

As you do not need to be an administrator to modify these settings, users can set them to whatever they want, including automatically running whatever malware is on the drive they found in the parking lot. In fact, they can do it by checking the appropriate box in the AutoPlay dialog.

Managing AutoPlay in Your Network

As an administrator, there are a couple of ways you can manage AutoPlay throughout your network. First, you can prevent a user from enabling AutoPlay on removable media and CDs by modifying the NoDriveTypeAutoRun setting that controls which drive types AutoPlay is enabled for. Windows XP shipped with NoDriveTypeAutoRun set to 0x95, which disables AutoPlay on unknown drive types, network drives, and removable devices. Starting with Windows XP SP2, the NoDriveTypeAutoRun setting is configured to 0x91 by default. This enables AutoPlay on removable storage devices. Using Group Policy, there is a setting under User Configuration\Administrative Templates\Windows Components\AutoPlay Polices that allows you to manage the NoDriveTypeAutoRun setting. Enabling the "Turn off AutoPlay setting and select CD-ROM and Removable Drives" will disable AutoPlay on both types of drives.

As a result, though, the user does not get the AutoPlay dialog from Figure 1. In fact, nothing at all happens when the user inserts the drive. That may not be an ideal solution, however, as it can cause confusion for the user who isn't sure how to access the necessary information on the drive.

What you probably want to do is control which types of content can be played automatically. You can do this to some extent on Windows Vista, as this OS effectively has two levels of controls over automatically running software. Another control in Group Policy, shown in Figure 3, allows you to disable AutoPlay of software using autorun.inf files, while leaving the remainder of the Windows Vista AutoPlay behavior intact.

Figure 3** Disable autorun.inf files with Group Policy **(Click the image for a larger view)

The decision flow is a bit complicated when it comes to AutoPlay, and perhaps it is easiest to show with a flowchart. Figure 4 depicts the decision flow used when determining whether to automatically execute a file on removable media.

Figure 4** The AutoPlay decision flow **(Click the image for a larger view)

Other Beginnings

Of course, these are just some of the tools that can be used to compromise a computer with a USB flash drive. All sorts of tools can be added to this scenario, such as a tool that dumps out the currently logged-on user's Windows NT® password hash (see microsoft.com/technet/community/columns/secmgmt/sm1005.mspx).

Many USB controllers are actually Direct Memory Access (DMA) devices. This means they can bypass the operating system and directly read and write memory on the computer. Bypass the OS and you bypass the security controls it provides—now you have complete and unfettered access to the hardware. This renders device control implemented by the OS completely ineffective. I am unaware of any hacking tools that currently use this technique, but I very much doubt that this has not already been done.

Another way to exploit the user/removable device combination is to simply present an enticing option. For example, how many users would click the dialog in Figure 5? Not all, but probably many. The point is, it's a fairly trivial task to concoct a dialog that will be too enticing for users to ignore.

Figure 5** How many users would fall prey to this? **

Device Blocking

New in Windows Vista, Group Policy now has a set of policies to govern device installation (see Figure 6). As shown, the administrator can block all new removable devices from installing if the driver specifies that they are removable. If the driver states that they are not, however, the policy does not take effect. Thus, this policy can be circumvented using custom drivers.

Figure 6** Windows Vista device installation policies **(Click the image for a larger view)

For more granular control, the administrator can use the policies to act on specific device setup classes. However, those require you to know the GUID for the specific device class you wish to block (or allow), making this approach considerably more difficult to manage.

Least Privilege Really Matters

Ignoring the DMA scenario for a moment, the success of the attacks I have discussed, as well as the success of the countermeasures, will depend on the privileges of the user using the computer. If the user is a standard user, the amount of damage the exploit can do is limited. It can still steal that user's data and anything that user has access to. However, the attack will likely not impact the network at large.

However, if the user being exploited is an administrator, the consequences can be a whole lot worse. In the worst-case scenario, the user is a Domain Administrator, and taking over the entire network is trivial. For instance, the attacker could extract the user's password hash from memory. The system caches the hash within the LSA process space at logon so that it can be used to transparently access network resources on behalf of the user. An attacker with administrative privileges can extract this hash and access any network resources with it. In other words, if the user is a Domain Administrator, the entire domain has been compromised.

This leads me to the topic of dependencies. So far, I have outlined a specific attack on workstations. I have not, however, explored what the attack can lead to on a network scale. In next month's column, I will explore the concept of dependencies, showing you what they mean for the environment as a whole and, more importantly, what you can do to harden these dependencies.

Jesper M. Johansson is a Security Engineer working on software security issues and is a contributing editor to TechNet Magazine. He holds a PhD in MIS and has more than 20 years of experience in security.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.