Re: --++[Preventing the spread of USB malware]++--

[Marcus Vinicius <marcovvinicius () gmail com>]

Yeap man, but this solution is for one place out the domain with Active 
directory. But thanks for you replay, is good too.  =)



Nathan Sportsman escreveu:
> Marcus,
>
> If the workstation is a member of a domain you can also disable the 
> autorun feature via Active Directory and group policy. This is a much 
> more effective solution for enterprise environments where you are 
> dealing with thousands of users and workstations.
>
> Regards,
> Nathan Sportsman
>
> --
> Nathan Sportsman
> Managing Partner, Praetorian
> http://www.praetoriangrp.com
> (O) 512.410.0350
> (F) 512.410.0356
> (C) 512.554.6181
>
> On Tue, Apr 14, 2009 at 1:22 PM, Shreyas Zare <shreyas () technitium com 
> <mailto:shreyas () technitium com>> 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 <mailto:shreyas () technitium com>
>
>     ..::< The Technitium Team >::..
>     Visit us at www.technitium.com <http://www.technitium.com>
>     Contact us at theteam () technitium com <mailto: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
>     <marcovvinicius () gmail com <mailto:marcovvinicius () gmail com>> wrote:
>      > Hello guys. one nice text.
>      >
>      >
>      >
>      > //Author – Robin Bailey
>      > //Date – 05/04/2009
>      > //Email - rbailey.security<0x40>googlemail.com
>     <http://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 <http://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
>     ------------------------------------------------------------------------


------------------------------------------------------------------------
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
------------------------------------------------------------------------