Tuesday, July 7, 2009

Zero-day directshow exploits that don't work with jsunpack, an explanation why

Hey guys,
My friend recently was attempting to decode some JavaScript and he sent me the URL to look at. This case reveals that attackers are gaining sophistication because they have a model for blocking researchers from analyzing URLs.

This is the request. If you download the the non-cached contents of that URL you get three iframes (instead of just one):

The new iframes contain the directshow 0-day exploit, which is currently unpatched:

hxxp://guama.9966.org/images/images/chanm.htm [analysis]
hxxp://www.7iai.cn/index.htm [analysis]

More information on the vulnerability here.

This is a case for using jsunpack-n, which you can run from your local IP address to decode traffic. It also highlights the importance of not trusting online tools and performing additional verification. In this case, if you had downloaded the contents and submitted them in HTML form (instead of using the jsunpack cached copy) you would have revealed the 0-day exploits.
Posted by at

5 comments:

  1. faso1983July 9, 2009 at 1:57 PM

    How can this exploit in my web site?

    ReplyDelete
  2. UnknownJuly 17, 2009 at 11:38 AM

    Hello I was trying to run the script against one of the sample files you provided and can't get past this error message. Any thoughts? Thanks for the help and great tool, look forward to playing around with it.

    Error----
    Traceback (most recent call last):
    File "./jsunpack-n.py", line 490, in ?
    main()
    File "./jsunpack-n.py", line 458, in main
    ms = magic.open(magic.MAGIC_NONE)
    AttributeError: 'module' object has no attribute 'open'

    ReplyDelete
  3. jsunpackJuly 17, 2009 at 12:08 PM

    soccerfan81: this seems to be a problem with the "magic" python library. On my system this file is at "/usr/lib/python2.5/site-packages/magic.so".

    However, you might have a different version (newer or older) or a magic.py (or magic.so) in your searchable path.

    Look into your python version, and the version of this magic library. You might instead have a magic.py file within /usr/lib/python__VERSION__/magic.py. Let me know what you find, and I can probably update the code to make sure that your version of the library is compatible.

    ReplyDelete
  4. UnknownJuly 20, 2009 at 4:27 AM

    Thanks for the help/reply. I am running Python 2.4.3
    on CentOS 4.5. I installed the .egg for python-magic, location shown below.
    /usr/lib/python2.4/site-packagespython_magic-0.1-py2.4.egg

    # whereis magic.so
    magic: /usr/include/magic.h /usr/share/magic /usr/share/magic.mime /usr/share/man/man5/magic.5.gz

    ReplyDelete
  5. jsunpackJuly 31, 2009 at 11:07 AM

    soccerfan81: I'm working on an update 0.1d, which will solve your problems with the magic library by making it an optional component. I will release it either tonight or tomorrow.

    ReplyDelete

Subscribe to: Post Comments (Atom)