Security Basics mailing list archives

RE: Disabling autorun for mapped network drives


From: "Jesse Eaton" <jesse.eaton () gmail com>
Date: Thu, 26 Jul 2007 19:17:40 +0200

It's standard practice to disable autorun functionality for all our client
machines. You can set the local policy on a machine before imaging it. Then
all client builds that roll out will be set up.

Or you can set up a GPO, if you're in a domain environment. Enabling the
following Group Policy will do the trick:
User Config/Administrative Templates/System/Turn off Autoplay

Enable it for All Drives.

Also, McAfee VirusScan Enterprise default Access Protection rules block
autorun.inf's from running on protected machines. And you can manage McAfee
policies through ePO.

Or you can push a .reg file to all your machines to disable auto run. A
query by your favorite search engine will show you the values to edit...
Hope this helps.

-Jesse


-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On
Behalf Of Johnny Wong
Sent: Thursday, July 26, 2007 4:03 AM
To: security-basics () securityfocus com
Subject: Disabling autorun for mapped network drives

Hello all,

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.

Thank you,

JW


Current thread: