jsunpack blog

New jsunpack server!

2011-10-03T08:43:00.001-07:00

I brought a new server online for jsunpack.jeek.org over the weekend and everything should be operating normally now. I expect this server to last about 6 months based on the volume of past submissions. I hope you enjoy it!

Blake

The jsunpack website is accepting submissions again

2011-06-15T15:56:00.000-07:00

I removed the ability for people to submit URLs and files to http://jsunpack.jeek.org/, partially due to abusive submissions in late May. I brought the submissions interface back online today with some changes to help prevent further abuse. Please let me know if you encounter any sort of problems.

Temporary downtime for jsunpack website

2011-04-01T07:56:00.000-07:00

The website for this project jsunpack.jeek.org has been down for the past 2 days because I was moving it to new hardware. The old hardware was running ESXi and caused all virtual machines to lock up repeatedly. While I was moving it the site was completely offline but I'm happy to say its back now!

Keep in mind, if you had been running jsunpack-n locally then you wouldn't have experienced any problems (thats software is freely available and that is what the server is running).

[off topic] I've seen a few people do a great job in downtime situations, none of which I did because this whole project is running from a single virtual machine with limited resources. For instance, when Netflix was recently down they acknowledged the problem and credited subscriber's accounts. When another site was down, they played a funny "Doh!" error message video from the Simpsons. In yet another case, DreamHost apologized and wrote a funny blog about it (note: I do not use or endorse DreamHost but I do read their blog). Some quotes from that post:

"I’d like compensation. You’ve earned it! You pay for 365 days of service – not 364.375"

"Why didn’t you call me? We would have loved to reach out to every customer individually, but with over one million domains hosted, that could – quite literally – have taken all year. We’d have loved to email you too, but well, we had this little network problem blocking emails."

Jsunpack Website Database Optimizations

2010-12-22T11:08:00.000-08:00

I just published some new optimizations for the jsunpack.jeek.org database. This should dramatically improve the performance of the website.

Contact me if you need anything related to this update. I removed the search functionality (and associated RSS feeds) because that was one of the most performance intensive features on the database. While this type of function is still possible, I think I'll either have to limit terms that may be searched for or build a separate index structure so that it is better optimized.

[edit] In case you are curious, the jsunpack database has 186,459 submissions and 686,232 evalated scripts and URLs since 2010-01-29 14:17:36. This year was pretty active for web exploits. The majority of the submissions to jsunpack were publicly released in one of the RSS feeds with 167,356 submissions over this year. The opposite of that were the entries where users wished those submissions to remain private totaling 19,107 submissions.

Importing jsunpackn.py as a python library

2010-12-01T07:14:00.000-08:00

In case you were wondering, it *IS* possible to import jsunpack-n from your own python programs. The benefits include:
1) greater control of the options (that you'd normally specify on the command line or in the configuration file)
2) control of the output in their native data structures (no more $ ./jsunpackn.py file|grep -E "suspicious|malicious" >> readme.log)

Check out the new exampleImport.py script, now available in the project's google code svn site.

If you review the main code for the exampleImport.py script, you will see that it defines a function that allows you to directly pass JavaScript... for example:
main('eval("var a=123;");')

Then you can see these loops in the main function:

        for type,hash,data in js.rooturl[url].files:
            print 'file              type=%s, hash=%s, data=%d bytes' % (type,hash,len(data))
        for printable,impact,msg in js.rooturl[url].msg:
            print 'output message    printable=%d, impact=%d, msg=%s' % (printable,impact,msg)

The point of this post is to show you that you can directly access these files and perform decoding using jsunpackn.py as a python library. If you need examples for how to operate on more than just JavaScript as the exampleImport.py shows, then try looking at the main function of jsunpackn.py, and you'll see how I process the various different types of input.

Cheers,

Jsunpack through a proxy

2010-08-12T08:35:00.000-07:00

I have a special guest blog from http://twitter.com/malc0de today. He submitted some proxy suggestions for jsunpack-n, which I've added to svn. Here is a description of the features. Thanks for the great new feature ideas, keep them coming! also check out his site at http://malc0de.com/ if you haven't already.

In todays threatscape the ability to forward requests through proxy servers can come in handy in certain situations. Generally speaking a majority of drive-by exploit kits in the wild have logic built in that does not allow for duplicate requests originating from the same IP address. Since I primarily use jsunpack-n to investigate potentially malicious domains and am one of the many jsunpack-n users out there I thought it would be useful if jsunpack supported proxies. At first diving into the 1300+ lines of python was intimidating but after a few hours I had a working prototype that I sent to Blake who later modified (improved) and added to the svn repository.

Once you have checked out a new copy (https://code.google.com/p/jsunpack-n/source/checkout) you will notice two additional options:

-p PROXY, --proxy=PROXY
- use a random proxy from this list (comma separated)
-P CURRENTPROXY, --currentproxy=CURRENTPROXY
- define a single proxy

The first option -p allows you to specify a comma delimited list of proxies of which jsunpack will randomly pick one.

Example
./jsunpackn.py -u "www.google.com" -p 189.3.47.146:3128,187.49.68.11:8080,187.45.175.66:3128

URL fetch www.google.com
[fetch config] random proxy 187.45.175.66:3128
[fetch config] currentproxy 187.45.175.66:3128

The second option -P allows you to define a single proxy.

Example
./jsunpackn.py -u "www.google.com" -P 187.45.175.66:3128
URL fetch www.google.com
[fetch config] currentproxy 187.45.175.66:3128

For your convenience a perl script called getCurrentProxies.pl can be found in the tools directory. This script interfaces with a popular website named malwaregroup.com to retrieve an updated list of active proxies. The IP’s are printed out in a comma delimited format accepted by the new -p option.

Example

./tools/getCurrentProxies.pl
193.255.184.210:3128,193.110.187.209:3128,193.105.240.32:8080,190.200.151.23:8080,189.84.116.88:3128,189.3.177.146:8080,189.3.150.32:3128,189.3.47.146:3128,187.49.68.11:8080,187.45.175.66:3128,187.23.145.82:3128,187.0.80.180:3128,180.149.49.114:8080

I enjoyed working on this project with Blake and would like to take this opportunity to encourage others to contribute their ideas. Jsunpack has come a long way since it was first introduced and continues to remain one of my favorite tools.

I need your encrypted PDF files

2010-07-02T13:40:00.000-07:00

I just released some major improvements to jsunpackn today in version 0.3.2c. The main new feature is the ability to parse encrypted PDF documents. One problem though, the output isn't quite perfect. For example, see one of these encrypted PDFs where jsunpackn extracted JavaScript:

http://jsunpack.jeek.org/dec/go?report=2ed7fde3fbc8d7c2857bfd69878f78e3b008518e
http://jsunpack.jeek.org/dec/go?report=1873b5faccc1574ce065f6528e85e64464e4b09c

Note, how certain characters in the output are not quite right, therefore the JavaScript decoding doesn't go beyond the first stage. If you find any PDF files with the string "/Encrypt" in them, please let me know, I'd like to test them to see if I can improve the parsing further. In the process of supporting the /Encrypt tag, I was able to build a testbed and was able to detect 20 new PDFs in my testcases with the new parsing!

I would like to thank Dave Touretzky (from the Computer Science Department and the Center for the Neural Basis of Cognition at Carnegie Mellon University) for posting details of encrypted PDFs within his Gallery of Adobe Remedies.

Friday Link Trifecta

2010-06-18T15:02:00.000-07:00

Here are some cool things I ran into this week.

koto's Ultimate String override
koto gave a presentation to a polish owasp meeting describing how to detect and evade jsunpack. He also presents some ways to fix those evasions in Ultimate toString override. Great work!

Paul Makowski's Blog
In this post, Paul uses his hacked sshd (it logs attempted usernames and passwords) in order to track down the tools used against his server. I was investigating some similar tools, so it was great to see this. One of the interesting tools Paul found was a Mac OSX IRC bot. They all seem to have some connection to "trance". I even found some new files "trance.pdf", which isn't really a PDF if you were wondering :)

SWF Disassembler Plug-in for IDA Pro [PDF]
This looks like a great plugin for IDA. If you want to try it with some live samples from jsunpack, monitor this rss feed.

Jsunpack-n update 0.3.2b Custom Spidermonkey and Google Code Subversion

2010-05-20T08:39:00.000-07:00

I now distribute my own modifications to Spidermonkey with the project. This allows you to easily compile it with my preferred modifications. If you want to see what modifications I make, read the INSTALL.spidermonkey or INSTALL.spidermonkey.shellcode files.

You can now get the source code for the project from https://code.google.com/p/jsunpack-n/ (instead of my website).

Updates 2010-05-20 version 0.3.2b

1) added INSTALL.spidermonkey.shellcode instructions. This adds improved shellcode detection.
2) updated jsunpack class options structure. New options will always use file contents instead of filenames (where possible). Also, rules are now part of the options structure.
3) socket defaulttimeout now part of jsunpack class (it was global before). If you import jsunpack, make sure to set a timeout on your own.
4) you can use jsunpack.version to get the current version string
5) new performance option (-f "fasteval") for disabling non-critical features in favor of performance
6) fixed a bug in redoevaltime option affecting performance of malicious scripts
7) fixed a pdf parsing bug for /Page related to testcase samples/pdf-numPages.file

Three days ... of bug hunting (and a new release) I blame python

2010-05-05T15:21:00.000-07:00

This is the worst bug related to the project that I've encountered so far and I just spent a few days trying to find what went wrong... Well, I just found and fixed it!

I'd highly recommend NOT using version 0.3.2 because of this bug, version 0.3.2a has only a few new features but YOU SHOULD UPGRADE immediately if you use 0.3.2. Version 0.3.2 is the only version affected by this bug and it prevents jsunpack-n timeouts from killing the SpiderMonkey process (if the script never terminates).

Updates 2010-05-05 version 0.3.2a
1) implemented this.numPages, getPageNthWord, and getPageNumWords
2) fixed bug (python 2.6 only) for log_ips functionality
3) fixed REALLY BAD performance bug related to python dynamic types. This is why type checking is a good thing and why python sucks at it. Most of my python bugs are because I redefine another variable, wipe out a loop variable, or otherwise use a bad type.

Jsunpack-n update 0.3.2: Major Updates

2010-04-30T12:53:00.000-07:00

Happy Friday! ;)

I added LOTS of great new features in this release. Here's the CHANGELOG.
Sorry for the Friday update, it seems like I've still got lots of work left to do still!

Updates 2010-04-30 version 0.3.2
1) added configuration command line option -c which replaces all former directories and filenames specified on the
command line, now uses options.config instead
2) added command line option -J option to disable any decoding
3) added document.title parsing
4) js.files is now part of urlattr/rooturl structure
5) handle referrers in building the tree
6) detection now can be performed against full decoded stream (ie. between different decode levels on the same decoding)
don't use decodedOnly filter in the rule if you expect to match on the full decoded stream
7) ipaddress logging upon detecting malicious contents with a 'options.config' option
8) make PDF headers available to future decodings
9) added navigator.plugins enumeration in pre.js
10) support getAnnot calls (note: previously getAnnots was supported only)
11) html parsing customizable configuration file (see htmlparse.config file)
12) fixed a bug in htmlparsing related to NULL bytes
13) added pdf app.plugIns enumeration
14) other bug fixes

Jsunpack-n update 0.3.1e: Bug Fixes Release

2010-03-18T12:39:00.000-07:00

I released an update to jsunpack-n that fix some bugs and add some new features. The detection updates for this release mostly involve improvements in PDF parsing. Some jsunpack users suggested that I add better detection capabilities for PDF files and content within deflated streams. That is not yet available, but I am planning to make those updates available in a future version.

Updates 2010-03-18 version 0.3.1e
1) added LZW and RunLength decoding to pdf.py
2) fixed pdf.py so that streams that fail to decompress are not output
3) rooturl is now a member of jsunpack objects (to better support threading)
4) js.files now contains three entries [filename,origin,contents] (contents is new)
5) new command line argument -Q (for Quit-outputting-files), incase you plan to use the output from a python script
6) updated rules

Executables Feed for Malware Analysis

2010-02-17T08:04:00.000-08:00

Someone sent me an email wondering why I don't continue to publish a feed for recent executables (like the older version of jsunpack), and I do! I thought the answer could be useful to others wanting to perform malware analysis so keep reading if that interests you.

You can perform a search with the term "executable" under the recent submissions of jsunpack.jeek.org. These are not guaranteed to be malicious, but there is a high likelihood that most of them are malicious. Many of the URLs are from decoded javascript or environment variables pointing to executables.

Here are the links for you,

Search http://jsunpack.jeek.org/dec/go?list=1&search=executable
RSS Feed: http://jsunpack.jeek.org/dec/go?search=executable&list=search

For each executable you find, you may choose not to download it from the actual server (the server may not offer the file anymore). In that case, you can download the executables from jsunpack instead.

Each link in the RSS feed contains a link to the decoding report like this:
http://jsunpack.jeek.org/dec/go?report=d6257c1932efa718fe424fbdd92ae7e0779aa9df

If you replace the "go" part with "download" you'll get all the files created and the executable file.
http://jsunpack.jeek.org/dec/download?report=d6257c1932efa718fe424fbdd92ae7e0779aa9df

Please enjoy and send me any reports for malware that you analyze and I'll post them on the site.

Shmoocon Recap and Presentation Slides

2010-02-09T06:57:00.000-08:00

Shmoocon was great! At the Own the Con talk hosted by Bruce Potter, the event organizer, he explained one of the reasons for limiting the con to 1500 people given that his house, living room, and garage become full of swag. He also mentioned that at the open bar on Saturday night Shmoocon attendees created a bar tab of $28k!

He also said attendance was great given that we just experienced the worst snowstorm in Washington DC's history. (about 95 percent attendance)

Thanks to Bruce, his wife, and all the volunteers for putting on another awesome Shmoocon this year! I put the slides from my presentation online for those of you that couldn't make it:

http://jsunpack.jeek.org/BlakeHartstein_Shmoocon_Jsunpack_20100206.pdf

Shmoocon and New Releases

2010-02-04T12:00:00.000-08:00

Hi everyone,
If you make it to Shmoocon this weekend I'll be presenting jsunpack on Saturday at 10am. Also, check out the improved web interface!

See you there!
Blake

Jsunpack-n update 0.3.1c: Decoding and Functionality Updates

2010-01-08T08:20:00.000-08:00

I just released a new version of jsunpack-n, this version has some great new features! First off, it handles new decoding techniques like PDF annots. What are Annots you ask? Well, its just like getElementByID but for PDF files. This allows exploit authors to store arbitrary content within a PDF file then access that content directly from javascript using the getAnnots() function. Similarly, attackers have been using the "this.info.title" variable also! This version of jsunpack-n supports both of these new obfuscation techniques.

I also added many improvements to PDF decoding and added a few new detection rules for new exploits. You will find that I've also added many new sample-* files for jsunpack-n users to test with and see what jsunpack-n is capable of.

IDEA: I've been considering creating an svn repository to store high volumes of pcaps and malicious samples ... if there is interest contact me or let me know if you would find it valuable.

Updates 2010-01-08 version 0.3.1c
1) pdf improvements
1a) handling and decoding of pdf annots (see sample-pdf-annots.file)
1b) octal-based object decoding support
1c) handling of obfuscation for this.info.title (see sample-infoTitle.pcap)
2) graphing in verbose mode now displays all nodes rather than just malicious ones, increased node limit to 60
3) bug fix for gzip python library to better handle IOError case for 'Not a gzipped file'

Rule2Alert Project Release

2009-12-21T15:25:00.000-08:00

This is an idea I had a while ago and the Rule2Alert project implemented it (awesome work Josh)

Step1. Take a snort rule like this:
alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Snort alert"; flow:to_server,established; content:"|56 24 5a 63|"; content:"hey"; distance:5; within:12; sid:2000000; rev:1;)

Step2. Create a pcap (packet capture file) or network traffic to trigger this rule.
(Mind you certain things like pcre are incredibly challenging to implement)

Why is this useful you say?
I can see many uses -

1) You can test your rules to make sure they work

2) You can determine if overlap exists between one or more different rule (therefore, consider disabling one, or merging the rule into one). This was a goal of one of the public community/EmergingThreats/Sourcefire project that I think has dropped off the radar since it was initially started.

3) You can also test other non-snort Intrusion Detection Engines for known signatures to determine how much overlap exists.

4) An attacker could also use this tool to do some sneaky things. I won't go into much detail here, but leave a comment if you think of anything.

More on the project from "New Project - Rule2Alert" at http://malforge.com/node/22 or get the source code from http://code.google.com/p/rule2alert/

Jsunpack-n update 0.3.1b: Functionality Updates

2009-12-08T11:12:00.000-08:00

Today I am releasing a new version of jsunpack-n that fixes several different bugs and increases the functionality of jsunpack-n.

This release REQUIRES an up to date version of YARA (1.3 or greater), because the rules file makes use of the new rule syntax. If you experience problems compiling the YARA rules, this is likely the reason.

In this release, I added support for lastModified, which attackers have used in attacks to prevent analysis (this will only work if you use a pcap file), since it is part of the network traffic that an attacker sends from a malicious server.

Here is the full CHANGELOG below:

1) rule updates for yara 1.3 rule language
2) fixes in PDF JavaScript parsing
3) improvements to the tree structure, made appending children better
4) cmdline options for logging and temporary directories
5) additions to pre.js and post.js to handle App.eval, String.eval, and better definitions for Adobe version variables
6) handle document.write and document.writeln with multiple parameters

Using a Custom Spidermonkey Version and bug fixes

2009-10-08T11:27:00.000-07:00

I've added instructions within "INSTALL.spidermonkey" showing how to build a js-1.8.0rc1 custom version of spidermonkey with hooked eval() statements. Upon doing so, your decodings will be more reliable and effective!

Attackers can use techniques that change the scope of variables, therefore JavaScript hooks are not sufficient to handle them. When you modify the spidermonkey engine in this manner, you do not change the scope and such cases will continue to decode successfully. I do not distribute spidermonkey with jsunpack-n so you still have some choices in this area, and therefore I did not disable the eval() hooks in pre.js, which this spidermonkey modification replaces.

I've been working much more on parsing SWF files and I have a development version of a Flash Decompiler (for ActionScript code) in the works, stay tuned for that!

From the CHANGELOG:
Updates 2009-10-08 version 0.3.1a
1) bug fixes release
1a) I now distribute an optional gzip.py file (on by default)
This file was built to fix gzip decompression errors (from python2.5), you may not want to use js this if you use python2.6
2) rule detection updates
3) updates to pre.file
4) added instructions for compiling and using custom spidermonkey version INSTALL.spidermonkey
5) (not new) you can type "make clean" to destroy all temporary and log files

Jsunpack-n update v0.3a: SWF parsing and Bug fixes release

2009-09-25T12:10:00.000-07:00

The main new feature in this release is the "swf.py" file, as a standalone you can run it like this:

$ ./swf.py sample-swf-js.file
processing flash file [version 4] (length 115, actual length 115)type=0x9 length=3 name=SetBackgroundColor
type=0x18 length=31 name=Protect
type=0xc length=46 name=DoAction
actionCode 0x83 len(42) ActionGetURL javascript:eval(fV6("ZlY4KGZWMSwxKQ=="))
actionCode 0x0 len(0) unknownAction

tags (with counts) of length=0
End:1, ShowFrame:1
sample-swf-js.file ['javascript:eval(fV6("ZlY4KGZWMSwxKQ=="))']

$ ./swf.py sample-swf-url.file
processing flash file [version 8] (length 1125772, actual length 1125772)type=0x45 length=4 name=FileAttributes
type=0x9 length=3 name=SetBackgroundColor
type=0xc length=65 name=DoAction
actionCode 0x83 len(45) ActionGetURL http://5173vip.seawww.cn/cuteqq.htm (_blank)
actionCode 0x96 len(12) ActionPush datatype[0]=string(text)
actionCode 0x1d len(0) ActionSetVariable
...

As you can see, you can embed both URLs and javascript within Flash SWF files. jsunpack-n uses this module to follow those links and report any obtained information.

The changelog follows:

Updates 2009-09-25 version 0.3a
1) new extraction of URLs/JavaScript from Flash files (CWS/FWS) with swf.py
2) significant performance improvements in shellcode processing
3) bug fixes
3a) fixed tree structure of urls (specific to pcap processing)
when a node could detatch itself from the tree incorrectly

Jsunpack-n update v0.1f: Active Mode and Client version Enumeration

2009-09-18T11:59:00.000-07:00

Attackers frequently try to hide their exploits using version detection. They profile the client software (browser or PDF reader), then only launch an exploit or decode the payload provided you use a vulnerable version. To counteract this, jsunpack-n now uses multiple different version strings and uses the best result.

More signatures and better PDF decoding (pdf.py) with Ascii85Decode support!

I also added active mode (-a), which fetches any [not analyzed] URLs and can be used with URL fetching (-u):

$ ./jsunpack-n.py -u "www.bbkmobile.com" -a
URL fetch www.bbkmobile.com
      (referer=www.google.com/trends/hottrends)
      saved 1647 bytes to ./files/fetch_b8df4c6607205922a41d6448de0dda45d3885951

Active Mode, fetching x new URLs
      [...cut...]

[nothing detected;children=malicious:10] (script) www.bbkmobile.com/
      [suspicious:5] (script) www.crcf.org.cn/logo.gif?b
            suspicious: DecodedIframe detected <iframe
            [nothing detected;children=malicious:10] (iframe) knownsec.7766.org/wwj2/1.htm?
[...cut...]

More info from the CHANGELOG:

Updates 2009-09-18 version 0.1f
1) active fetching of with -a, and evaluation of urls with -u, use both (-u URL and -a) for purely active analysis
2) evaluation of multiple different client version strings:
2a) version enumeration: adobe reader for pdf
2b) version enumeration: IE7, IE8, Firefox, Opera
2c) cumulative evaluation time limits per decoding, and inference of code coverage based upon evaluation time
3) added pdf decoding support for ASCII85Decode and made other improvements to pdf decoding
4) rules updates

Get it here!

Jsunpack-n Update v0.1e: Graphical output, directory output, command line options and fixes

2009-09-02T14:50:00.000-07:00

A new version of jsunpack-n is available 0.1e! This version makes some major improvements in the rule language (using Yara) and allows you to make pretty pictures like this:

One thing I think you will like is the new output ./files/ directory and command line options! Enjoy.

Here is it running with the sample files included in the archive:

$ ./jsunpack-n.py sample-http-exploit.pcap
[malicious:10] hifgejig.cn/nuc/
[impact=5] DecodedGenericCLSID detected F0E42D60-368C-11D0-AD81-00A0C90DC8D9
[impact=10] MSOfficeSnapshotViewer detected F0E42D60-368C-11D0-AD81-00A0C90DC8D9
[impact=5] ObfuscationPattern detected location eval
[impact=10] MSIENestedSpan detected CDATA[<image SRC=http://&# DATAFORMATAS= <SPAN DATASRC= DATASRC= DATAFLD=
[info] find_urls: [javascript var] hifgejig.cn/nuc/exe.php

$ ./jsunpack-n.py sample-pdf.pcap
[suspicious:5] trughtsa.com/
[impact=5] DecodedIframe detected <iframe
[info] [iframe /] trughtsa.com/img/pfqa.php

[malicious:10] trughtsa.com/img/pfqa.php
[impact=10] PDFexploit detected util.printf Collab.getIcon getAnnots Collab.collectEmailInfo spell.customDictionaryOpen
[malicious] identified shellcode of length 1533 (./files/shellcode_9ac3a76f70caef94f2773abc1043e9511d2d0f09)
[info] XOR key [shellcode]: 33
[info] shellcode url [xor] trughtsa.com/img/uet.php
[impact=5] ObfuscationPattern detected eval String.fromCharCode

[malicious:10] trughtsa.com/img/uet.php
[incident:10] [0] requested by 192.168.203.60
[incident:10] [0] origin trughtsa.com/img/pfqa.php
[incident:10] [0] method=GET type=shellcode
[incident:10] [0] filetype MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit

$ ./jsunpack-n.py sample-pdf.file
[malicious:10] sample-pdf.file
[impact=10] PDFexploit detected collab.getIcon
[suspicious] likely NOP sled shellcode variable of length 167
[malicious] identified shellcode of length 1526 (./files/shellcode_da344d16e814e40dec67592bdccdf3ad50e0069d)
[info] XOR key [shellcode]: 33
[info] shellcode url [xor] b35.info/w/who.exe
[suspicious] likely NOP sled shellcode variable of length 2048
[suspicious] likely NOP sled shellcode variable of length 1714
[suspicious] likely NOP sled shellcode variable of length 522574

More from the RELEASE notes:

RELEASE NOTES:
Updates 2009-09-02 version 0.1e

First and foremost, thanks to Victor! (for creating the Yara detection library)
Yara is now a required dependency and the supported format for the 'rules' file

1) improved URL tracking using 'urlattr' class and urls dictionary
1a) new command line option -g, to create a URL graph (only when pcap contains 10 or fewer URL requests)
2) bug fixes for stream reassembly and pdf parsing
2a) stream reassembly now handles all streams when processing a pcap file,
regardless of whether the nids state is in end_states
4) detection of NOP sled shellcode and performance improvements in shellcode processing
(this was one of the performance bottlenecks)
5) new output format with ./files/ directory or -d OUTDIR command line option
6) CVE references are available in the 'rules' file but are temporarily unavailable in alerts

Jsunpack-n Update v0.1d: Great New Features, Detection, and Other Improvements

2009-08-01T14:03:00.000-07:00

The coolest feature in my opinion is demonstrated below using the sample-pdf.pcap file included in the archive:

$ ./jsunpack-n.py sample-pdf.pcap
[suspicious:2] trughtsa.com/
[impact=2] CVE-NO-MATCH (id 9) detected eval
[suspicious] [0]
[info] [iframe /] trughtsa.com/img/pfqa.php

[malicious:10] trughtsa.com/img/pfqa.php
[impact=2] CVE-NO-MATCH (id 9) detected eval
[suspicious] [0]
[suspicious] [0] decoded 25275 bytes
[impact=2] CVE-NO-MATCH (id 9) detected eval
[suspicious] [1]
[suspicious] [1] decoded 12269 bytes
[impact=10] CVE-2008-2992 (id 1) detected util.printf
[impact=10] CVE-2009-1493 (id 2) detected spell.customdictionaryopen
[impact=10] CVE-2009-1492 (id 3) detected getannots
[impact=10] CVE-2007-5659 (id 4) detected collab.collectemailinfo
[impact=10] CVE-2009-0927 (id 5) detected collab.geticon
[impact=3] CVE-NO-MATCH (id 8) detected string.fromcharcode
[impact=2] CVE-NO-MATCH (id 9) detected eval
[malicious] identified shellcode of length 1533
[info] XOR key [shellcode]: 33
[info] exploit_watch append [shellcode] trughtsa.com/img/uet.php
[malicious] [2]
[malicious] [2] decoded 4626 bytes

[malicious:10] trughtsa.com/img/uet.php
[incident] [0] Exploit successful [origin trughtsa.com/img/pfqa.php]
[incident] [0] Exploit successful [victim 192.168.203.60]
[incident] [0] Exploit successful [type MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit]

Notice that each URL is flagged as suspicious/malicious (or [benign] in case you use -v or -V). Check out the "rules" file, which uses a Snort-like syntax to express what exactly you want to detect. For now, it is very simple and only allows pcre-style detection rules, each of which must match for it to classify the URL according to the impact level (-1 is experimental, 0 is benign, 0-5 is suspicious, 6-10 is malicious). If you create some great new rules, post them as a reply to this thread or send them to me and I'll add them to the "rules" file that I distribute with jsunpack-n.

Another cool thing about this version is that you no longer need the pynids/libnids libraries for it to work with non-PCAP files. A lot of people wanting to use jsunpack-n been having issues installing this library so that is the reason I've made it optional. Here is an example of processing a PDF file on the local system (sample-pdf.file is an example file included in the jsunpack-n package for testing that your local installation functions properly).

$ ./jsunpack-n.py -V sample-pdf.file
Processing sample-pdf.file
[malicious:10] sample-pdf.file
[info] [0] found JavaScript
[info] [0] decoded 14602 bytes
[info] [1] found JavaScript
[malicious] analysis exceeded 30 seconds (125644 bytes, incomplete)
[info] [1] decoded 125644 bytes
[impact=10] CVE-2009-0927 (id 5) detected collab.geticon
[malicious] identified shellcode of length 35223
[info] XOR key [shellcode]: 33
[info] exploit_watch append [shellcode] b35.info/w/who.exe
[malicious] [2]
[malicious] [2] no JavaScript

One thing you will notice about this case is that collab.geticon is not visible from the immediate decoding (but is visible via a print "//jsunpack.called collab.getIcon". It also demonstrates the timeout on JavaScript evaluation (the -t command line option). The new command line arguments that are available can be listed via the following:

$ ./jsunpack-n.py -h
Usage:
./jsunpack-n.py [fileName]
./jsunpack-n.py [interfaceName]
jsunpack-network version 0.1d (alpha)

Options:
-h, --help show this help message and exit
-t TIMEOUT, --timeout=TIMEOUT
limit on number of seconds to evaluate JavaScript
(default 30 seconds)
-v, --verbose verbose mode displays status for all files, even if
they are benign
-V, --very-verbose shows all decoding errors (noisy)
-D, --debug (experimental) debugging option to profile memory
usage

Additionally, you can inspect the CHANGELOG file for all new features:
Updates 2009-08-01 version 0.1d
1) determination of whether the code is malicious or benign (see detection.py)
2) better tracking with exploit_watch and ability incident alert for infected IP address
3) pynids 'import nids' library is now optional due to user feedback
4) additional command line arguments -h (help), -t (timeout), -v (verbose), and -V (very verbose)
5) bug fixes and performance improvements
6) added debug option -D, which profiles memory usage (get Heapy from http://guppy-pe.sourceforge.net/#Heapy)

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

2009-07-07T07:02:00.001-07:00

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.

Jsunpack-n update: Automatic shellcode detection and other improvements

2009-06-30T12:29:00.002-07:00

Hey guys,
I just released jsunpack-n version 0.1c. This release introduces JavaScript variable enumeration using a new file "post.js". get the source code here

Check out the new output for the sample-pdf.pcap included in the archive:

$ ./jsunpack-n.py sample-pdf.pcap
[0] decoded 25275 trughtsa.com/img/pfqa.php
[1] decoded 12269 trughtsa.com/img/pfqa.php
identified shellcode of length 1533
XOR key [shellcode]: 33
exploit_watch append [shellcode] http://trughtsa.com/img/uet.php
Match signature [CVE-2007-5659] Collab.collectEmailInfo
Match signature [CVE-2009-0927] Collab.getIcon
Match signature [CVE-2008-2992] util.printf
Match signature [CVE-2009-1493] spell.customDictionaryOpen
Match signature [CVE-2009-1492] getAnnots

undefined variable s fixing

Notice how jsunpack-n identified the shellcode, identified that it uses an XOR key of 33, and determined the URL that the shellcode presumably tries to download and execute. This URL is automatically added to the exploit_watch variable, so that a new alert will result if the victim downloads that file.

Other great features, such as default definitions for undefined variables indicated by the debug output shown above by "undefined variable s fixing".

Yet another feature, evaluation timeouts will prevent infinite loops and scripts that consume too much time/cpu/memory.

Jsunpack-n updates for PDF decoding, improved HTTP handling, dynamic JavaScript and Logging

2009-06-24T12:40:00.000-07:00

Hey everyone,
I released jsunpack-n version 0.1b today (get source code from http://jsunpack.jeek.org/jsunpack-n.tgz). While this code is still being released as alpha/unstable, there are some great new features in this edition.

For example, try to decode the sample-pdf.pcap file included with the distribution and you will notice that I've added not only PDF decoding, but minimal PDF CVE signatures.

$ ./jsunpack-n.py sample-pdf.pcap
decoded 25275 bytes in pdf
[0] decoded 25275 trughtsa.com/img/pfqa.php
[1] decoded 7627 trughtsa.com/img/pfqa.php
Match signature [CVE-2007-5659] Collab.collectEmailInfo
Match signature [CVE-2007-5659] Collab.getIcon
Match signature [CVE-2008-2992] util.printf
Match signature [CVE-2009-1493] spell.customDictionaryOpen
Match signature [CVE-2009-1492] getAnnots

I hope you enjoy all of the new features in this update. As always, I like feedback so send me an email blake_at_jeek_org.

Very Cool jsunpack-n release: JavaScript Decoding on the Network (The Future)

2009-06-07T16:23:00.000-07:00

My favorite tools to decode JavaScript today are for security research and often have too little impact because administrators must find URLs, submit them for research, and it requires significant additional effort. There is no current way to detect threats against a real network using these tools in an automatic manner.

Until now! I started building a tool that is useful to administrators defending networks. The main difference is that it is a completely passive JavaScript decoder to perform Intrusion Detection, by processing network traffic (either an interface or pcap file), rather than URLs.

I built a basic implementation of this concept as a new version of "jsunpack-network" or (jsunpack-n). Some of the benefits of this technique are:

Tracks streams and decodes Transfer and Content encodings of types chunked and gzip.

Completely passive: Don't need to worry about User-Agents, proxies, or other tricks that attackers use to prevent analysis

Detect if an exploit is successful: the system monitors all URLs. It can determine if an exploit would fetch another URL and when the client requests that URL, the system knows that the exploit was successful.

The source code for this project is available from http://jsunpack.jeek.org/jsunpack-n.tgz. Here is an example output using the test file (included in the jsunpack-n.tgz archive):

$ ./jsunpack-n.py sample-http-exploit.pcap
DECODED JavaScript Data
exploit_watch append hxxp://hifgejig.cn/nuc/exe.php

The exploit_watch variable tracks all URLs to track if an exploit is successful and if it is, then the script prints the associated IP addresses and URLs:

print 'Exploit Successful ', tcp.addr, ' from URL ', exploit_watch[host+url]

Since this project is very new, I expect there will be a few issues and therefore you run this at your own risk. I am releasing this code as alpha/unstable, because I think that there is a lot of opportunity to improve it.

Two of the areas that are completely lacking at this point are

signature-based detection

pdf decoding

I am releasing a PDF decoding script with this code, available in the jsunpack-n.tgz archive called "pdf.py"; however, I haven't integrated it with jsunpack-n yet. While this should be a simple task, I'm still testing and improving the PDF decoding, as it now only handles a few of the decoding techniques I'd like it to support.

Please leave me your comments (good or bad), to improve the project. I haven't fully integrated jsunpack's algorithms yet (I will soon, I promise).

Improved Command Line API for jsunpack

2009-06-07T16:07:00.000-07:00

A few weeks ago Jesse wrote an excellent script which is a command line interface for jsunpack.

Last week, one reader made some great improvements to this script by allowing you to upload a local file for decoding. It checks each command line argument to see if a local file exists, then if it does it uploads it. Otherwise, it works in the same way as Jesse's original script and just decodes URLs.


#!/usr/bin/perl

use strict;
use CGI;
use LWP::Simple;
use LWP::UserAgent;
use HTTP::Request::Common;

my $ua = LWP::UserAgent->new;
$ua->agent("jsunpack");

for my $url (@ARGV){
        if (-f "$url"){
                if(open(FIN, "< $url")){
                        $url = <FIN>;
                        close(FIN);
                }
                else {
                        print "warning: ignoring '$url', cannot open file\n";
                }
        }

        my $res = $ua->post(
                        'http://jsunpack.jeek.org/dec/api',
                        Content_Type => 'application/x-www-form-urlencoded',
                        Content =>
                                [
                                        'url'      =>   [$url],
                                        'apikey'   =>   ['exploitme']
                                ]
                );

        if ($res->is_success){
                print $res->content;
        }
        else {
                print "\n\n"."Failed to fetch remote file"."\n\n";
                print "jsunpack"."\n".$res->status_line, "\n";
        }
}

PDF Decoding Bugfix and Open Source from Adobe

2009-05-18T15:46:00.000-07:00

I fixed a bug today, which was causing some of the scripts to fail decoding.
Basically, the JavaScript contained within a PDF file can be part of a special tag where it escapes special characters like (, ), &, \, and so on. The problem with this is that some of the regular expressions would incorrectly show up like this:

(hOPz).replace(/\\&/g,BiY+(13+20-8))
p=p.replace(new RegExp('\\\\b'+e(c)+'\\\\b','g'),k[c])

In those cases, you could make them function correctly by replacing '\\' with a single '\' fixes the problem.

(hOPz).replace(/\&/g,BiY+(13+20-8))
p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])

This bug has been corrected in any future decodings see examples here and here.

I originally thought this might be related to custom Adobe Reader javascript engine, since Adobe uses a custom version of SpiderMonkey. I would still like to integrate Adobe reader's custom JavaScript engine whenever processing PDF files, however, their website says

In some Adobe products, Adobe uses a modified version of the open source SpiderMonkey code. Use of that source is subject to the Mozilla Public License Version 1.1 (the License). You may obtain a copy of the License on the Mozilla website or in the download files.

However, read on and you will see "Download files - Coming soon!". There goes that plan! Anyone at Adobe care to comment on when they plan to release this code?

Command Line API for jsunpack

2009-05-14T10:04:00.000-07:00

Thanks Jesse!
Yesterday, he sent me this script, which takes URLs as parameters then provides the decoding as output. The "api" script does not escape HTML characters whenever the User-Agent is "jsunpack" and the parameter "apikey=exploitme" is set (to prevent accidental accesses of a malicious page).

#!/usr/bin/perl -w
use strict;
use CGI;
use LWP::Simple;
use LWP::UserAgent;
use HTTP::Request::Common;

my $unpackurl = 'http://jsunpack.jeek.org/dec/api?url=';
my $apikey = '&apikey=exploitme';

my $ua = LWP::UserAgent->new;
$ua->agent("jsunpack");

for my $url (@ARGV){
my $req = HTTP::Request->new( GET => ($unpackurl . CGI::escape($url) . $apikey));
my $res = $ua->request($req);

if ($res->is_success){
print $res->content;
}
else {
print "\n\n"."Failed to fetch remote file"."\n\n";
print "jsunpack"."\n".$res->status_line, "\n";
}
}

One feature that could improve this script would have it POST the contents of a local file. Does anyone feel like doing some scripting to extend this?

Using ClamAV on the command line as an automatic unpacker

2009-05-13T21:14:00.000-07:00

A few people have asked me about how exactly the automatic unpacking in jsunpack works whenever it finds an executable. Well, here is the answer.

Take this executable submitted on 05/13/09 as an example:

Sections ( UPX0 UPX1 UPX2 )
File: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit, UPX compressed
Strings:5.com/
Strings:.NET CLR
Strings:UNPACKED %sc%sok.com/
Strings:UNPACKED %sm0%s09.biz
Strings:UNPACKED %sn%s9.info
Strings:UNPACKED c:\43214354.bat
Strings:UNPACKED Us%se%sla/4.0 (compatible; MSIE 7.0; %s; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Strings:UNPACKED http://%s%s
Strings:UNPACKED c:\win
Strings:UNPACKED c:\wi%sft%df44.dat
Strings:UNPACKED %s\jopaxx_%d.exe
Strings:UNPACKED c:\w%sws\t55ft%df44.dat
Strings:UNPACKED %s\st_%d.exe
Strings:UNPACKED %s\yoo_%d.exe
Strings:UNPACKED %s\lim_%d.exe
Strings:UNPACKED c:\windows\%s%s.exe
Strings:UNPACKED reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t REG_DWORD /d 00 /f
Strings:UNPACKED reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t REG_DWORD /d 00 /f
Strings:UNPACKED www.google.com
Strings:UNPACKED 127.0.0.1
Strings:UNPACKED Software\Microsoft\Windows\CurrentVersion\Internet Settings
Strings:UNPACKED tmp_%d_%d.exe
Size: 14848 bytes,
MD5: 78d18e15a1ce15d4869f8db16f4e8642

UPX isn't particularly impressive because "upx -d" works fine most of the time, but this method gets a lot of other packed files too. It uses clamscan (from clamav.net) with --leave-temps, then it looks for URLs, Registry keys, domain names, and anything else interesting it could find in the strings. If it finds the same string in the original binary, then it does not display UNPACKED before outputting it. In this way, the analyst can see if it was really hidden or available in the original strings output.

The --leave-temps method is not perfect, but it has helped me on a number of occassions when I was in a hurry to evaluate the likelihood that a binary was malicious or find the purpose of an unknown binary or large number of malicious samples. In particular, I found it the most useful when it finds an autoit-compiled executable. In those cases, you get the entire autoit script from taking this simple step, which is much easier to quickly analyze.

Jsunpack blog online

2009-05-13T20:37:00.000-07:00

Hey guys,
It's Blake. I finally added a proper blog! Add it to your RSS reader at http://jsunpack.blogspot.com/.
I've been getting some good feedback from users and I plan to add some new features soon. Stay tuned and I'll update you soon on some raw data feeds and command line utilities.

Example of malicious site with rogue anti-virus with javascript exploits

2009-05-13T20:36:00.002-07:00

[23/Feb/2009:11:10:26 -0500] Interesting JavaScript case here -> link, looks like a rogue AV that is either infected or spreading exploits too. Send me ones you decode if you think they are interesting (or if they fail too)

Shmoocon and Presentation Slides (pdf)

2009-05-13T20:36:00.001-07:00

[09/Feb/2009:09:37:18 -0500] Shmoocon was lots of fun. Here is a copy my talk on jsunpack. [02/Feb/2009:11:36:39 -0500] Shmoocon! I'll be speaking about jsunpack on Sunday Feb 8 [more]. Also, brief update - I added meta refresh static crawling to jsunpack this morning.

PDF and SWF decoding in jsunpack

2009-05-13T20:35:00.000-07:00

[29/Jan/2009:11:26:02 -0500] I added PDF decoding to jsunpack several months ago, and I noticed some exploit toolkits using SWF files to redirect to additional exploit pages recently. Please let me know if you like or dislike the new SWF decoding.

Contact me for samples or data

2009-05-13T20:34:00.000-07:00

[09/Jan/2009:00:16:16 -0500] I noticed someone looking for data/logs and they were getting 404 as responses. Please contact me if you would like access to my data - blake_at_jeek.org