New Java Attack Rolled into Exploit Packs

New Java Attack Rolled into Exploit Packs:
If your computer is running Java and you have not updated to the latest version, you may be asking for trouble: A powerful exploit that takes advantage of a newly-disclosed security hole in Java has been rolled into automated exploit kits and is rapidly increasing the success rates of these tools in attacking vulnerable Internet users.
The exploit targets a bug in Java (CVE-20120-0507) that effectively allows the bypassing of Java’s sandbox, a mechanism built into the ubiquitous software that is designed partly to blunt attacks from malicious code. Microsoft’s Malware Protection Center warned last week that new malware samples were surfacing which proved highly effective at exploiting the flaw. Microsoft says the samples it saw loaded the ZeuS Trojan, but thieves can use such attacks to install malware of their choosing.
According to posts on several underground carding forums, the exploit has now been automatically rolled out to miscreants armed with BlackHole, by far the most widely used exploit pack. An exploit pack is a software toolkit that gets injected into hacked or malicious sites, allowing the attacker to foist a kitchen sink full of browser exploits on visitors. Those visiting such sites with outdated browser plugins may have malware silently installed, and Java is almost universally the most successful method of compromise across all exploit kits.
According to software giant Oracle, Java is deployed across more than 3 billion systems worldwide. But the truth is that many people who have this powerful program installed simply do not need it, or only need it for very specific uses. I’ve repeatedly encouraged readers to uninstall this program, not only because of the constant updating it requires, but also because there seem to be a never-ending supply of new exploits available for recently-patched or undocumented vulnerabilities in the program.
Case in point: On at least two Underweb forums where I regularly lurk, there are discussions among several core members about the sale and availability of an exploit for an as-yet unpatched critical flaw in Java. I have not seen firsthand evidence that proves this 0day exploit exists, but it appears that money is changing hands for said code.
If you do not need Java, junk it; you can always re-install it later if you need to. If you need Java for a specific Web site, I would suggest a two-browser approach. If you normally browse the Web with Firefox, for example, consider disabling the Java plugin in Firefox (from the Add-ons menu, click Plugins and then disable anything Java related, and restart the browser), and then using an alternative browser (Chrome, IE9, Safari, etc.) with Java enabled to browse only the site that requires it.
The Java latest versions (which patch the CVE-2012-0507 hole) are Java Version 6 Update 31, or Java 7 Update 3, released on Feb. 15, 2012. Please note that if you disable the Java plugin from a browser, the next time you update the program, you may need to disable it again, as Java tends to re-enable itself with every security update.
Update, March 28, 3:48 p.m. ET: Marcus Carey, a security researcher at Rapid7, adds a bit more perspective on the severity of the situation with this exploit. He estimates that upwards of 60 to 80 percent of users probably are not yet patched against this flaw. Here’s what he wrote:

Anytime an exploit, such as one for CVE-2012-0507,  is added to mass exploit kits it goes from being a “hypothetical risk” to becoming a real risk. This particular exploit can be found in the widely used BlackHole Exploit kit.
Based on the Java patching habits of 28 million unique Internet users, Rapid7 estimates that 60-80% of computers running Java are vulnerable to this attack today.
Looking long term, upwards of 60% of Java installations are never up to the current patch level. Since so many computers aren’t updated, even older exploits can be used to compromise victims.
Rapid7 researched the typical patch cycle for Java and identified a telling pattern of behavior. We found that during the first month after a Java patch is released,  adoption is less than 10%. After 2 months, approximately 20% have applied patches and after 3 months, we found that more than 30% are patched.  We determined that the highest patch rate last year was 38% with Java Version 6 Update 26 3 months after its release.
Since this is only about a month since the patch was released (February 15), it’s likely that only approximately 10% of users have applied the patch.

Malware Analysis

Malware Analysis: If you do malware analysis as part of your DFIR activities, check out this post from the System Forensics blog; what I really like about the post is not just that the testing environment is described in a pretty thorough manner, it's also that this is someone doing malware analysis who runs PEView against the file to be tested, rather than simply running strings!  In fact, not only is PEView used in the static analysis of the malware, so is PEiD and Dependency Walker, both very useful tools that are used to great effect in this post to illustrate some important artifacts of the EXE being analyzed.  The post also lists an impressive set of tools used for dynamic analysis of the malware (including CaptureBAT).

The post continues with dynamic analysis of the malware...if you're new to this sort of thing, this is an excellent post to read in order to get yourself up to speed on how to go about performing dynamic analysis.  It also illustrates some of the important artifacts and IOCs that can be derived, not just from analysis of the malware, but in communicating the analysis and results to another part of the IR team.

Some thoughts on what might prove to be very useful...

MFT analysis, particularly with respect to the batch files mentioned in the post.  For example, if the MFT is extracted and parsed, and the record for the tmpe275a93c.bat file still exists (even if it's marked as not in use), it might be a good idea to see if the file is resident or not.  If it is (batch files don't need to contain a great deal of text to be useful), then the contents of the file could be extracted directly from the MFT record.

While it may seem to be providing redundant information from a purely malware analysis standpoint, enabling a greater level of auditing on the system (enabling Process Tracking, for example), as well as increasing the size of the Event Logs, would prove to be useful, particularly for those without the funding or budgets, or the time, for more expansive tools.  When it comes to response, having relevant data is critical...yet, even when shortcomings are identified (i.e., "I really could have used information about processes that had been launched..."), many times we're not able to get the tools we need in order to answer the critical questions next time.  So, if you have come to realize the value of tracking which processes had been launched, but can't get something like Carbon Black, then perhaps enabling Process Tracking on systems and increasing the size of the Event Log files is something of a happy medium.  After all, it doesn't cost anything, and may provide you with some valuable information.

With the transient nature of the processes listed in the post (particularly WinMail), I would think that something like Carbon Black would be an excellent tool to have installed in a malware testing environment, particular the next version (due out next month) that includes monitoring of Registry modifications and network initiations.

There might be great benefit in more extensive Prefetch analysis, particularly with respect to some of the other processes that were created (i.e., WinMail, etc.).  Corey recently took a second look at Prefetch file analysis, and turned up some pretty interesting artifacts, and illustrated how there's more to Prefetch file analysis than just getting the last execution time and the runcount.

Something else to keep in mind when testing malware like this...you need to separate the malware IOCs from the "self-inflicted" artifacts; if you have a sample and not other information regarding the propagation mechanism of the malware, then there will likely be some artifacts that are created as a result of the testing environment, as well as the method used to initiate the malware itself.

Finally, there can often be far more value to malware analysis, particularly from an intel/counter-intel perspective, something that was recently discussed on the MalAnalysis blog.

Resources
MS Free Safety Scanner

Windows support coming to Qubes!

This a project that I have been following closely, and holds a lot of promise.

While the “Qubes 1.0” branch iscurrently in the final development and testing, we have alreadystarted working on the Next Big Feature, which is a support for HVMdomains (hardware, or VT-x virtualized domains). This allows to rune.g. Windows VMs under Qubes. You might be wondering what so specialabout this, if Xen has been supporting HVM domains, and specificallyWindows VMs for a long time, and Qubes uses Xen hypervisor, so whyhaven't we had Windows support since day one?

The are a couple of things that wedon't like about HVM support in Xen (and also in other VMMs), whichinclude: the need to run device emulator (AKA qemu) in Dom0, the needto use crappy VNC, or a similar protocol to access the VM'sframebuffer, or alternatively, the crazy idea (from security point ofview, that is) of using a pass-through graphics for a VM, the lack ofsupport for disaggregated architecture where backends, e.g. networkbackends, run in other domains than Dom0. In fact even the Xen“stubdomain” feature, introduced a few years ago, that wassupposed to be a solution allowing to move the qemu out of Dom0, inpractice turned out to be quite disappointing, as the qemu in thestub domain still requires an accompanying process of another qemu inDom0, somehow negating all the security benefits this architecture issupposed to bring... And not to mention the omni present assumptionthat backends run always in Dom0, hardcoded in a few places in thestubdomain code.

So, we didn't like it and that's whyQubes had no Windows support for long time. But this has now changed,as we have just finished the 1^st stage implementation ofHVM support in Qubes, the way we like it, without any securitycompromises. In our implementation we've completely eliminated allthe qemu remains from Dom0 (it's running in a micro stub domain), thegraphics virtualization fully integrates with our very slim GUIdaemon (we didn't have to modify our GUI daemon at all!), using ourXen-optimized, zero-copy, minimalist GUI protocol, and the networking isalso fully integrated with the Qubes diaggregated networkingarchitecturethat uses isolated domains for all the networking stacks and drivers.Of course, there are still some rough edges, such as no clipboardsupport, and the virtualization is currently in a “per-desktop”mode, rather than in a “per-window” mode, which is used for PVdomains. But, rest assured, we are working on those things rightnow...

This code is currently not public, andthe plan is to release it only after Qubes 1.0 release, either as anupgrade, or as Qubes 2.0. All the dom0 code for HVM support willlikely remain GPL, while any Windows-specific code (agent code) willlikely be proprietary.

An Evaluation of the Google Chrome Extension Security Architecture

An Evaluation of the Google Chrome Extension Security Architecture: Abstract

Vulnerabilities in browser extensions put users at risk by providing a way for website and network attackers to gain access to users’ private data and credentials. Extensions can also introduce vulnerabilities into the websites that they modify. In 2009, Google Chrome introduced a new extension platform with several features intended to prevent and mitigate extension vulnerabilities: strong isolation between websites and extensions,privilege separation within an extension, and an extension permission system. We performed a security review of 100 Chrome extensions and found 70 vulnerabilities across 40 extensions. Given these vulnerabilities,we evaluate how well each of the security mechanisms defends against extension vulnerabilities. We find that the mechanisms mostly succeed at preventing web attacks,new security mechanisms are needed to protect users from network attacks on extensions, website metadata attacks on extensions, and vulnerabilities that extensions add to websites. We propose and evaluate additional defenses, and we conclude that banning HTTP scripts and inline scripts would prevent 47 of the 50 most severe vulnerabilities with only modest impact on developers.




Download PDF: http://www.eecs.berkeley.edu

W3af walkthrough and tutorial – Part 1

W3af walkthrough and tutorial – Part 1: w3af (Web Application audit and attack framework) is a framework for auditing and exploitation of web applications. In this series of articles we will be looking at almost all the features that w3af...



Go on to the site to read the full article