Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Marcus Vinicius (marcovviniciusgmail.com)
Date: Tue Apr 14 2009 - 21:04:58 CDT
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:
> 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.
> Nathan Sportsman
> Nathan Sportsman
> Managing Partner, Praetorian
> (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
> <mailto:shreyastechnitium.com>> wrote:
> 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
> ("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 <mailto:shreyastechnitium.com>
> ..::< The Technitium Team >::..
> Visit us at www.technitium.com <http://www.technitium.com>
> Contact us at theteamtechnitium.com <mailto: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 <mailto:marcovviniciusgmail.com>> wrote:
> > Hello guys. one nice text.
> > //Author – Robin Bailey
> > //Date – 05/04/2009
> > //Email - rbailey.security<0x40>googlemail.com
> > //Contents
> >  Introduction
> >  The problem
> >  Solution
> >  Conclusion
> > //Introduction 
> > 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 
> > 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
> > file,
> > which Windows automatically executes when the drive is connected,
> > 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 
> > 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
> > 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
> > 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
> > 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,
> > 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 
> > 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.
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.