//Author ? Robin Bailey
//Date ? 05/04/2009
//Email - rbailey.security<0x40>googlemail.com
//Contents
[1] Introduction
[2] The problem
[3] Solution
[4] Conclusion
//Introduction [1]
As the use of memory sticks has become more and more widespread, so
malware has
began to use them as a way to spread from machine to machine. While this
is a
problem for end users, the real danger is with IT professionals, who
might use
the same USB stick in dozens of computers in a single day, will often be
logged
in with administrative privileges, and will have access to important
machines.
This paper is aimed at those professionals, and how they can mitigate
the risk
of passing an infection onto other machines.
//The Problem [2]
Malware uses two main techniques to spread through memory sticks. The
first,
and less serious, is infecting executable files on the memory stick, so
that
when they are run on another machine, the infection moves with them.
The more common, and more dangerous, is to spread via the `autorun.inf`
file,
which Windows automatically executes when the drive is connected,
meaning that
no user interaction is needed. Conficker has been getting a lot of
attention
recently, and this was one of the methods it used to spread itself, but
many
other malicious programs used the same technique.
It is possible to disable the autorun feature from Windows, but this
requires
that the client machine has done this, which is not always the case, as
most
users will not have the technical knowledge to do this.
//The Solution [3]
Since we cannot rely on the computer to prevent the execution of the
autorun.inf file, we must do this from the memory stick. It is possible
to buy
memory sticks with read-only switches, so that they can be locked to
prevent
the computer writing to them, but this can cause problems, is easily
forgotten,
and doesn't help once the memory stick has been infected.
However, if the memory stick is FAT32, which most are, with the
exception of
some of the new 8GB+ drives, we can create a quick fix using a hex
editor, and
a basic knowledge of the FAT32 directory table.
First, we create a blank `autorun.inf` file on the memory stick, then
open up
the disk in a hex editor. It doesn't matter if you open the physical
disk, or
the logical partition, but if the disk has more than one partition, it is
better to do the latter. Make sure that the disk is opened with read/write
permissions, and that you haven't got anything accessing it at the time.
HxD
for Windows is a small, portable hex editor, if you don't already have one.
While this can be done to a disk with data on, it is safer to do it to a
blank
one, just in case there is a problem. If not, make sure that you have a
copy of
any data on the stick, if you don't, the you are liable to any loss of data
that might occur.
Next, run a search in the disk for the string `AUTORUN`, as a
non-Unicode text
string. It should find it near the beginning of the disk. The area we are
interested in is as follows.
41 55 54 4F 52 55 4E 20 49 4E 46 20
A U T O R U N I N F
The first 8 bytes are the filename (with a space at the end, because
autorun is
only 7 characters), followed by a 3 bytes file extension (INF), followed
by one
byte for the file attributes. It is this final byte that is relevant.
The current value of the byte (0x20) has just the archive bit set. What
we want
to do, is to change this byte to 0x40, which sets the device bit, which is
never normally found on a disk. The block will now look like this.
41 55 54 4F 52 55 4E 20 49 4E 46 40
A U T O R U N I N F @
Once this has been saved to disk, ignoring any warning that this might
corrupt
the disk, we then unmount and remount the volume. Now, when you browse
to the
disk, the autorun.inf file can be seen, but it cannot be deleted, opened,
edited, overwritten, or have its attributes changed.
When this memory stick is connected to an infected machine, which will
try to
create an autorun.inf file on it, it will fail with an error, (Cannot
create
file), meaning that this memory stick cannot be infected, and thus
cannot pass
an infection on to any other computers.
//Conclusion [4]
As stated before, this is not a guide aimed at end users, it is aimed at IT
professionals, or other power users, who will use the same USB stick on
multiple computers on a day to day basis.
Should this technique become widely used, we will almost certainly see
malware
that can bypass it, but until that happens, it can provide a simple but
effective defense against USB spreading malware.
If you have any comments/questions/suggestions send me an email.
# milw0rm.com [2009-04-06]
# EOF
--
LPIC-1 -- Linux Certified
http://bi0os.blogspot.com
"I like when the my box said:
All ports Are filtred =:)"
Learn all of the latest penetration testing techniques in InfoSec Institute's Ethical Hacking class.
Totally hands-on course with evening Capture The Flag (CTF) exercises, Certified Ethical Hacker and Certified Penetration Tester exams, taught by an expert with years of real pen testing experience.
//Author ? Robin Bailey
//Date ? 05/04/2009
//Email - rbailey.security<0x40>googlemail.com
//Contents
[1] Introduction
[2] The problem
[3] Solution
[4] Conclusion
//Introduction [1]
As the use of memory sticks has become more and more widespread, so
malware has
began to use them as a way to spread from machine to machine. While this
is a
problem for end users, the real danger is with IT professionals, who
might use
the same USB stick in dozens of computers in a single day, will often be
logged
in with administrative privileges, and will have access to important
machines.
This paper is aimed at those professionals, and how they can mitigate
the risk
of passing an infection onto other machines.
//The Problem [2]
Malware uses two main techniques to spread through memory sticks. The
first,
and less serious, is infecting executable files on the memory stick, so
that
when they are run on another machine, the infection moves with them.
The more common, and more dangerous, is to spread via the `autorun.inf`
file,
which Windows automatically executes when the drive is connected,
meaning that
no user interaction is needed. Conficker has been getting a lot of
attention
recently, and this was one of the methods it used to spread itself, but
many
other malicious programs used the same technique.
It is possible to disable the autorun feature from Windows, but this
requires
that the client machine has done this, which is not always the case, as
most
users will not have the technical knowledge to do this.
//The Solution [3]
Since we cannot rely on the computer to prevent the execution of the
autorun.inf file, we must do this from the memory stick. It is possible
to buy
memory sticks with read-only switches, so that they can be locked to
prevent
the computer writing to them, but this can cause problems, is easily
forgotten,
and doesn't help once the memory stick has been infected.
However, if the memory stick is FAT32, which most are, with the
exception of
some of the new 8GB+ drives, we can create a quick fix using a hex
editor, and
a basic knowledge of the FAT32 directory table.
First, we create a blank `autorun.inf` file on the memory stick, then
open up
the disk in a hex editor. It doesn't matter if you open the physical
disk, or
the logical partition, but if the disk has more than one partition, it is
better to do the latter. Make sure that the disk is opened with read/write
permissions, and that you haven't got anything accessing it at the time.
HxD
for Windows is a small, portable hex editor, if you don't already have one.
While this can be done to a disk with data on, it is safer to do it to a
blank
one, just in case there is a problem. If not, make sure that you have a
copy of
any data on the stick, if you don't, the you are liable to any loss of data
that might occur.
Next, run a search in the disk for the string `AUTORUN`, as a
non-Unicode text
string. It should find it near the beginning of the disk. The area we are
interested in is as follows.
41 55 54 4F 52 55 4E 20 49 4E 46 20
A U T O R U N I N F
The first 8 bytes are the filename (with a space at the end, because
autorun is
only 7 characters), followed by a 3 bytes file extension (INF), followed
by one
byte for the file attributes. It is this final byte that is relevant.
The current value of the byte (0x20) has just the archive bit set. What
we want
to do, is to change this byte to 0x40, which sets the device bit, which is
never normally found on a disk. The block will now look like this.
41 55 54 4F 52 55 4E 20 49 4E 46 40
A U T O R U N I N F @
Once this has been saved to disk, ignoring any warning that this might
corrupt
the disk, we then unmount and remount the volume. Now, when you browse
to the
disk, the autorun.inf file can be seen, but it cannot be deleted, opened,
edited, overwritten, or have its attributes changed.
When this memory stick is connected to an infected machine, which will
try to
create an autorun.inf file on it, it will fail with an error, (Cannot
create
file), meaning that this memory stick cannot be infected, and thus
cannot pass
an infection on to any other computers.
//Conclusion [4]
As stated before, this is not a guide aimed at end users, it is aimed at IT
professionals, or other power users, who will use the same USB stick on
multiple computers on a day to day basis.
Should this technique become widely used, we will almost certainly see
malware
that can bypass it, but until that happens, it can provide a simple but
effective defense against USB spreading malware.
If you have any comments/questions/suggestions send me an email.
# milw0rm.com [2009-04-06]
# EOF
--
LPIC-1 -- Linux Certified
http://bi0os.blogspot.com
"I like when the my box said:
All ports Are filtred =:)"
------------------------------------------------------------------------
This list is sponsored by: InfoSec Institute
Learn all of the latest penetration testing techniques in InfoSec Institute's Ethical Hacking class.
Totally hands-on course with evening Capture The Flag (CTF) exercises, Certified Ethical Hacker and Certified Penetration Tester exams, taught by an expert with years of real pen testing experience.
http://www.infosecinstitute.com/courses/ethical_hacking_training.html
------------------------------------------------------------------------
[ reply ]