Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Security-Basics
[Top] [All Lists]

Re: Disabling autorun for mapped network drives

Subject: Re: Disabling autorun for mapped network drives
Date: Thu, 26 Jul 2007 19:46:31 +0200
On 2007-07-26 Johnny Wong wrote:
Over the past few months, we have faced situations where user PCs 
were infected with virus when they connect to network mapped drives. 
What happened was that the virus creates "autorun.inf" in the root of 
the shared network drive, so users who double-click the drive in 
Explorer, the autorun.inf executes the linked virus-infected 
executable. Evem though the user PCs have anti-virus installed, the 
incidents we faced so far, the virus was not detectable. It was 
realised later that the virus was a new strain.

We have tried to disable the mapped-drives autorun feature (based on 
registry key settings); however, it was not foolproof because the 
autorun.inf was still able to execute in some cases. We found later 
from Microsoft's KB (http://support.microsoft.com/kb/933008) that 
this registry setting may not work. So we did not roll out this 
registry settings to the users.

Anyone of you facing the same situation as me? I can only think of 
the following solutions:

- keep AV signatures updated - this is not foolproof because most of 
the time, the virus writers are leading the game. So we can only try 
to send the first specimen we find ASAP to the AV vendors so that 
they could develop signatures for them. Guessed by that time, a 
number of users would have been infected.

- run a task on the file server that regularly checks for presence of 
autorun.inf in the root of the shared folders, and if found, rename 
or delete them. Implementation of this task will impact the 
performance of the server when it hosts a lot of shared folders.

Please share your workarounds if you have any.

Disable autorun via group policy for all drives. Problem solved.
Autorun is evil(tm).

Regards
Ansgar Wiechers
-- 
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq

<Prev in Thread] Current Thread [Next in Thread>