Thursday, January 17, 2013

Web Exploits and Intrusion Detection Systems


Introduction

Over the past year, I have observed a significant decrease in the number of detections of modern threats among organizations protected by traditional Intrusion Detection and Prevention Systems (IDS/IPS) while those monitored by community intelligence based solutions and behavioral analysis have shown increases. Meanwhile organizations are becoming increasingly educated about modern threats and have been seeking confirmation that their chosen products can address these threats. Organizations and their executives are expecting their staff to show them where they have been compromised and attacked, however the traditional configurations employed are not producing data representing detections of modern threat activity. Relying on these vendor produced solutions alone has forced some to conclude that their networks are clean when in reality they are deeply infiltrated. Representing adequate threat coverage has become an increasing challenge as a result.

Highly Pervasive Threats

Recent surges in exploit delivery kits and the evolution away from direct exploitation has largely moved the bulk of Internet based attacks to a passive model. The sharing of resources and monetization of exploit kits has resulted in a surge of weapons and variants available to the adversary and has eased the process of exploitation. Additionally the increasing use of encoding and encryption to hide malicious content has decreased the visibility the IDS has over the session. Traditionally an adversary would scan a network, find applications they could interact with, and attempt to directly deliver exploit code to them.

Weaponization: From a kill chain perspective, industry is seeing pervasive threats weaponize files like documents (MS Office, Adobe PDF, MS Excel), as well as active Internet content (Java, Flash) by embedding exploit code within them and hiding this code through obfuscation tactics including encoding and encryption. In this new model the “attack” has become akin to successfully delivering the weaponized file to a victim and executing it locally. The weapons themselves have become additional delivery channels, often exploiting a vulnerability in an Internet based application to download a final stage package containing the core malware.

Delivery: Rather than identifying a specific target and launching a custom or tool driven direct attack by delivering exploit code directly to the vulnerable application, adversaries are using embedded weapons like mines throughout the Internet and luring unwitting victims to them through phishing, injecting into legitimate websites, and creating malicious versions of seemingly legitimate websites. One tactic recently discovered and employed by the adversary is the monitoring of top news and creating malicious websites purporting to be related or hosting information about the story. JavaScript, iFrame, PHP, and CGI is being commonly used to redirect a user’s browser to access content unintended by the user. As users are lured to the delivery websites, they are exposed to the exploit through passive actions which often result in their inadvertent requesting of the weaponized file. These delivery websites are often temporary and dynamic making tracking difficult. They get registered through free online domain registry sites using fake personas and change quickly or go silent after first use. This tactic is used by the adversary to evade black list attempts by defenders to prevent or detect known malicious websites.

Exploitation: When exposed to one of these delivery sites, the client application (web browser) receives the weaponized file still in its obfuscated state. The weaponized file (JavaScript, Flash, PDF etc.) containing the encoded or encrypted contents also includes decode or decrypt functions which are performed within the client application during execution, finally exposing the exploit code to the application and resulting in a compromise. With these exploit kits, this is usually the first stage. The application has been exploited and is then used to retrieve and execute an additional malware package which results in a system level compromise.

Example from Blackhole: A lab test conducted using the Blackhole Exploit Kit resulted in the following progression:
Initial redirect: GET <baddomain>/main.php?page=<string>

Weapon retrieval
: GET /archive=”Leh.jar” loads the Java applet in the browser and triggers the next stage
Second stage: GET /w.php?f=<string> about 2 seconds later, served “contacts.exe” in response

Exploitation: contacts.exe executed on the local system performing persistent changes

Compromise symptoms: A new application on the victim system began generating repetitive HTTP GET requests using a User-Agent string of “Windows 98” which did not match any known applications previously installed.

A compilation of the most active exploit kits which leverage this model is represented below. A keyword based cross reference of the exploit kits against a leading Intrusion Prevention System (IPS) vendor’s content encyclopedias was conducted to find if there were any IPS/IDS, AV, App Control, or other signatures available to address these adversary tools. The results are included below.

Redkit: 0 references found
NeoSploit: 0 references found
Cool Exploit kit: 0 IPS references
Blackhole: 0 IPS references found, numbers virus results
Nuclear Pak: 1 reference in IPS to an RFI related attack (not the exploit kit) and 1 RAT sig
Crimeboss: 0 references found
Cridex: 0 IPS references
Phoenix: 0 IPS references
TDS Sutra: 0 references found
Sweet orange: 0 references

These exploit kits each represent a delivery system. The weapons used within each exploit kit can vary from user to user, however they often use a common set of standard exploits. A review of the 2012 exploits used by these kits as noted by their Common Vulnerabilities and Exposures (CVE) reference is listed below. A keyword search within the same IPS vendor’s threat encyclopedia using the CVE identifier of the specific exploits used by each of these kits was conducted and found at least one signature match for each exploit.

CVE-2012-4969 (Java 0-day used in blackhole) – 1 prevention signature
CVE-2012-4681 (Java 0-day used in NeoSploit, Blackhole, Redkit, Nuclear, Crimeboss, Sweet Orange) – 2 prevention signatures
CVE-2012-1723 (Java exploit used in Blackhole, Cool, NeoSploit, Nuclear) – 1 prevention signature
CVE-2012-1535 (Flash 0-day exploit) – 1 prevention signature
CVE-2012-0779 (Flash targeted exploit, Phoenix) – 1 prevention signature
CVE-2012-1875 (MS IE exploit) – 1 prevention signature
CVE-2012-0507 (Java exploit used in Redkit, Phoenix, Blackhole, Cool) – 1 prevention signature

A review of these vendor threat encyclopedia articles validates they appear to be directly related to detecting the exploits associated with each of the vulnerabilities. The articles also reference the correct delivery model for the exploits targeting active Internet content (ie malicious websites) and the vulnerable application (ie Java). From this finding, one conclusion could be drawn that the IPS vendor has the ability to detect these modern day exploit kits because they have signatures that detect the exploit code associated with the exploits used by the kits. Another conclusion can be drawn that since the vendor did not reference these exploit kits by name, their approach appears to be to focus on the actual exploit code and not how it is used.

Lab Tests

Testing actual system exploitation in a lab using some of these exploit kits resulted in 0 detections by a leading IPS system (the same vendor referenced above) running configurations validated by the vendor’s technical resources. The logical question is if the product has detection content to address these exploits, then why is it not detecting the activity?

A Lesson in Obfuscation

The reason the before mentioned exploit kits have become so highly effective and pervasive is they each employ various methods of obfuscation and encryption to hide the exploit payload from inspection by technology such as IDS/IPS. Recall the Weaponization, Delivery, and Exploitation sections above. The exploit code is not passed directly between the “attacker” and victim in normal clear syntax for inspection by the IDS, but rather encoded within websites or within files transferred to the victim. All of these kits use an intermediary application or file to obfuscate and carry the exploit code to the target where it is exposed only during execution, not during the delivery stage where IDS can inspect the payload. Encoding comes in various forms including character substitution, XOR, base64, string reversal, custom encoding, encryption etc. The basic progression is:

  1. User browses to malicious website containing “clean” HTML, PHP, or CGI code
  2. Website contains HTML, PHP, or often an iFrame which instructs the browser to retrieve a secondary active content file (usually JavaScript or Flash) – no exploit code is in the HTML, PHP, or CGI
  3. This file contains the obfuscated or encoded exploit code which cannot be inspected by the IDS/IPS (because it’s encoded)
  4. The file is received by the client and loaded into the browser where the contents are decoded and the exploit executed
  5. Game over

Competitive and Community Solutions

Some in the competitive field have taken a more proactive approach to threat detection, focusing not on the actual exploit, but rather the delivery model and methods to perform the initial detection. The threat community group called “Emerging Threats” lead by researcher Matt Jonkman takes this approach a step further by developing detection signatures based on the behaviors of delivery and exploitation as well as the attributes of weaponized files or websites and compromised systems. Rather than detecting an exploit, they detect websites, URLs, URIs, and files which match attributes of weapon delivery, weaponization, and command and control (C2). This model produces the highest fidelity detection on exploitation behaviors, preceded by informational alerts but also generates a high volume of alerts which must be correlated for their potential to be realized. Using these behavioral indicators will produce a significant volume of independently uninteresting alerts, however the combination of multiple alerts in sequence enables the high fidelity “detection” rather than any single signature by itself. For example:

·         ET CURRENT_EVENTS Blackhole – Blackhole Java Exploit request to spn.jar (Java asked for a file)
·         ET INFO JAVA – Java Archive Download (A .jar was downloaded)
·         ET INFO Java .jar request to dotted-quad domain (Java requested a .jar to an unusual domain)
·         ET INFO EXE – Served Attached HTTP (an EXE was attached to an HTTP request)
·         ET CURRENT_EVENTS DRIVEBY Blackhole – Payload Download – readme.exe (readme.exe was downloaded)
·         ET POLICY Windows 98 User-Agent Detected – Possible Malware or Non-Updated System (an Internet application using an outdated identification string was detected)

These are all behavioral indicators of exploit kit activity. Specifically these examples are used in conjunction to detect the various stages of the Blackhole kit, however these attributes exist among numerous kits. In this example, some of these indicators are benign but when represented together in context, they provide a positive detection.

Missing the Message

Coincidentally I have heard countless arguments from security minded people who claim these highly pervasive exploit kits aren’t worth the resources to detect and defend against because they represent basic criminal activity. They argue that the real threat, the “Advanced Persistent Threat,” is where we should be focusing resources because they cause major damage. The basis for this argument assumes the delivery method used by the adversary is a direct representation of their level of sophistication which is a direct sign of their intent and ability. As operation ShadyRAT, Night Dragon, and now Red October have shown, this is a dangerous assumption. We see time and time again extremely sophisticated adversaries using common methodologies because that’s all it takes to infiltrate an organization. Why use your most sophisticated tactics and risk exposing them, when common tactics will suffice?

Advanced Threats

The Red October campaign with Flame-like characteristics uncovered by Kaspersky this week has been hitting the news rounds. More information is coming out daily and today it was revealed that the two primary delivery vectors were spear-phishing with a weaponized file (MS Word, Adobe PDF, or MS Excel) and web exploit via Java. Nothing new there, however it’s interesting to note the similarities with common web exploit kits (Blackhole, Redkit etc) which tend to get downplayed as common threats not worthy of the same attention as “APT” activity. This is a good reminder that the severity of the threat and who’s behind it is less about delivery and compromise symptoms and more about use. It’s not how it was delivered, it’s how it’s being used.


Notice this excerpt about delivery from the article referenced above: “the attackers sent an email with an embedded link to a specially crafted PHP web page. This webpage exploited a vulnerability in Java (CVE-2011-3544), and in the background downloaded and executed the malware automatically.” Later it appears the malware authors changed from PHP to CGI but continued to use web exploits. This maps exactly to the exploit kit methodology previously described.

That specific exploit and method was also used by Blackhole during early 2012 (the methodology is still active it just uses different exploits). Something organizations might downplay as Internet noise, hence the reason malware analysis is so critical; understanding what the malware is and does is essential to understanding the nature and severity of the threat and other reminder that web-based monitoring and behavioral detection remains a critical component of comprehensive defense.

Then there’s this: “Analysis of the server side source code of the exploit showed that the malware payload URL is encoded before being passed to the Java applet. ‘When the client is exploited, the URL gets decoded and the malware gets downloaded.’” That’s something else we’ve seen among common web exploit kits and the reason IDS often misses the exploit code and “attack” stage. The delivery is obfuscated and the exploit exposed post-delivery (rendered in the browser).

Conclusions

The combined research above has shown that market leading Intrusion Detection and Prevention Systems (IDS, IPS) are woefully unprepared to not only address highly pervasive threats but also sophisticated nation-state sponsored campaigns which have persisted undetected for years. To detect and defend against the modern threat, whether they be common criminals or Advanced Persistent Threats, a comprehensive approach that covers all delivery vectors and focuses on behavior rather than exploit code is needed. Community based groups such as EmergingThreats.org and the various private threat intelligence sharing groups are a critical inclusion into active defense. Going stock IDS alone won’t solve this problem. A combination of able technology, people and process including understanding the nature of the threat; conducting ongoing research and analysis into adversary tools, tactics, and techniques  identifying behavioral indicators and developing signatures; community sharing; and data correlation is needed.

References
http://www.emergingthreats.net/open-source/open-source-overview/

No comments:

Post a Comment