Malware Analysis In Situ

Preface: I am by no means a "professional" malware analyst, and I'm sure there are easier ways  to analyze samples (including just throwing the following sample at a sandbox). This was more of a live-fire exercise.


Besides drive-by downloads, typically in the form of Exploit Kits, one of the most common vectors for delivery of malware is email. Last week I received a typical message promising to contain deposit slips in a .rar file. Instead of trashing it or uploading it to a public sandbox, I decided to take a peak into the sample's functionality using a variety of techniques. Some of these have been covered in previous articles (Malware Analysis 101 Part 1, Malware Analysis 101 Part 2, Malware Analysis 101 Part 3) while others will be somewhat more advanced. First we'll start with static analysis in dependencywalker and Ida Free. Then we'll move onto OllyDbg. Next up will be behavioral analysis within the analysis VM using Brian Baskins' Noriben.py (and fakenet to emulate a "real" internet connection). Finally, I'll share the final report from malwr.com to see what indicators we may have missed throughout the above process.

Memory Games - Volatility

I had a brief introduction to memory forensics, or rather I was pushed into exploring the topic after an interesting conversation with Micrmsoft's own Allison Nixon.

Allison had come across a malware sample that was thwarting VM runtime execution and static code analysis. It was evident after IDA began to loop on a large block of code that this particular sample was packed. This was confirmed with a quick strings search. Besides the Visual Basic ASCII strings, there was no means by which to analyze this sample without patching out the encryption function. Unfortunately, neither of us is at a point where we can handle that just yet so we threw some ideas around. Prior to roping me in, while closely observing the sample (Redacted), she discovered the means by which the VM detection was functioning. After removing the registry entry that was observed (more info to come in a blog from Allison) the sample successfully executed and the VM was infected!

With the sample active in a controlled environment, I suggested that a memory snapshot of the VM environment could be used to carve a copy of the unencrypted sample for local static analysis. This would allow us to bypass the encryption function of the original sample! The awesome thing about VM environments, and VMware Workstation (http://www.vmware.com/products/workstation/) in particular, is the ability to create snapshots which include a ".vmem" file. This file format is very similar to using dd (http://www.forensicswiki.org/wiki/Tools:Memory_Imaging) to dump RAM from a live system, and thus, the open source Volatility Framework (https://www.volatilesystems.com/default/volatility). After creating taking a snapshot of the infected VM to generate the .vmem file I needed, I fired up SIFT (Freely provided by SANS here) to begin my search for the nastiness.

Malware Analysis 101 [Part 3]

Finally, here's the concluding portion of Malware Analysis 101. Both previous posts can be found here [Part 1] and here [Part 2].

An unexpected weekend project that went very well.

We all have these unexpected projects. This week I was given a surveillance DVR that had seen better days. The primary hard disk had spun a bearing (hehe). It was a system I built a number of years ago for my family. Previously I used the software that came with the capture card, a generic 4 channel bt878 card. The software ran on Windows XP so from the start I never really expected anything long lasting although it did last about 5 years.

Anyways, enough about what it was. I dug up a 4Gb USB flash drive, installed a very basic CenOS 6 install, got x264, FFmpeg, ZoneMinder, MySQL, PHP and Apache and made it a reliable surveillance server now. It does have a 1Tb drive for the video.

I have to say the ZoneMinder software is not anything fancy by first appearance but supports all the features that most expensive commercial solutions offer. I like that it did not require me to install any GUI environment on the device itself. No resources wasted on this build.


[root@cam ~]# uptime
 11:09:56 up 1 day, 23:04,  2 users,  load average: 0.00, 0.18, 0.22
[root@cam ~]# ps ax | grep zm[ac]
12795 ?        S      0:04 /usr/bin/perl -wT /usr/local/bin/zmaudit.pl -c
12931 ?        S     46:47 /usr/local/bin/zmc -d /dev/video0
16011 ?        S    131:08 /usr/local/bin/zma -m 5
16192 ?        S     35:39 /usr/local/bin/zmc -d /dev/video1
16204 ?        S    126:37 /usr/local/bin/zma -m 6
16231 ?        S     35:32 /usr/local/bin/zmc -d /dev/video2
16243 ?        S    120:07 /usr/local/bin/zma -m 7
16309 ?        S     34:22 /usr/local/bin/zmc -d /dev/video3
16321 ?        S    128:12 /usr/local/bin/zma -m 8


 Not bad for an old Pentium E5200 with 2Gb.

-Mathew

Malware Analysis 101 [Part 2]

Now that we've covered the different classifications of the functionality of malicious software, made the distinction between targeting vectors, and summarized how IDS/IPS devices fit into the scheme, its time to move into analysis of malware. In case you missed it, Part 1 can be located here.

Image Source

Approaches:

Generally, analysis of any sample can be broken down into two categories, static and dynamic which further subdivide into basic and advanced:

• Static
• Basic - Examine an executable without viewing instructions.
• Advanced - Code analysis using disassembly tools to view Op Code.
• Dynamic
• Basic - Behavioral observation [Sandboxing].
• Advanced - Code analysis using a debugger to manually control the flow of the program. This technique is used to understand the more complex aspects of a sample which static code analysis may be unable to provide.

Each of the above techniques can be utilized in synchronicity of one another in order to reveal different pieces of information about a piece of software. The goal of analysis is to take these many small pieces of information from multiple sources and form a picture of the nature of the sample.

Basic Static Analysis:

From here on, it is assumed that a sample is readily apparent and available. Finding malware is a whole different can of worms, and a worthy topic for a separate blog post series (maybe in the future). 

With a sample provided, one of the first things that can be done is AntiVirus scanning. The key is to use multiple programs and resources as this increases signature coverage. Siganture variations make a substantial difference in the rate of detection. Fortunately, instead of buying 8-10 host based antivirus products (and pitting them against each other on the same local machine) along with their accompanying subscriptions, several free web services exist which will scan a submitted sample against multiple Antivirus engines. These engines include both signature based detection and heuristic based detection. The most common/popular/wellknown example is, of course, Virustotal.com (which has register free, public, and private API functionality).

Before moving on, a word about the inherent weaknesses of Antivirus software. The two types of detection mechanisms, signature based and heuristic based, have a number of shortcomings. Simple code modifications easily bypass signature based detection, and in this era of updatable malware through network (command and control) communications, the cat and mouse game has become even more fast paced. Heuristic engines have a similar weakness: they can be completely bypassed with new or unusual code. If there is no record to compare a sample against, it is impossible for a heuristic engine to categorize.

Image Source

The image to the right was generated by using VirusTotal's main page to submit a binary retrieved from a domain listed on malwaredomainlist.com. This file is categorized as a generic password stealer, which slots nicely into the "Infostealer" category defined in part 1 of this series. Interesting note: 9/42 AV products detected this sample as malicious, although the ones that did identifity the sample, categorized it similarly [this suggests a commonality amongst their signature designs]. The grey window shows PE32 structural information, which is something we will examine a little later. Sites like VirusTotal and AntiVirus products as a whole are not withoiut their faults: benign files can and oftentimes do trigger alerts [Example being unebootin, packed with UPX which appears suspicious, and does trigger some alerts]. Thus, solely relying on multi-scanner service like this is not going to provide enough information to make an informed decision about the overall nature of a sample. Use the information gained from services like VirusTotal or NoVirusThanks to inform your decisions, not make them for you!

Sandboxing:

Image Source

Sandboxing is a basic, dynamic analysis technique in which a sample is run in an isolated environment: the goal being to "box off" potentially malicious activity from harming a local machine. This is generally achieved through virtualization ex: Cuckoo Sandbox. Sandboxes attempt to mimic common network services in order to monitor the behavior of malware when provided network connectivity. Like antivirus services, there are a number of free, web-based services that provide this functionality if one does not have the means to setup a local environment. By far the most popular is ThreatExpert. ThreatExpert performs automated analysis, and is generally very useful in initial reporting.

Automated sandbox analysis is not without its drawbacks and frequently will fail to give any meaningful output. Some of the issues are as follows:
1) Any sample that requires command line options will not be analyzed appropriately as an automated environment has no way to pass arguments via command line in the course of executing a piece of software.
2) Though network services are simulated, command and control traffic is not. Malware this is reliant on instructions from a remote host may never execute, leaving automated analysis useless.

Provided the sandbox is able to execute the provided sample, a report containing system changes, network connectivity, and basic functionality if generated. ThreatExpert has the added ability to identify some malwre through AV scans, but this functionality overlaps with services previously mentioned. Like the multi-engine antivirus services  the results of automated analysis should not be taken as definitive: the goal of sandboxing is to provide insight into the ways in which a sample may attempt to manipulate a host.

Report Source

Here is an example report for a sample submitted to ThreatExpert in 2010. Though 2010 may be a reltively ancient date at this point, it is a good demonstration of information provided by ThreatExpert post-analysis.  You can see basic summary information of the submitted sample including hash, file size  Aliases as identified by AV products and Time/Date Submitted. Of more interest is the "What's Been Found Field" which summarizes the activity which took place during the run time in an easily readable and understandable form. This information is very useful for understanding the capabilities of a sample, and can provide some insight into the Function Calls that you may see further along in the analysis process. The next section contains File System changes: files added, removed and modified and their names + directories, potentially useful for signature development or manual removal. The final section of note is the Network activity summary. Here you can see that a file was downloaded, potentially provided yet another sample for analysis in the future. You may also be able to infer that the sample submitted has some downloader Trojan Functionality, and is likely to making Windows API calls in order to download this file.

Stay Tuned for Part 3!
[Hashing, PE Headers, Linked Libraries and Functions!]

Newest contributer to this blog

Hello followers. I am a new edition to this blog. My topics will be far and wide due to that being the focus of my interests.

My current project is porting ArchLinux to my newest embedded device, the oDroid. I have a Raspberry Pi, I wanted something with a bit more processing capabilities and discovered the oDroid. Great device.

The status of this project is, as far as I can tell the system is running but no video output from the HDMI output (framebuffer only). I have a 1.7v UART adapter on the way so that I can get the console up and figure out the video issue.

As of last night I've completed setting up a VM on my server that is dedicated to distcc (distributed c compiler) to assist in compiling software on the oDroid. Not that the oDroid is slow but just because time is progress.

In case you've not seen the oDroid, it packs a Cortex A9 quad-core ARM7 at 1.7GHz, 2Gb memory and Mali-400 GPU. A couple other things that make this stand out compared to the RPi is that this has 6xUSB, Audio in, 8-bit eMMC memory option and then a category 10 SD reader. I did spring for the 16Gb eMMC option.

I now have the eMMC running Android on it, one SD card with my ArchLinux progress and a second SD card with Ubuntu. I did manage to get GNUradio compiled under Ubuntu and have been using it with a RTL-SDR receiver.

-Mathew

Malware Analysis 101 [Part 1]

Back in July of 2012 at the Rhode Island OWASP and again in September of 2012 at "The Brain Tank", I was fortunate enough to be allocated 50 minutes during which to speak about a sort of side hobby that overlaps into my normal workflow. Its a topic that really inspired me to look into the Info-Sec industry as a career: that topic is Malware. I find evil things highly entertaining, and what is more sinister than malicious software?

The goal of my original presentation was to provide an overview of basic techniques I use on a daily basis in order to inform my decision making process. Within 15 minutes of receiving a sample (regardless of the form it arrives in!) an analyst needs to be able to determine what action to take. The desired outcome is to categorize the sample as:

1) Benign

2) Suspicious

3) Malicious

With that in mind, I am going to go ahead and skip the first 2 slides, which consisted of an Introduction and an About Me section, and hop right into the meat of my presentation. 

Note: Some of my slides contain 3rd party graphics or images. These will all be linked below the image of the slide.

CVE-2013-0333 - Ruby On Rails: JSON Parser Derailed

Yet another vulnerability Ruby on Rails vulnerability has been patched today.
Official(ish) notification here: Google Groups: Ruby on Rails Security

This time, instead of XML being used to pass raw POST data as an argument to the backend, the problem lies in the JSON (which was originally considered the work around for CVE 2013-0156) parser which transforms JSON into YAML, which is in turn passed through a YAML parser. This leads to a very similar attack, abusing !ruby/hash:ActionController::Routing::RouteSet::NamedRouteCollection, that was previously thought patched in ROR 2.3.x and 3.0.x.

Here's a look at the problem (activesupport/lib/active_support/json/backends/yaml.rb)

# Parses a JSON string or IO and converts it into an object
         def decode(json)              if json.respond_to?(:read)                 json = json.read            end            YAML.load(convert_json_to_yaml(json))         rescue *EXCEPTIONS => e
           raise ParseError, "Invalid JSON string: '%s'" % json

The bold part is important. This is what further encodes arbitrary user input into a format that supports serialization and deserialization of arbitrary data types by the Yaml parser. Once again, this includes reserved Symbols and arbitrary objects.However, instead of a combination of XML and Yaml, JSON converted into Yaml is the culprit.

The fix replaces the Yaml backend (activesupport/lib/active_support/json/backends/yaml.rb), which allowed single quoted ('foo') strings, with OkJson (activesupport/lib/active_support/json/backends/okjson.rb). The fixed versions are identified as: 3.0.20 and 2.3.16. Due to the similarity to the previous vulnerabilities earlier this month, this is likely to quickly be utilized in the wild. Expect probes soon.

Update 1: POC here: https://gist.github.com/4660248

encoded_yaml = yaml.gsub(':','\u003a') 

 [Clever!]

Update 2: Sample of Metasploit Module Code, based on the previous XML/YAML Vuln

1. !ruby/hash\:ActionDispatch\:\:Routing\:\:RouteSet\:\:NamedRouteCollection\n" +                        "'#{Rex::Text.rand_text_alpha(rand(8)+1)}; " +                        "eval(%[#{code}].unpack(%[m0])[0]);' " +                        "\: !ruby/object:OpenStruct\n table\:\n  \:defaults\: {}\n"                yaml.gsub(':','\u003a')

Windows 7/8 ASLR - Not so Much

This commentary is based on the work published and performed by "Kingcope". The original text and PoCs are located here: http://kingcope.wordpress.com/2013/01/24/attacking-the-windows-78-address-space-randomization/

The inclusion of memory protections in Windows 7 (and now Windows 8) was touted as a means to defeat exploitation attempts by:

1) Preventing code execution on the stack [DEP]
2) Randomizing the memory offsets of Programs (and associated DLLs) [ASLR].

While bypassing DEP has been relatively well documented by multiple sources in numerous locations [see: ROP Chains], ASLR has proven a tougher nut to crack. Randomization of the memory space forces an exploit writer to try and predict where in memory to point an instruction pointer that he or she has gained control over. The goal being, of course, to point to an area of memory which contains the writer's arbitrary code.

Current methods for "beating" ASLR include: utilizing browser memory leak bugs or relying on older DLLs that do not have their image bases randomized. Unfortunately, knowledge of a particular memory leak or reliance on outdated third party software are niche* scenarios culminating in the creation of an idyllic attack surface.

That's where Kingcope's research comes in!

The theory presented is fairly simple: DLLs are loaded into memory space as long as there is space available. If no memory (or very little) is availble, the DLL will be put into the remaining memory. But how does an attacker create a situation in which there is no or minimal (and thus predictable!) memory available in which to load a DLL? By utilizing JavaScript in a target's browser to fill memory to the allocated boundary.** When the allocated boundary is hit, a JavaScript exception is raised which causes the exception handler to execute additional code that frees small chunks of memory. The goal is to slowly free small heap blocks and try to add the DLL(s) into memory; when the DLL is successfully loaded, the region (address space) is fixed and predictable, allowing an exploit writer to point an instruction pointer at a fixed location on the heap.

In his example, Kingcope utilizes the Windows Media Player control ActiveX object to illustrate how the previously described method of abusing JavaScript's exception handler can be used to load a DLL into predictable address space.

Now that the selected DLL (The Windows Media Player DLLs, to continue the example) are loaded into a predictable address, execution of shellcode is only an ROP chain away! I won't spoil the rest of the example Kingcope provided [Hint: LoadLibrary API], but suffice to say it is relatively simple to construct an ROP chain by which to execute arbitrary code following a heap spray.

Click the link to view a quick graphic summary.

My GCIA Gold paper was published on sans.org. Also, SANS watermarks

I completed my GCIA Gold paper and it was accepted and published this past week.  Link below:

http://www.sans.org/reading_room/whitepapers/detection/watermarks-prevent-leaks_34087

I wrote it on watermarks and it took me the larger half of the past year to complete.  Boy I really underestimated how difficult it would be. When I read other people's papers I saw a lot of poor grammar and spelling so I didn't take it very seriously and figured I could just knock it out in a leisurely few months.  I couldn't be more wrong.  I spent well over a hundred hours on it, and almost all of the original draft got scrapped.  If you're considering a "gold" level paper for any of the GIAC certifications, be aware it isn't going to be easy.  But when you get it, it's good resume fodder.

I picked the topic of the paper due to the watermarks I noticed on the GCIA practice tests I was taking.  Below are details about SANS watermarks, simply because they were dropped from the paper.  The information was passed along to SANS many months ago so they can act on it if they wanted.  None of this could be exploited in a profitable way, but I found it interesting.

If you look at the monitor at an angle while taking a SANS practice test you can see the watermarks.  On further inspection you may notice it's the exact same number as the exam ID.  You might also notice that the exam ID numbers you get if you purchase multiple tests are sequential.  I collected dozens of numbers from other users and found that this incrementing number is sequential for all users.  You could spawn practice "math tests" to ensure the software worked, and those numbers were also sequential from the same autoincrementing field in their database.  This indicates an inference attack is possible.

Now the purpose of the watermark is most undoubtedly to trace the source of copyright infringement.  The number is unique on a per-test basis and if the test questions were found on p2p networks and the watermark number was carried over, it could be used as evidence against the student that number pointed to.  Since SANS testing costs as about much as a used car, they probably care more about piracy than the average cert vendor.

The problem is that the watermark number is semi-predictable and easily altered.  It isn't apparent that your exam ID is sensitive information and could be used against you as evidence, and I didn't realize it myself when I was asking people for theirs.  If you wanted to frame someone for piracy, it's as simple as asking them for their practice exam ID.

Since the IDs are sequential, you could also spawn many math tests and infer someone else's exam ID numbers when they purchase one.  example:

Exam ID - description
1 - my math test
2 - my math test
3 - my math test
4 - Other person's practice test
5 - Other person's practice test
6 - Other person's exam
7 - my math test
8 - my math test

On my account I would notice a gap between 4 and 7 in my math test IDs and I would know that someone purchased a set of three tests(which is how it goes when they buy the full training, afaik) and #4 and #5 are the practice tests.  Then if I was an awful person I could insert a "4" watermark and release the test question into the wild.  This is a very hit or miss way of framing someone because their practice test is most likely for a different certification than your test question and you can't tell.

Aside from that, one could also infer purchasing statistics from this autoincrement field.  By spawning math tests over time, one could infer how many tests are purchased by observing how many exam IDs were generated by other people.  clusters of 3 are most likely full training purchases, and 1 indicates a single test purchase or a math test.  The math test function is rather obscure on their website and I think it's fair to say that it's rarely used.  SANS doesn't release any information(afaik) about how many tests or trainings are purchased- only how many students pass.  This information isn't very profitable but it is not public either.

Now with all of that said, the real core of this weakness is that they're using their autoincrement field for something important.  It's a convenient field to use because you know it'll be unique and it's always going to be an index and easily searchable.  But it will always be weak to inference attacks, and that class of attacks is very hard to protect against because most of the time it isn't obvious what you could discover with that data.

This attack was inspired by an inference attack I found/reported against a video game years ago.  The account ID was autoincremented and easily obtainable so I could infer secret data like account age and some overall userbase statistics.  In the context of that game it was useful for cheating, so beware of using that field.

And if you ever plan to do evil stuff with this knowledge, this is all i have to say to you.  Spawning tons of math tests on sans exam portal will get you noticed.

JavaScript Anti-Automated Detection

Yesterday, I came across a relatively rudimentary webpage attempting to exploit a vulnerability in Microsoft Internet Explorer. The particular vulnerability in question is defined in CVE-2012-1875 and is identified by Microsoft in MS12-037. Excellent coverage of this exploit in the wild was posted by AlienVault Labs http://labs.alienvault.com/labs/index.php/2012/ongoing-attacks-exploiting-cve-2012-1875/

Though hardly cutting edge now (a fix was issued in June of 2012), I was curious about one of the sections of code. Following the ROP techniques used to bypass Windows Vista (And later) DEP [Data Execution Prevention], there is a section of code, a "Trigger" that looks like the following [Code follows the Break]:

Update on CVE-2013-0422, The Aftermath

Oracle has officially released Java 7 update 11 which addresses one of two vulnerabilities highlighted in CVE-2013-0422.

The reflective (invoke) API vulnerability (introduced in Java 7) has been patched, and it has come to light from posts to the Full Disclosure mailing list that this particular vulnerability was introduced due to an earlier, incomplete patch.
Full write up here: More details on Issue 32 and Oracle's 'fix' for it

The initial confounding information released by Immunity Inc stating that JRE6 could be effected by the "com.sun.jmx.mbeanserver.MBeanInstantiator.findClass" has been refuted by the very same firm after further analysis. This leads to 3rd party substantiation of Oracle's claim that only JDK and JRE 7 update 10 and earlier are affected.
A summary of Immunity Inc's findings:

After further research we found that although theMBeanInstantiator code is the same in both versions, JDK/JRE 6 cannot be exploited.

Original analysis [Warning, PDF!]: https://partners.immunityinc.com/idocs/Java%20MBeanInstantiator.findClass%200day%20Analysis.pdf
Post Patch Analysis: http://immunityproducts.blogspot.com.ar/2013/01/confirmed-java-only-fixed-one-of-two.html?m=1

Patching the reflective API vulnerability cuts off the vehicle for exploitation of the MBeanInstantiator.findClass vulnerability. However, Immunity Inc indicates that restricted classes can still be called. This calls into question the overall security of the trusted class model utilized my Java 7. It remains to be seen if another vehicle for exploitation will be found, and if so, how soon it will be utilized.

Oracle's official Security Alert can be found here: http://www.oracle.com/technetwork/topics/security/alert-cve-2013-0422-1896849.html

Two big takeaways here:
1) JDK and JRE 6, 5.0 and 1.4.2, and Java SE Embedded JRE releases are not affected.
2) The MBeanInstantiator.findClass vulnerability is still present, but currently there are no known alternative methods to utilize this bug.

Off the Rails: A blurb about CVE 2013-0156

Its been quite a January so far, and we aren't even half way through!

Earlier this week (Prior to the January 10th, 2013 Java 0day), another major remote code execution vulnerability was disclosed which effects Ruby on Rails implementations 2.x and 3.x.
Summary Here: http://threatpost.com

So far, a Metasploit module and POC exploit code have been released. The SQL injection vulnerability is nicely summarized here:
 !ruby/object:Arel::Nodes::SqlLiteral 

A trio of vulnerabilities exist, JSON, XML [Parsing], and Remote Code Execution. For more information see the link here:  http://ronin-ruby.github.com/blog. The root of these vulnerabilities lies in the way in which Rails parses YAML input (user-controlled).


If you want an in depth break down of the functionality of the RoR vulnerability:
http://www.insinuator.net/2013/01/rails-yaml/

For a tl:dr
1. The XML case calls Hash.from_xml() passing the raw POST body as argument
2. The YAML string “”— !ruby/object:A\nfoo: 1\nbar: 1\n” will create an object instance of class A and set the object attributes @foo and @bar to the value 1. This means that an attacker can create instances of all classes defined in the targeted Rails application.
3. ^^ All basic Ruby classes are included, meaning this vulnerability is quite broad.
4. The YAML parser used by Ruby supports the serialization and deserialization of arbitrary data types. This includes Symbols and also arbitrary Objects.
5. SQLi (in the form of the arel object) is probably only the first of many different ways to exploit this, as it is essentially remote code execution.
6. Validate input. Seriously.

Mitigation

Upgrade Rails to one of the following releases: 3.2.11, 3.1.10, 3.0.19 or 2.3.15.

New Java 0-day - 1.7u10

Following 4 months of relative quiet from the Java front, today marks the appearance of the first 0day since CVE-2012-5088, which was patched by Oracle in October.

Preliminary reports from multiple vendors indicate this exploit shares some characteristics with CVE-2012-5088, according to Trustwave's SpiderLabs:

On top of using java.lang.invoke.MethodHandle.InvokeWithArguments() from CVE-2012-5088, the attacker smartly takes advantage of MBeanInstantiator in order to get a reference to a restricted class from a trusted caller (MBeanInstantiator is trusted). [http://blog.spiderlabs.com/2013/01/first-java-0day-for-the-year-2013.html]

Alienvault has released a screenshot of the exploit in action against a fully patched version of Java. Their conclusions mirror those of the preliminary findings from Trustwave: http://labs.alienvault.com/labs/index.php/2013/new-year-new-java-zeroday/

Brian Krebs reports that this exploit has already been included in Pauch's Blackhole and Cool Exploit Kits as well as the Nuclear Exploit Kit. The SANS ISC recommends disabling Java if possible. Fortunately, a feature to disable the browser plugin was conveniently rolled into Java 1.7u10.

For more information, including ISC's recommendation and primary sources, follow the link here http://isc.sans.edu/diary/Java+is+still+exploitable+and+is+likely+going+to+remain+so./14899

Update 1: Exploit code has been published here: http://pastebin.com/raw.php?i=cUG2ayjh

Update 2: CVE candidate has been added: CVE-2013-0422. The exploit has also been ported to Metasploit.

Update 3: Lightly Commented Exploit Code Sample

Click to Embiggen