Re: AUTORUN.INF Vulnerability

From: Nick FitzGerald (nick@virus-l.demon.co.uk)
Date: Sat Feb 19 2000 - 21:26:15 PST

  • Next message: Fernando Schapachnik: "A DDOS defeating technique based on routing"

    Eric Stevens wrote:
    
    > --introduction--
    > There is a small, but potentially very dangerous vulnerability in Windows
    > (all versions as far as I know, should be 95,98,NT4 SP*, but only really
    > dangerous on NT machines) regarding an autorun.inf file.
    <<snip>>
    
    Eric missed several details in his description.  In fact, his post
    prompted me to reproduce some quick tests I initially tried when I
    first became aware there may be an issue with AutoPlay/AutoRun around
    the time Win95 was released.  Those tests suggested that you can use
    AUTORUN.INF files in the root of hard drives to change the icon
    displayed in Explorer, on desktop shortcuts to the drive, etc, but
    that the OPEN key in AUTORUN.INFs housed on other than CD-ROM drives
    was ignored.
    
    On re-testing I discovered why my original tests failed.  If you use
    the "real" Explorer, AutoPlay events are not triggered when opening
    views of drives.  To run the AutoRun app in an already mounted CD-ROM
    you have to either eject and re-insert it or select AutoPlay from its
    context menu.  Thus, all my earlier testing in Explorer was wasted...
    
    Where Eric wrote:
    
    > When an administrator logs on locally, they may double click that
    > drive (it can be done to all of them), and run the malicious
    > executable, with out their knowledge.  Our little trojan may even
    > continue on to open Explorer to keep the administrator blissfully
    > unaware that they have just been compromised.
    
    you have to read it with the proviso that the administrator uses the
    default My Computer interface and/or standard desktop shortcuts to
    drives.  Die-hard Explorer users might never trigger such an attack.
    
    Eric also mentioned there were two different registry locations
    controlling this, but did not describe them.  You can control the
    drive types that have their AUTORUN.INF files acted upon with the
    value NoDriveTypeAutoRun at the registry key:
    
       HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
    
    This is a binary value with a default of 00000095h (or "95 00 00 00"
    in RegEdit), and is a bit-mask of the drive types used with the
    GetDriveType API.  This default corresponds to AutoRun being off for
    drives of unknown, removable and remote types, and bit-7 is not
    defined according to my Win32 reference.
    
    So, by default, AutoRun *is enabled* for local hard drives.  I was
    not able to find any MS comment on this (though it's a while since I
    looked), but as my earlier tests "failed" to get it to work, I was
    not too concerned at the time...
    
    CD AutoPlay is a related, but different, phenomenon and is (I
    presume) the second registry setting that Eric referred to.
    Appropriately setting the AutoInsertNotification value (a boolean,
    surprise!) for a given CD-ROM's device entry under HKLM\Enum (Win9x)
    or under the NT HKLM\System\CurrentControlSet\Services\CDRom key
    either prevents the driver generating insert notificattions or casues
    the system to ignore them.  This prevents AutoPlay on insert for that
    device (Win9X), or for all CD-ROM drives under NT.
    
    This raised the question "Can you configure "My Computer" to use the
    "real" Explorer interface, rather than the poxy default one?"  Eric
    tells me he has done this in the past, but cannot recall how.  This
    would not be a complete solution, as you still have the possibility
    of desktop shortcuts, which also trigger AutoPlay events when
    double-clicked...
    
    
    ...
    Of course, if anything can install an AUTORUN.INF in the root of a
    local hard drive, this may open an exploit, but then you are talking
    about "any old Trojan Horse attack" and the possibility of code doing
    anything that code can do to the target machine.  The solution to
    that is to ensure trusted users never run untrusted s/w in a
    production environment.  Maybe it is just me, but I would never
    allow general users write access to \ of *any* local drive on an NT
    box anyway, so I don't see this hole as being much of an issue...
    That said, I'll be thinking about adding local hard drives to the
    masked-out drive types in NoDriveTypeAutoRun from now.  Apart from
    this less-than-essential feature, does anything else break if local
    hard drives are excepted from AutoRun processing?  (And if not, why
    is the default should to enable AutoRun for these drives?)
    
    >From memory, a few viruses and/or Trojans have created AUTORUN.INF
    files to change the icon on local hard drives.  I do not recall if
    any of these also attempt to cause programs to run via this method.
    
    Note:  I could not bring myself to enable Active Desktop, even
    just for the duration of this testing.  I *presume* it acts the same
    as the My Computer interface (which is really a "dumbed-down
    Explorer"), but would welcome results from anyone who has tried.
    
    
    --
    Nick FitzGerald
    Computer Virus Consulting Ltd. (NZ)
    Ph/FAX: +64 3 3529854
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:36:20 PDT