Steve Riley on Security

Formerly of Microsoft's Trustworthy Computing Group.

More on Autorun

More on Autorun

  • Comments 24
  • Likes

Last month, in my post "Autorun: good for you?" I described why I believe you should disable Autorun on all computers in your organization. I also explained how you can do this for XP and Vista computers.

Well, it turns out that Windows will override this setting if you insert a USB drive that your computer has already seen. I received an email from Susan Bradley that links to an article on Nick Brown's blog, "Memory sitck worms." Nick mentions the MountPoints2 registry key, which keeps track of all USB drives your computer has ever seen. I'll admit, I didn't know this existed! I'm glad Nick wrote about it, though.

Nick also includes a little hack that effectively disables all files named "autorun.inf." Interesting, but something in me prefers to make Windows just plain forget about all the drives it's seen. So now I will amend my instructions. In addition to what I wrote earlier, you should also write a small script, and execute it through group policy, that deletes the following key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

When I searched for it in my registry, I also found a few others, so maybe you'd want something that would search through the registry and delete them all, although I don't know if such a tool exists -- I've never had a need to look for something like that.

Comments
  • PingBack from http://blogs.technet.com/steriley/archive/2007/09/22/autorun-good-for-you.aspx

  • Hi Steve - Nick Brown here, the author of the above-linked blog entry.

    I'm skeptical about the impact of systematically deleting MountPoints2.  In our experience of fighting memory stick worms, this is necessary but not sufficient.  We are not sure what *would* be sufficient, but on general principles, if there's one unknown registry key (googling for "MountPoints2" is remarkably unproductive), I would not be too amazed if there were others.

    Turning off Autorun using IniFileMapping is instantaneous, reversible (OK, you need to reboot after you delete the entry), and has precisely definable side-effects.  For a busy system administrator, that's three for three...

    Nick

    PS: Can you change my name from Mike to Nick please? :-))

  • I don't know if such a "tool" exists, but it should be pretty easy to do with a line of powershell...

    that is, assuming it is "safe" (=does not crashes or breaks anything else... since I see it contains also the "C" drive for example...) to delete everything under MountPoints2....

  • In areas where this kind of attack is relevant, I have applied a GPO that uses Software restriction policies to block execution of any file from any drives that have a drive letter except C:

    It has worked really well so far!

  • When we were still trying to get "deleting stuff under MountPoints2" to work, I wrote a BAT file to do it, on a remote PC, and without deleting the keys for drive letters A-F, "in case they actually do something".  It uses REG.EXE and REGDMP.EXE, and a bit of FOR /F parsing.  (I'd love to know what the "CPC" key is for.  It has its own 5 or 6 {hexmumble} subkeys.)

    Actually I don't think it's a big deal to delete the whole MountPoints2 key.  It's per-user, so the first time a user logs on it gets default values for C (etc) anyway.  We treat per-user registry data as extremely disposable.  But again, as far as we can tell, deleting MountPoints2 is not sufficient for all worms of this type.

    Unfortunately, per-user registry data is harder to keep track of in a big network environment.  People create local accounts on the PC, their roaming profiles get reset, etc etc.

    Something else to worry about: if you have a big shared drive with 500 people accessing it via a mapped drive letter and just one person's infected memory stick creates an Autorun.inf file in there, you can have 500 copies of the virus running by close of business.  Panagis' idea looks good to block that too, as long as this shared drive is not also hosting software...

  • Nick - I am running McAfee's VirusScan on all my servers and it has a rule to block the creation of 'autorun.inf' files remotely, meaning any clients connecting to a shared drive on my servers cannot create such a file. You can use that ability to block other file types or you can use FSRM (assuming you're running R2 on your servers) to block file types as well.

  • >>a rule to block the creation of 'autorun.inf'

    >>files remotely

    That sounds like a nice feature.  However, we don't run commercial anti-virus software on any of our PCs or servers (apart from real-time checks of incoming content at the SMTP server and Web proxy ), so that's not an option for us.

    If I get time to develop my blog, its major theme will be how you can (and/or why you should) run a big Windows network without anti-virus software.  I've been developing my own solutions since 1991 and in that time, I think I can honestly say that on our network - now 1800 PCs - we have never lost a single document to malware.

  • While there's been discussion of the weaknesses of NoDriveTypeAutorun, I haven't seen any critiques of NoDriveAutoRun. Setting this to 0xffffffff appears to obviate the need for iterating over MountPoints2 (thus making application much easier).

  • This is an interesting thread...can someone explain how deleting the MountPoints2 keys from a user's profile affects the spread of USB worms...

    Thanks,

    Harlan

  • >can someone explain how deleting the MountPoints2

    >keys from a user's profile affects the spread of USB

    >worms...

    The deleting of MountPoints2 keys doesn`t help in any situation, for example, in a case when the worm is already in memory.

    In my situation I have my computer at work infected with some virus because it doesn`t let me to open any drive by double-clicks. Though I deleted MountPoints2 subkeys 2 or 3 times, after rebooting everything comes back - some MountPoints subkeys with Auto key in everyone which is calling bittorrent.exe or activexdebugger32.exe. I tried to run fresh Panda Internet Security 2007, but it didn`t find anything at all.

    Cloud anybody tell me what I should do in my situation? I am sure one day I would discover that my projects disappeared and my disk is completely damaged by viruses!

    Thanks!

  • Surely time itself has warped and it's suddenly April 1st. Come on, if you read the following, wouldn't

  • I am experiencing the same problems with a virus that is running under the name sevice.exe     It is called by autorun.inf and it infects every drive it comes in contact with. So the virus is being renamed or issued by some people, it is a very nice thread about what to do to stop it. There are several places in all your physical drives where it is such as

    c:/windows/system32/your virus.exe

    c:/program files/common files/Microsoft Shared/MSInfo/yourvirus.exe

    but you better do something to protect you computers or next time you stick your infected drive into your computer, you will have to do it all over again.

  • found this site, when searching for "registry mountpoints2".

    Since few months i have some weird errors, when clicking on Drive P: (network drive).

    The error is something with xiao.vbs (some kind of trojan or whatever)

    Tried all kind of removers (like ATF-cleaner, Look2me destroyer and smitfraudfix). But nothing helps, mountpoints2 still comes back.

    And funny thing is, no one can find the xiao.vbs on network drivers/ usb drivers and my local computer.

  • I just found a 0-day worm that puts 'smss.exe' into a "system32 " (note the space after the system32). It creates this 2nd folder and then intercepts the exefile key so when you delete it, you can't run any .exe files... Nice. I was able to successfully disable & remove it. BTW it has a cute pink squid as an icon and is 416K in size. The normal smss.exe is about 50K.

  • I deleted Mountpoints2 in my registry and BAM! In an instant I was able to normally get into my Local Disk E without an error message.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment