Bugtraq mailing list archives

Re: AUTORUN Vulnerability - Round 2


From: Matthew Leeds <mleeds () theleeds net>
Date: Mon, 19 Feb 2001 15:25:17 -0800

Autorun is controlled by the host. The following excerpt from a Microsoft KB article provides details. This is NT4 
Workstation.
-----snip-----
http://support.microsoft.com/support/kb/articles/Q185/5/90.ASP?LN=EN-US&SD=gn&FR=0&qry=What%20controls%20autorun&rnk=1&src=DHCS_MSPSS_gn_SRCH&SPR=NTW40

The following section describes the locations and values for useful registry entries that are available in the 
operating system, but not available in the System Policy Editor.

Autorun:
Category: Windows NT Shell
Subcategory: Removable media
Description: Determines whether the Autorun feature is enabled on each drive connected to the system. When Autorun is 
enabled, media is started automatically when it is inserted in the drive. This value is comprised of 32 bits. The lower 
26 bits each represent a drive, with the lowest (right- most) bit representing drive A and the 26th bit from the right 
representing drive Z. If a bit is set to 0, the autorun feature is enabled on that drive. If a bit is set to 1, the 
autorun feature is disabled on that drive.

For example, if the value of this entry is 0x8 (1000 binary), autorun is disabled on drive D. Note that a value of 1 in 
the bit representing the CD- ROM drive takes precedence over the value of Autorun.
Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion \Policies\Explorer

Registry Value Registry Data Description
NoDriveAutoRun REG_DWORD 0x0 - 0x3FFFFFF
-----snip-----

---Matthew
*********** REPLY SEPARATOR  ***********

On 2/16/01 at 7:48 PM David LeBlanc wrote:

-----Original Message-----
From: Nelson Brito

Well, like Ben told me, people are confused.

OK, I'll try to make myself more clear.

OK

When Domain Admin mount the user's shared then he'll execute the
"arbitary code".

This isn't true. Or at least it needs clarification. Let's say that you have
a share, \\evilserver\nastytrojans. Now I as an admin access that share
somehow. What happens depends on how I access it. "mount" is not a precise
term, as there are many possible ways to access a remote share - you can
assign a drive letter to it or not, and you could browse the share using a
command line (for example, a batch file), or you could use Explorer. So if
you are going to say that something happens when an admin accesses the
share, you have to specify how this is done.

If I do this:

net use \\evilserver\nastytrojans /user:domain\domain admin password

Then nothing happens. I can read the share, and everything is fine.

Now say I go to Explorer, and type in the path \\evilserver\nastytrojans,
then I still read the share and autorun.exe does not run. So now we have two
ways for the admin to access the share where autorun.exe doesn't fire.

OK, now I try the following -

net use z: \\evilserver\nastytrojans /user:domain\domain admin password

and I then browse the new z:\ drive, and again the autorun.exe does not
fire.

This testing is done using a CD that has a legitimate autorun.exe and
autorun.inf, which I have "mounted" in various ways.

Now, I have just tested the exact same thing remotely (while logged in as
domain admin here on my home domain), and I cannot seem to get the
autorun.exe to fire at all (unless I double-click on it). Note that both
systems are Win2k Server at SP1 + various patches. I am certain the domain
controller is an default installation.

Also, for good measure, I have tried:

dir \\evilserver\nastytrojans

from the command line, and again, nothing happens.

So apparently (at least on Win2k), there are several ways for me to access a
share that has an autorun.exe and autorun.inf that I have verified to work
(just popped the CD in and out, it ran), and I cannot seem to get it to work
using every way I know how an admin might access the share.

Perhaps the problem could be specific to NT 4.0 systems, or it could be that
I am missing something. In fact, I just copied these files to a local hard
drive, and it still did not fire. It seems that it only works for removable
media on my systems (and then only when I remove and reinsert the media). I
don't have any NT 4.0 systems currently running on my home network, so it
wasn't practical to do a full test matrix.

I do note that I have NoDriveTypeAutoRun = 0x95 set in HKCU (I didn't change
this myself). I don't recall exactly what this implies (perhaps Jesper has
this info handy). Apparently, even if the poor admin is indeed stupid, he is
safe from this attack if he happens to be running Win2k.

If I am missing something here, corrections are quite welcome.


Current thread: