Preventing the spread of USB malware
> hello
> http://www.techsupportforum.com/sectools/sUBs/Flash_Disinfector.exe
> this tool do exactly what is needed to protect every drive and usb
> flash. Clean all of existing malicious stuff "/Flash_Disinfector will
> create a hidden folder named autorun.inf in each partition and every
> USB drive that is plugged in when you ran it.
> Don't delete this folder...it will help protect your drives from
> future infection.///"
>
> other good way to protect pc : block autorun/autoplay.
> This will allow you to change the system settings for AutoPlay/autorun.
> http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.msp
> x
>
> To block vbs script based viruses, use noscript from
> http://service1.symantec.com/sarc/sarc.nsf/html/pf/win.script.hosting.
> html
>
>
>
>
> On Tue, Apr 14, 2009 at 2:22 PM, Shreyas Zare > wrote:
>
> Hi,
>
> I use a simpler solution. I format the USB drive with NTFS (you need
> to set the device policy as "optimize for performance" in hardware
> details for formatting with NTFS, after the format u can revert back
> to "optimize for quick removal" if you wish to).
>
> I configure the NTFS file permissions for the entire drive such that
> only my trusted machine users (the user a/c on machines I fully trust
> to be non infected) have write access, and Everyone user has only read
> & execute access. Remove all other users from the file permissions.
>
> Then the most important thing, create a folder which I generally name
> "DMZ" and set file permission Everyone Full Control. This folder thus
> can be accesses to save files on untrusted machines. Thus *only* this
> folder may contain infected files if used on infected machine.
>
> This idea makes creating "autorun.inf" files not possible unless the
> malware author write code to take ownership & change permissions
> (which I have not seen yet). So this works quite well and I have been
> using this without any issue since 1yr or so.
>
> On the side note, I am coding a application (which is in testing
> phase, and will be commercial soon) to tackle this problem effectively
> without doing any such things like formatting with NTFS or editing
> file table in HEX and would catch most malware that spread through
> USB.
>
> Regards,
>
> --
> ("Computers have a strange habit of doing what you say, not what you
> mean." - SANS Top 25 Most Dangerous Programming Errors)
>
> Shreyas Zare
> Co-Founder, Technitium
> eMail: shreyas@technitium.com
>
> ..::< The Technitium Team >::..
> Visit us at www.technitium.com
> Contact us at theteam@technitium.com
>
>
> Join Sci-Tech News group and get the latest science & technology news
> in your inbox. Visit http://tech.groups.yahoo.com/group/sci-tech-news
> to join.
>
>
> On Tue, Apr 14, 2009 at 5:36 PM, Marcus Vinicius
> > wrote:
> > Hello guys. one nice text.
> >
> >
> >
> > //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 =:)"