From: Nathan Sportsman (nathanpraetoriangrp.com)
Date: Tue Apr 14 2009 - 15:07:57 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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 <shreyastechnitium.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: shreyastechnitium.com
>
> ..::< The Technitium Team >::..
> Visit us at www.technitium.com
> Contact us at theteamtechnitium.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
> <marcovviniciusgmail.com> 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 =:)"
>
> ------------------------------------------------------------------------
> 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
------------------------------------------------------------------------

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]