Exploiting Autorun: Threats, Vulnerabilities and Countermeasures of the Autorun Functionality Associated with Portable Data Storage Devices by Kevin M

Home , Autoplay, AutoRun

Exploiting AutoRun: Threats, Vulnerabilities and Countermeasures of the AutoRun Functionality Associated with Portable Data Storage Devices by Kevin M. Williams, CISSP

Abstract ------On the battlefield of Information Security, amidst hackers, crackers, phreakers, and phrackers, cyber warriors, organized crime, script kiddies, and hacktivists, the last thing information security professionals would imagine having to worry about would be portable data storage devices. Nevertheless, a growing threat has emerged, stealing data and spreading malware by exploiting the seemingly benign nature of the AutoRun functionality associated with portable data storage devices.

In this study, we examine the vulnerabilities present in AutoRun functionality, the threats that target these vulnerabilities, and the countermeasures to stop them. While the results show that vulnerabilities do exist, and the threats are real, there are many effective countermeasures available to the information security professional. Most notably, security awareness training programs that educate and empower users can be the most effective weapon in the information security professional’s arsenal.

Table of Contents ------Abstract ...... 1 Acknowledgements ...... 3 Introduction ...... 4 Background ...... 4 Need for the Study...... 4 Purpose of the Study ...... 5 Limitations of the Study ...... 5 Organization of the Study...... 6 Research Questions ...... 6 Research Question One - Vulnerabilities ...... 6 Research Question Two - Threats ...... 6 Research Question Three - Countermeasures ...... 6 Literature Review...... 7 Methodology ...... 9 Scenario...... 9 Equipment ...... 9 Target...... 9 Scripts ...... 10 Process...... 11 Conclusion...... 11 Results ...... 12 Research Question One - Vulnerabilities ...... 12 Research Question Two - Threats...... 12 Research Question Three - Countermeasures...... 13 Countermeasure One – Security Awareness and Training...... 13 Countermeasure Two – Programmatic Suppression...... 14 Countermeasure Three – Registry Keys ...... 14 Countermeasure Four – Disabling Devices...... 15 Countermeasure Five – Group Policy...... 15 Countermeasure Six – BIOS Settings ...... 15 Countermeasure Seven – Thin Clients...... 15 Countermeasure Eight - Physical Prevention ...... 16 Additional Countermeasures ...... 16 Recommendations ...... 17 References...... 18 Appendices ...... 20 Appendix A – Target Directory Screenshots...... 20 Appendix B – AutoPlay Screenshots...... 22 Appendix C – USB Flash Drive Screenshots...... 23 Appendix D – iPod Screenshots ...... 24 Appendix E – Flash Memory Card Screenshots...... 25

Acknowledgements ------I would like to acknowledge my professor, Dr. Robert August, and the Center for Cyber-Security Policy, School of Business and Leadership, at Our Lady of the Lake University (CyberSecurity.OLLUSA.edu). Thank you for your guidance during this study.

I would also like to acknowledge all my co-workers at The Denim Group (DenimGroup.com), especially to Derek Flint, Erhan Kartaltepe, and Michael McBryde for lending me their technical expertise and proofreading my paper.

And lastly, I would like to acknowledge my wife, Adele Williams, not only for her technical expertise and proofreading, but also for her patience and understanding. Thank you for your compassion and kindness while I wrote this paper, hid away in our home office till 2 A.M. on consecutive nights surrounded by Star Wars toys and security textbooks.

Introduction ------

Background The seemingly benign nature of AutoRun functionality is being exploited by attackers to steal data, spread malware, and generally do harm. Exploits targeting what was once considered harmless is nothing new in the field of Information Security. One could argue that the very essence of what makes something an effective exploit is the ability to turn something previously overlooked into something dangerous.

One particular technique has even been given the name “podslurping”; pod because it can be done from an iPod, slurping because it can indiscriminately copy large amounts of data onto the device. An iPod that normally holds 60 GB of digital music can be used as a portable hard drive capable of stealing 60 GB of corporate data. In GFI Software’s white paper, Pod Slurping – An easy technique for stealing data, they describe pod slurping in this way: Data slurping is a very simple automated process and does not require any technical expertise; a user may plug in the portable storage device to a corporate workstation and by the time it takes to listen to an MP3, all the sensitive corporate data on that workstation is copied to the portable storage device. (p. 3)

The concept of attacks via unanticipated routes is nothing new. What is different about AutoRun exploits is the prevalence of portable data storage devices. USB storage drives (A.K.A. thumb or jump drives) are ubiquitous in the modern workplace. They can be purchased at nearly all retail stores, some for less than the cost of lunch. Any time a new technology is introduced, especially one that is cheap and easy to use, it inevitably invites exploits. Someone somewhere will find a way to turn that technology against its owner.

AutoRun exploits also highlight another important facet of information security: physical access controls. Besides all the logical controls you may have in-place, what are you doing to physical restrict or prevent access to your systems? I was always taught that in Information Security, physical access trumps logical access. (Williams, 2008) I recently covered this topic for my company’s blog in an article titled, If You Can Touch it, You Can Hack it. In the article, I explained the issue in this way: All the fancy authentication methods in the world won't help if someone can kidnap your PC! Physical access gives an attacker the ability to install a hardware keyboard logger, boot into a CD-based OS like Knoppix and access your entire file system, or if all else fails, just crack your case and steal your hard drive. (p. 1)

Writing that article served as an inspiration for this study. The research I did for it fueled my interest in the subject. At the time, I knew I had just barely scratched the surface of a much bigger issue regarding the threat of portable data storage devices.

Need for the Study In an InformationWeek article titled, Thumb Drives Replace Malware As Top Security Concern, Study Finds, the author cites a study that found these alarming statistics:

Of the 370 IT professionals polled: • 38.4% of IT managers say portable storage devices are their top security concern, that is up from 25.7% in 2006

• 80% of respondents admitted that their organizations don't currently have effective measures in place to combat the unauthorized use of portable devices • 43.2% cited no control at all • 8.6% have a total ban on portable devices • 65% of IT managers use a USB flash drive on a daily basis (p. 1)

Granted, the authors of the study cited were sellers of software that protects against the unwanted transfer of data to portable devices (Centennial-Software.com), so they may have more than just an academic interest in the subject matter. But their involvement highlights an interesting point: they’ve sold more than five million licenses to over five thousand organizations in forty-two countries (Centennial Software, 2008), so obviously someone is concerned about the security of portable data storage devices.

Purpose of the Study The purpose of this study is to make information security professionals aware of this growing threat and what they can do to protect themselves and others. This study will investigate what vulnerabilities are present in AutoRun functionality, what threats target those vulnerabilities, and what countermeasures can be implemented to protect against them.

Limitations of the Study There are a few limitations of this study. First, the study focuses entirely on the Microsoft Windows operating system. This was done to limit the scope of the paper, the quantity of research involved, and the likelihood that AutoRun exploits will target Windows users. Windows makes up the vast majority of all operating systems used worldwide, with some estimates as high as 90% of the market share. (Legard, 2004)

Second, this study acknowledges that as its being written, new threats and vulnerabilities are being discovered. In February 2008 alone, PacketStormSecurity.org recorded 334 new exploits. (Packet Strorm Security, 2008) This paper is by no means an exhaustive list of AutoRun exploits, but merely a general academic examination of the vulnerabilities, threats, and countermeasures associated with them.

Third, while this study will make countermeasure recommendations for preventing AutoRun exploits, these procedures should be taken under serious consideration before implementation. Where appropriate, you will be directed to refer to the manufacturers or responsible party’s websites. Making significant changes to your PC or network should not be done without the professional advice of skilled administrators or consultants. Please proceed with caution.

Fourth, there is third-party software that provides end-point security for portable data storage devices; however, this study is focusing on countermeasures that anyone can implement without the need to purchase additional software. This study will focus on simple, effective methods, such as awareness training or system re-configuring, to aid in eliminating the threat. The goal here is to change users’ mindsets when it comes to information security.

Fifth, please note that this paper refers to the functionality in question as AutoRun, rather than AutoPlay. While they are very similar in name and function, technically they are different in the sense that AutoPlay references the playback of an audio or video stream from a device as its plugged in (i.e., insert music CD and it starts playing without prompting). Quite often, the two terms are used interchangeably throughout the literature. For the purposes of this study; however, we will refer to the functionality in question as AutoRun, unless we are specifically referring to automatic playback functionality.

Organization of the Study The study is organized in relatively simple way. First, we will state the research problems we are attempting to answer. Second, we will review the current literature for references to AutoRun security. Third, we will collect and analyze data on AutoRun security by attempting to create and use some AutoRun exploits. Fourth, we will then evaluate the results as they pertain to the research problems. And fifth, we will then discuss what conclusions and recommendations we can make based on the results.

The paper follows the documentation standards of the American Psychological Association (APA) Publication Manual and the citation standards of the Harvard System of referencing. Please refer to either Books.APA.org or APAStyle.org for more information on the documentation and citation standards.

Research Questions In this study, we focused on the three primary research questions:

Research Question One - Vulnerabilities What are the vulnerabilities of AutoRun functionality? What vulnerabilities are present in AutoRun functionality? Are these merely bugs or design flaws? How do the vulnerabilities work?

Research Question Two - Threats What threats take advantage of AutoRun vulnerabilities? What are the treats to the vulnerabilities discussed in Question One? How likely are these threats to occur? What is their potential for causing harm?

Research Question Three - Countermeasures What are the countermeasures to AutoRun exploits? What countermeasures exist to prevent AutoRun exploits? How effective are these countermeasures? How easily can the countermeasures be implemented?

Literature Review ------Few direct mentions of AutoRun security were found in recognized industry standards and guidelines. ISO/IEC 27002 (formerly ISO 17799) and the Payment Card Industry Data Security Standard (PCI-DSS) both state you should prevent unauthorized access to equipment through physical means. While these are very general statements, AutoRun security does fall under their purview.

The best references reviewed were from The Standard of Good Practice for Information Security, from the Information Security Forum (SecurityForum.org). The Information Security Forum is an independent, international, non-profit organization that documents best-practices in information security. The Standard was first released in 1996, and has been updated every two years. The latest version of the Standard was released in February of 2007.

While these areas did not make explicit mention of AutoRun security they do cover nearly all areas of portable device security. Specifically, they are heavily focused on USB flash-memory drives, which they refer to as USB sticks, USB memory sticks, and USB storage devices. This is appropriate for the subject of this paper as USB flash memory drives are prevalent in the work area and one of the major areas of concern in AutoRun security.

The sections of The Standard concerning AutoRun security are as follows: Information Security Policy, SM1.2.7 A high-level policy (e.g., the information security policy) should prohibit: g) Using unauthorized information facilities or equipment (e.g., unauthorized third party software, USB sticks or modems) (p. 86)

Malware Protection Software, SM5.2.5 Malware protection software should be configured to scan: d) Removable computer storage media (e.g., CDs, DVDs and USB storage devices) (p. 117)

User Environment Workstation Protection, CB3.3.3 Workstations should be protected by the use of: f) Restrictions on the use of removable storage media (e.g., prohibition of personal use of external hard disk drives and USB memory sticks) (p. 159)

User Environment Security Awareness, CB3.4.4 Users of the application should be made aware that they are prohibited from: f) Using unauthorized information facilities or equipment (e.g., unauthorized third party software, USB sticks or modems) (p. 161)

Live Environment Workstation Protection, CI2.4.3 Workstations should be protected by the use of: f) Restrictions on the use of removable storage media (e.g., prohibition of personal use of external hard disk drives and USB memory sticks) (p. 194)

Computer Installation Security Awareness, CI5.2.4 Individuals employed in the computer installation should be made aware that they are prohibited from: f) Using unauthorized installation components (e.g., using unauthorized third party software, USB memory sticks or modems) (p. 216)

Local Security Management Roles & Responsibilities, UE1.1.3 Standards / procedures should specify methods of: e) Using removable storage media (e.g., CDs, DVDs, external hard disk drives, flash memory cards and USB memory sticks) (p. 308)

Portable Storage Devices, UE4.3.1 There should be documented standards / procedures covering the use of portable storage devices in the end user environment. Portable storage devices include external hard disk drives, flash memory cards such as secure digital (SD) and compact flash, USB memory sticks, solid state storage and MP3 players with storage capacity for holding data. Methods of connecting portable storage devices to computer equipment (e.g., laptop computers and desktop computers) include USB, FireWire and Bluetooth. (p. 330)

The above sections are all very good standards that will aid in preventing AutoRun exploits. Most importantly, they have a significant focus on security awareness training. The phrase “should be make aware” is repeated throughout the standards. Awareness of the risks and available safeguards is the first line of defense for the security of information systems and networks. (Kalmelid, 2007, p. 5)

Please refer to Research Question Three in the Results section for a discussion of security awareness training as a countermeasure to AutoRun exploits.

Methodology ------

Scenario To replicate an AutoRun exploit for this study, I first had to settle on what was a likely scenario. For this study, I chose a batch file-based podslurping technique. The scenario works like this: an attacker crafts a series of malicious scripts, places them onto portable data storage device, and then lends the device to a colleague. The attacker has actually targeted this colleague as a source of sensitive information they wish to exfiltrate; that is, to clandestinely steal. When the device is returned to the attacker, it unknowingly contains sensitive information off the targets PC.

Equipment For this study, I used only personal equipment found in my own home office. I tried to replicate to the best of my ability what an average attacker would have access to. I did not use any resources from my university or employer.

For the target machine, I used my home PC with the following specs and software: • Target PC: Dell Dimension XPS Gen4 PC (Named ‘DELL_XPS’) with Intel Pentium 4 CPU 3.8 GHz and 2 GB RAM • Operating System: Microsoft Windows Vista Business Edition with service pack 1, fully patched • Anti-Virus: AVG Free Edition v7.5.519 with virus base v269.22.7/1361 released 05 April at 0753 • Anti-Spyware: Microsoft Windows Defender, v1.1.1600.0 with Definition v1.31.8469.0 on 04 April 2008 at 0436 • Firewall: Windows Firewall enabled

While my home PC does have much higher specifications than the typical business system, those should have no bearing on the results. Additionally, the security posture of my home PC, running the latest service pack, operating system patches, and virus and spyware definitions, is most likely higher than that of the typical business system.

For the rogue devices, I used three common portable data storage devices: • Rogue Device One: PNY Technologies “Mini Attaché” 2 GB USB flash drive • Rogue Device Two: Sony “Memory Stick” 128 MB flash memory card • Rogue Device Three: Apple iPod Classic, Gen5, 60 GB, portable media device

Target To simulate an actual attack, I created a series of directories and files that will act as stand-ins for sensitive information. In a real-world scenario, these would be the documents an attacker would be attempting to infiltrate from your system. For the purposes of this study, they are merely text files to serve as a proof-of-concept.

On the target PC’s “C” drive (C :) I created a directory called target_dir. Under target_dir, I created three sub-directory titled confidential_dir, password_dir, and payroll_dir. I then created confidential_file.txt, password_file.txt, and payroll_file.txt, each in their corresponding sub- directory. The final target directory and file structure looked like this: C:\target_dir\ C:\target_dir\confidential_dir\ C:\target_dir\confidential_dir\confidential_file.txt

C:\target_dir\password_dir\ C:\target_dir\password_dir\password_file.txt C:\target_dir\payroll_dir\ C:\target_dir\payroll_dir\payroll_file.txt

Screenshots of the target directories and files can be found in Appendix A.

Scripts While researching AutoRun exploits, I continued to use the approach of an average attacker. Rather than crafting my own scripts I will find simple and easy to understand scripts elsewhere and use them as my own. As discussed in Research Question One, this clearly makes me a script kiddie. But that is OK, because if this study can show the dangers of reusing simple scripts, then it also highlights how much information security professionals should be weary of truly skilled and experienced hackers.

I did a simple Google search for “podslurping examples”, and as is usually the case with Google, the first result gave me exactly what I was looking for. On USBHacks.com, they have a good article titled How to: Simple “Podslurping” Example With a USB Flash Drive. This one article gave me the foundation for the attack. Using USBHacks.com advice, on each of the rogue devices, I loaded three files.

The first file is autorun.inf. This is the file that Windows uses know what AutoRun actions it may perform with this device. The autorun.inf file contained the following lines: [autorun] open=start.bat action=Open folder to view files shell\open\command=start.bat

The “open” parameter tells Windows what program to AutoRun; in this case it’s the second file, start.bat (see below). The “action” parameter is the text that appears in the AutoRun menu. In this case, I mimicked the language used by Vista on all AutoRun menus.

The second file is start.bat. This is the batch file referenced by autorun.inf in the lines above. The start.bat file contained the following lines: @echo off @start /min slurp.bat /B @exit

The at sign (@) hides the current line from being rendered in the Command Prompt window. The command “echo off” stops any lines from being displayed in the Command Prompt window. The command “start” opens a separate window to run a command; in this case the third file slurp.bat (see below). The “/min” switch starts the new window minimized. The “/B” switch prevents the new application window from even being displayed.

The third file is slurp.bat. This is the batch file referenced by start.bat in the lines above. The slurp.bat file contained the following lines: @echo off mkdir %~d0\%computername% xcopy "C:\target_dir\*.txt" %~d0\%computername% /s/c/q/r/h @cls @exit

The “mkdir” command creates a new windows directory. The “%~d0” is a Windows variable that equals the drive that batch file is currently running from. The “%computername%” is also a Windows variable; this one equals the name of the PC. The combined effect of the “mkdir %~d0\%computername%” command is to create a directory on the rogue device named after the target PC.

The “xcopy” command is an enhanced version of the regular “copy” command. "C:\target_dir\" is the source of the files to be copied, and “%~d0\%computername%” is the destination of the copied files. “*.txt” tells xcopy to copy all files with the extension txt. The asterisk is the wildcard flag in DOS commands. “txt” is the common file extension associated with text files.

Next are the xcopy switches S, C, Q, R, and H. “/s” tells xcopy to copy all directories and subdirectories at the source, except empty ones. “/c” tells xcopy to continue copying even if errors are encountered. “/q” tells xcopy to not display the filenames during copying. “/r” tells xcopy to override any read-only files it encounters. “/h” tells xcopy to copy hidden and system files.

The combined effect of xcopy "C:\target_dir\*.txt" %~d0\%computername% /s/c/q/r/h” is that xcopy will start in C:\target_dir\ and transverse all subdirectories, copying any text files it encounters, hidden or not, to a directory named after the PC on the portable data storage device, all without displaying any of this on the screen.

Process The process for verifying the success of the AutoRun exploit was relatively simple. First, I copied the three files onto the rogue devices. Second, I attached the rogue devices one-by-one to the target PC, each time taking a screen shot of the AutoRun menu as it appeared. (Appendix B). Third, without closing the AutoRun menu, I took a screenshot of the rogue device containing the three files and no exfiltrated target files. (Appendix C, D, & E) Fourth, I then clicked on the exploit’s entry on the AutoRun menu, launching the batch files. Fifth, I then took a screenshot of the rogue device now containing the exfiltrated directories and files. (Appendix C, D, & E) During this process, the user only sees a command prompt window quickly appear, minimize, and then close.

Conclusion While these results were ultimately harmless to my PC, they serve as a demonstration of the power of AutoRun exploits. I was able to copy the three target files onto the rogue device without any overt notification to the user. An attacker can use this method to unleash any harmful action they desire against the target PC. The scripts to do so are freely available on the Web, and the portable data storage devices are cheap and easy to use.

Results ------

Research Question One - Vulnerabilities What are the vulnerabilities of AutoRun functionality?

The main vulnerability of AutoRun functionality is quite obvious; so much so, it’s in the very name AutoRun. The fact that something is automatically running is the major vulnerability. It becomes fertile ground for an attacker anytime a program or process executes without the users permission or initiation. The AutoRun functionality takes the hardest part out of the equation for an attacker: How do I get the user to blindly execute my malicious logic?

Crafting the code to cause harm is the easy part; in fact, from the script kiddie’s perspective, you can even skip the “crafting” part. Script kiddies are essentially the vultures of the hacker landscape: they feed of the rotting corpses of the successful exploits of the highly skilled and experienced hackers. In an article titled Know Your Enemy, The Tools and Methodologies of the Script Kiddie, by the Honeynet Project (Project.Honeynet.org), they describe script kiddies in this way: The script kiddie is someone looking for the easy kill. They are not out for specific information or targeting a specific company. Their goal is to gain root the easiest way possible. They do this by focusing on a small number of exploits, and then searching the entire Internet for that exploit. Sooner or later they find someone vulnerable.

Some of them are advanced users who develop their own tools and leave behind sophisticated backdoors. Others have no idea what they are doing and only know how to type "go" at the command prompt. Regardless of their skill level, they all share a common strategy, randomly search for a specific weakness, then exploit that weakness. (p. 1)

This effect is humorously known as the Smart Cow Problem. In an article for Wired magazine (Wired.com), Fred von Lohmann, senior staff attorney with the Electronic Frontier Foundation (EFF.org), explained the name of the expression, "It's the smart-cow problem. It only takes one smart cow to open the latch of the gate, and then all the other cows follow." (Kahney, 2003, p. 2)

The second vulnerability isn’t native to AutoRun functionality so much as it is to the portable data storage devices themselves. The prolific nature of portable data storage devices, such as USB flash drives, and their relative ease-of-use, is the second vulnerability affecting portable data storage devices. As previously stated in the Background section, any time a new technology is introduced, especially one that is cheap and easy to use, it inevitably invites exploits.

Research Question Two - Threats What threats take advantage of AutoRun vulnerabilities?

The vulnerabilities in Research Question One would be harmless if it were not for threats exploiting them. In the field of Information Security, a threat is defined as any potential danger to information or an information system. ((ISC)2, 2006, p. 55) For the purposes of this study, the threat would be the harmful code or program that is automatically executed.

The Methodology section detailed the various devices and scripts used as AutoRun exploit proof- of-concepts. Since autorun.inf file can execute a batch file, the list of potential threats is limitless. An attacker can produce scripts that can execute any program they choose. Those programs

could steal data (as demonstrated in this study), spread viruses, install rootkits, or any other malicious action.

The wide and varied nature of the possible threats is a prime example of the necessity of Defense in Depth. In the field of Information Security Defense in Depth is the concept of multiple overlapping defensive measures. (Cox & Greg, 2004, p. 2) In the SANS GIAC (GIAC.org) book Network Intrusion Detection, the authors explain Defense in Depth as: Defense in Dept doesn’t stop with the perimeter, of course. It includes configuration management, personal firewalls, anti-virus, content scanning at the perimeter, operating system patches, and an active vulnerability scanning program. (p. 390)

All of tactics and technologies listed above will aid in reducing, if not eliminating, the effects of AutoRun exploits. However, these defenses do not stop the underlying vulnerabilities that the threats are taking advantage of; the usage of rogue portable data storage devices and the automatic execution of programs and scripts. For true prevention of AutoRun exploits we will need to implement actual countermeasures to these threats.

Research Question Three - Countermeasures What are the countermeasures to AutoRun exploits?

A countermeasure is a “control, method, technique, or procedure that is put into place to prevent a threat agent from exploiting vulnerability and mitigate risk.” (Harris, 2005, p. 957) There are many countermeasures that can reduce, or even outright eliminate, AutoRun exploits. These countermeasures vary in their strategy and severity. In this section, we will examine the ease of implementing these countermeasures and how they effectively prevent AutoRun exploits.

Countermeasure One – Security Awareness and Training Cryptography expert Bruce Schneier once said, “If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.” (Mann, 2002)

Arguably, the cheapest and most effective countermeasure available is a security awareness and training program. According to the Federal information Security Management Act, a security awareness training program must inform employees of information security risks associated with their activities and their responsibilities in complying with agency policies and procedures designed to reduce these risks. (National Institute of Standards and Technology, 2002) An effective security awareness program can be the most cost-effective action management can take to protect its critical information assets. (Peltier, 2002, p. 149) Rather than relying on a single piece of software to prevent an attack, you can turn every employee into a mobile sensor.

As we demonstrated in the Methodology section these attacks are successful because they rely on an unsuspecting, untrained, or unaware user. You must train your users on security policies and procedures, how they are a part of enforcing and maintaining the security process, and to be aware and report potential avenues for attack. Through training and awareness programs your employees will have a sense of ownership in the security policy and “embrace it as an integral part of their jobs.” (Barman, 2002, p. 32)

Please refer to the Literature Review section for a good example of industry-recognized standards focusing on security awareness of portable device security

Countermeasure Two – Programmatic Suppression You can suppress AutoRun by simply disabling the functionality in your operating system. For example, you can do this through the Control Panel in Microsoft Windows Vista. There you will find AutoPlay configuration options under the Control Panel’s Hardware and Sound section where you can disable AutoRun globally or by device or medium. In Windows XP, you can only disable AutoRun through the use of TweakUI, a customization application freely downloadable from Micosoft.com as a part of their Power Toys suite. The Power Toys’ URL is available in the References section.

Alternatively, if you are using the Microsoft Windows Shell v4.70 or later and need to disable AutoRun while writing application code, you can follow the steps outlined in the Microsoft Developer’s Network (MSDN) article, Enabling and Disabling AutoRun. By using the QueryCancelAutoPlay message your application can respond to this message to suppress AutoRun. (Microsoft, 2008)

Please refer to the MSDN article for code samples and further discussion of this technique. The MSDN article’s URL is available in the References section.

Countermeasure Three – Registry Keys You may use the Windows Registry to disable AutoRun by drive letter or device. The MSDN article, Enabling and Disabling AutoRun, explains it this way: There are two registry values that can be used to persistently disable AutoRun: NoDriveAutoRun and NoDriveTypeAutoRun. The first value disables AutoRun for specified drive letters and the second disables AutoRun for a class of drives. If either of these values is set to disable AutoRun for a particular device, it will be disabled. (p. 1)

Both NoDriveAutoRun and NoDriveTypeAutoRun values can be found in the following registry key, HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Policies\ Explorer\.

Additionally, you can use the registry to disable the use of USB devices. The Microsoft Support article How to disable the use of USB storage devices discusses the registry values and keys that can be changed to prevent users from connecting USB storage devices. The article describes the process as follows: If a USB storage device is not already installed on the computer, assign the user or the group Deny permissions to the following files: • %SystemRoot%\Inf\Usbstor.pnf • %SystemRoot%\Inf\Usbstor.inf When you do so, users cannot install a USB storage device on the computer. (p. 1)

If a USB storage device is already installed on the computer, set the Start value in the following registry key to 4: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\UsbStor When you do so, the USB storage device does not work when the user connects the device to the computer. (p. 1)

Please note that edits to the registry should be done by only skilled administrators as there is great potential for wreaking unintentional havoc on your system. Registry keys and values should be changed only when absolutely necessary.

Please refer to the MSDN and Microsoft Support articles for more details on modifying the appropriate registry values and keys. The articles’ URLs are available in the References section.

Countermeasure Four – Disabling Devices You can prevent a device from using AutoRun by simply disabling or uninstalling the device through the operating system. For example, this would be done through the Control Panel in all versions of Microsoft Windows. Highlight the device in question and either right-click or select Action on the menu bar, then choose Disable or Uninstall from the submenu.

Please note that disabling or uninstalling device drivers can have unforeseen consequences, so due care should be taken when performing these actions. Also, this is by no means a “permanent” solution; depending on security permissions, users may be able to enable or reinstall the devices themselves.

Countermeasure Five – Group Policy Along the same lines as Countermeasure Four, you can disable devices through the use of Group Policy to change registry values and keys in Microsoft Windows. By default, this option is not present in group Policy, but you can create and apply a custom Administrative Template that will. Administrative Templates, or .adm files, are text files used to modify specific keys and values in the registry. For many applications the use of registry-based policy delivered by .adm files is the simplest and best way to support centralized management of policy settings. (Microsoft, 2004)

Please refer to the Microsoft TechNet white paper, Using Administrative Template Files with Registry-Based Group Policy for more information on customizing Administrative Templates. Also, an example Administrative Template for disabling AutoRun devices can be found at USBHacks.com. URLs for both can be found in the References section.

Countermeasure Six – BIOS Settings Your computer’s BIOS settings are another means of quickly disabling devices. Most BIOS give you the ability to shut down most device ports, including USB, Firewire, serial, and parallel. While this certainly will prevent AutoRun functionality, it will in fact make the device completely unusable.

As with registry edits in Countermeasure Three, only skilled administrators should change BIOS settings, as mistakes can create serious problems with your PC. BIOS settings should only be changed when absolutely necessary.

Countermeasure Seven – Thin Clients Thin clients provide one of the few countermeasures that can completely eliminate the threat of AutoRun functionality. Thin clients are a “server-centric computing model in which the application software, data, and CPU power resides on a network server rather than on the client computer.” (Wikipedia, 2008) Essentially, it’s a PC with just a screen, mouse, and keyboard. Thin clients can physically eliminate the user’s ability to input a disc or connect a device, thus preventing AutoRun exploits.

Implementing thin clients into your network is no small undertaking, as it is a complete paradigm shift in desktop computing. There are associated server, software, and infrastructure considerations that will also need to be addressed. There are a variety of manufacturers of thin clients, each with their own set of deployment requirements.

For more information, refer to a thin client manufacturer’s website. You can also find thin client- related information from technology articles and blogs, such as ThinClient.org.

Countermeasure Eight - Physical Prevention Finally, one can prevent AutoRun functionality by physically eliminating AutoRun devices. Some companies have resorted to a very low-tech approach by “physically filling the USB connectors with a thick epoxy adhesive”. (Hamid, 2006) While this may be incredibly effective, there are much less destructive ways of preventing rogue devices.

If you don’t want users inputting particular devices into their PCs, then simply remove the offending devices from the PC. If the user has no need to load CD-ROMs, then remove the CD drive from the PC. Better yet, save money and don’t order new PCs with hardware they don’t need. For instance, if your users have no business-related need for attaching devices to their PC via FireWire, don’t order a new PC with a FireWire card. Not only is it one less part for your IT staff to maintain, but it will save you $30 and eliminate a potential attack vector.

Additional Countermeasures This study found eight countermeasures to AutoRun exploits, but there are always more. Information security is a constantly changing landscape and new countermeasures are being discovered just as zero-day exploits are hitting the streets.

Some of the best advice the study can offer is to stay abreast of current developments in the industry. Read blogs, subscribe to email alerts, attend conferences, join professional organizations, and read publications. All of these are good sources to learn about new threats and how to protect against them.

Recommendations ------No single countermeasure will be effective for all organizations and in all scenarios but some of them can be applied generally to aid most. First, it is always a good idea to have your administrators enable Group Policy throughout the network to ensure standardization. In addition to configuring devices and their behavior, administrators can perform other best-practice security changes, such as enforcing password protected screen savers.

Second, a security awareness training program should be implemented across your organization. In addition to training users on the topics covered in this study, there is a wide-variety of information security topics users should be made aware of. Education provides decision-making, and security management skills that are important for the success of an organization’s security program. ((ISC)2, 2006, p. 42)

The concepts behind the AutoRun security discussed in this study are nothing new. Attacker have always been exploiting what was otherwise harmless functionality; that is the very essence of an exploit. Even if you implement every countermeasure mentioned in this paper, you will only deter attacks until they come up with a new approach. Only by educating and empowering your users, will you be able to prevent AutoRun exploits.

Through security awareness you are not treating the symptoms of AutoRun exploits, but rather you are treating the cause. Awareness becomes like a vaccine: now that your users have been exposed to the attacks, they can be alert and defend themselves the next time they encounter the threat.

References ------

(ISC)2. (2006). The (ISC)2 CISSP CBK Review Seminar Student Manual v5.0. Boston, MA, USA: Pearson.

Akuma. (2006, October 06). How to: Disable USB and CD-ROM on a Windows Network Using Group Policy. Retrieved March 30, 2008, from USBHacks.com: http://www.usbhacks.com/wp-content/uploads/sample_adm.txt

Akuma. (2006, October 29). How to: Simple “Podslurping” Example With a USB Flash Drive. Retrieved March 13, 2008, from USBHacks.com: http://www.usbhacks.com/2006/10/29/how- to-simple-podslurping-example-with-a-usb-flash-drive/

Barman, S. (2002). Writing Information Security Policies. Indianapolis, IN, USA: New Riders.

Centennial Software. (2008, January 01). About Centennial Software. Retrieved April 03, 2008, from Centennial-Software.com: http://www.centennial-software.com/company/about/

Cox, K., & Greg, C. (2004). Managin Security with Snort and IDS Tools. Sebastopol: O'Reilly.

Gaudin, S. (2007, May 07). Thumb Drives Replace Malware As Top Security Concern, Study Finds. InformationWeek .

GFI Software. (2007, January 01). Pod Slurping – An easy technique for stealing data. Retrieved April 03, 2008, from GFI.com: http://www.gfi.com/whitepapers/pod-slurping-an-easy- technique-for-stealing-data.pdf

Hamid, L. (2006, April 16). New security from USB mass storage. Retrieved March 31, 2008, from TheGlobeandMail.com: http://www.theglobeandmail.com/servlet/story/RTGAM.20060313.gtflhamidmar13/BNStory/Te chnology/

Harris, S. (2005). CISSP All-In-One Exam Guide (Third ed.). Emeryville, CA, USA: McGraw-Hill.

Honeynet Project. (2000, July 21). Know Your Enemy, The Tools and Methodologies of the Script Kiddie. Retrieved April 04, 2008, from Project.Honeynet.org: http://www.honeynet.org/papers/enemy/

Information Security Forum. (2007). The Standard of Good Practice for Information Security. London: Information Security Forum.

International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). (2007). ISO/IEC 27002. Geneva: ISO/IEC.

Kahney, L. (2003, October 21). Buck a Song, or Buccaneer? Wired .

Kalmelid, K. (2007, December 12). Facing the challenges of privacy and. Retrieved April 02, 2008, from ENISA.Europa.EU: http://cor.europa.eu/cms/pages/documents/educ/lahti/Kalmelid%20Lahti%20eInclusion%20se minar%2012-12-2007.pdf

Legard, D. (2004, April 27). IDC: Consolidation to Windows won't happen. Retrieved March 31, 2008, from LinuxWorld.com: http://www.linuxworld.com.au/index.php/id;940707233;fp;2;fpid;1

Mann, C. C. (2002, September 01). Homeland Insecurity. Retrieved April 05, 2008, from TheAtlantic.com: http://www.theatlantic.com/doc/200209/mann

Microsoft. (2008, January 01). Enabling and Disabling AutoRun. Retrieved March 30, 2008, from Microsoft Developer Network: http://msdn2.microsoft.com/en-us/library/bb776825.aspx

Microsoft. (2005, April 19). How to disable the use of USB storage devices. Retrieved April 03, 2008, from Support.Microsoft.com: http://support.microsoft.com/default.aspx?scid=kb;en- us;823732

Microsoft. (2008, January 01). Microsoft PowerToys for Windows XP. Retrieved March 30, 2008, from Microsoft.com: http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx

Microsoft. (2004, October 11). Using Administrative Template Files with Registry-Based Group Policy. Retrieved March 30, 2008, from Microsoft TechNet: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/management /gp/admtgp.mspx

National Institute of Standards and Technology. (2002). Federal Information Security Management Act. Gaithersburg, MD, USA: US Federal Law.

Northcutt, S., & Novak, J. (2003). Network Intrusion Detection (Third ed.). Indianapolis, IN, USA: New Riders.

Packet Strorm Security. (2008, March 01). 0802-exploits. Retrieved March 31, 2008, from PacketStormSecurity.org: http://www.packetstormsecurity.org/0802-exploits/

Payment Card Industry Security Standards Council. (2006). Payment Card Industry Data Security Standard. Wakefield: Payment Card Industry Security Standards Council.

Peltier, T. R. (2002). Information Security Poicies, Procedures, and Standards. Boca Raton, FL, USA: Auerbach.

Wikipedia. (2008, January 01). Thin Client. Retrieved March 31, 2008, from Wikipedia, The Free Encyclopedia: http://en.wikipedia.org/w/index.php?title=Thin_client&oldid=201969080

Williams, K. M. (2008, March 05). If You Can Touch it, You Can Hack it. Retrieved March 31, 2008, from Denim Group Blog: http://denimgroup.typepad.com/denim_group/2008/03/if-you- can-touc.html

Appendices ------

Appendix A – Target Directory Screenshots

Appendix B – AutoPlay Screenshots

Appendix C – USB Flash Drive Screenshots

Appendix D – iPod Screenshots

Appendix E – Flash Memory Card Screenshots