Exploiting 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.
© 2008 Kevin M. Williams. All Rights Reserved.
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
2
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.
3
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
4
•
•
•
•
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.
5
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?
6
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)
7
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.
8
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 subdirectory. 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
9
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
10
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.
11
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 proofof-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
12
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
13
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.
14
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.
15
For more information, refer to a thin client manufacturer’s website. You can also find thin clientrelated 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.
16
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.
17
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/howto-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-easytechnique-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
18
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;enus;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-youcan-touc.html
19
Appendices
------------------------------------------------------
Appendix A – Target Directory Screenshots
20
21
Appendix B – AutoPlay Screenshots
22
Appendix C – USB Flash Drive Screenshots
23
Appendix D – iPod Screenshots
24
Appendix E – Flash Memory Card Screenshots
25