Showing posts with label 0-day. Show all posts
Showing posts with label 0-day. Show all posts

Thursday, January 22, 2015

Malvertising leading to Flash Zero Day via Angler Exploit Kit


UPDATE [01/25/2015]: Adobe released an update yesterday (APSA15-01) for CVE-2015-0311 that fixes the zero day exploit mentioned in this blog. Given the number of exploit attempts we are seeing for this vulnerability in the wild, it is critical for users to update the Adobe Flash player to the latest version 16.0.0.296.

Background

Earlier this week, Kafeine published a blog mentioning an Angler Exploit Kit (EK) instance serving a possible zero day Adobe Flash exploit payload. The ThreatLabZ Research Team reviewed Angler Exploit Kit activity across the cloud and were able to identify multiple instances of Angler Exploit Kit hosting sites serving a new Adobe Flash payload that is able to exploit the latest Flash Player version 16.0.0.257.  [Adobe released a patch (APSB15-02) for CVE-2015-0310 today and we can confirm that the patch does not prevent exploitation of the 0day discussed in this blog. The latest version 16.0.0.287 is still vulnerable and is being actively exploited in the wild.]

Upon further investigation, we discovered that this appears to be yet another case of a Malvertising campaign leading unsuspecting users to Angler EK instances. Upon successful exploitation, we observed a new variant of the Bedep Trojan getting dropped and executed on the victim machine. We tested this on a Windows 7 64-bit system and the payload dropped was a 64-bit Bedep Trojan variant which generated a high volume of AdFraud traffic from the infected system.

The affected advertising networks found in this case were:
  • oneclickads.net
  • adcash.com
Infection Cycle

The infection cycle involves users visiting a legitimate site that displays certain advertisements from the compromised advertising networks, which will redirect them to an Angler EK hosting site and begin the exploit cycle. If the exploit is successful, a new variant of Bedep Trojan gets downloaded in an encrypted form and installed on the target system.

The entire infection cycle occurs silently in the background and is completely transparent to the end user.


The exploit page has the title "Welcome to new site" and is comprised of 220 hidden input elements, followed by three inline scripts.


The first script code snippet is obfuscated with block comment text (ie: /* random text */), but also appears purposefully broken for multiple JavaScript engines. Looking at the code, there are multiple period characters inserted throughout the script which leads to syntax errors at runtime:


The second script code snippet calls a function in the first script leading to "eval" and resulting in JavaScript code that performs Browser plugin detection:



The third script code snippet drew our attention, as it is not obfuscated and simply loads an SWF object. This script serves the Adobe Flash 0-day and it is interesting to note that the script will only execute if the earlier script has thrown an error. The flash payload is only triggered if a variable defined in the first script is undefined:



Successful exploitation will result in download of the Bedep Trojan payload that appears to be encrypted using an incremental XOR technique.

Malware Payload activity - Bedep Trojan

The malware payload dropped is a 64-bit DLL belonging to Bedep Trojan family.  This malware family is known to download additional malware. It is also responsible for generating AdFraud and ClickFraud activity from the infected system.

File: neth.dll
Size: 219608
MD5: EFB584DEA6CBC03765487633BD5A5920
Compiled: Wed, Nov 28 2007, 15:51:15  - 64 Bit DLL
Version: 5.3.3790.3959 (srv03_sp2_rtm.070216-1710)

It drops a copy of itself at the following locations:

C:\ProgramData\{9A88E103-A20A-4EA5-8636-C73B709A5BF8}\neth.dll
C:\Users\All Users\{9A88E103-A20A-4EA5-8636-C73B709A5BF8}\neth.dll

It creates the following registry entries to achieve persistence in a discreet manner:

HKLM\SOFTWARE\Classes\CLSID\{F6BF8414-962C-40FE-90F1-B80A7E72DB9A}\InprocServer32\: "C:\ProgramData\{9A88E103-A20A-4EA5-8636-C73B709A5BF8}\neth.dll"
HKLM\SOFTWARE\Classes\CLSID\{F6BF8414-962C-40FE-90F1-B80A7E72DB9A}\InprocServer32\ThreadingModel: "Apartment"


HKU\S-USERID-1000_Classes\CLSID\{F6BF8414-962C-40FE-90F1-B80A7E72DB9A}\InprocServer32\: "C:\ProgramData\{9A88E103-A20A-4EA5-8636-C73B709A5BF8}\neth.dll"
HKU\S-USERID-1000_Classes\CLSID\{F6BF8414-962C-40FE-90F1-B80A7E72DB9A}\InprocServer32\ThreadingModel: "Apartment"

This ensures that it runs in the context of system process "explorer.exe":


It appears to determine the infected system's timezone and location by connecting to "earthtools.org", however we noticed that it is not able to supply the latitude and longitude parameters in the request, essentially resulting in getting back UTC date and time information.

It employs a Domain Generation Algorithm technique to hide the actual Command & Control server as seen below:



 We found the following two C&C domains registered in past 48 hours:

  • gaabbezrezrhe1k.com
  • wzrdirqvrh07.com






It attempts to connect to these Command & Control servers to report the infection and receive further instructions. It presumably gets a list of ClickFraud tasking servers, following which we started seeing high volume of ClickFraud activity.




Conclusion
This is the first 0Day Adobe Flash Player exploit for year 2015 and not surprisingly, we are seeing it getting served through a malvertising campaign. The fact that the end malware payload getting served in this case is also involved in AdFraud activity leads us into believing that this campaign appears to be from a gang indulging in ClickFraud and AdFraud activity.

Zscaler ThreatLabZ has deployed multiple layers of protection against this threat to ensure that the customers are protected.

Analysis by Deepen Desai & John Mancuso

Thursday, September 25, 2014

Shellshock attacks spotted in wild [Updated Sept 26]

[Updated Sept 26, 2014: added new analysis and exploit attempts]

Background

GNU Bash is susceptible to an arbitrary code execution vulnerability (CVE-2014-6271) dubbed as Shellshock. The vulnerability is due to failure to properly handle environment variables.

A remote attacker can exploit this flaw by interacting with an application that uses BASH environment variables to override or bypass environment restrictions to execute shell commands. If an attacker can control the value of an environment variable, then code execution can be achieved in the context of the application using the environment variable.

A public advisory was released regarding this vulnerability here:

http://seclists.org/oss-sec/2014/q3/650
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

Shellshock Attacks - CVE-2014-6271

Within hours of the public disclosure of this vulnerability, we have started seeing incidents of attacks targeting this vulnerability in the wild to download additional malware. It appears that Nginx and Apache web servers configured to use mod_cgi are two potentially vulnerable services that are actively being targeted in the wild. One such incident that we were able to confirm through mining our logs is shown below:


The server involved in the above case was found to be compromised and hosting ELF binaries which belongs to the same Linux Backdoor Trojan family with DDoS capabilities. We believe that the vulnerable Apache servers were resulting in the download of an ELF binary named "apache" whereas vulnerable Nginx servers were getting the ELF binary named "nginx". The only difference we saw in these two binaries was the hardcoded Command and Control server information.

Upon successful exploitation of CVE-2014-6271 vulnerability, the attacker is able to download and install the malicious ELF binary on the target Linux system. The malware connects to a predetermined Command and Control (C2) server on a specific port and awaits further instructions from the attacker. The C2 information can be seen hardcoded in the binary:


The malicious ELF binary named "apache" is leading to a different C2 location "162.253.66.76:53".

This malware family is capable of performing the following actions:
  • BusyBox command injection exploit attempts
  • Collect and send sensitive system information
  • Perform Denial of Service attacks
  • Brute force authentication attempt 
  • Opens a Backdoor connection for remote attacker
List of commands supported by this bot:


The screenshots below show sample command and control communication from this bot:
Initial call back message and command to get system IP address
Shell command & JUNK flooding attempt

Active Shellshock exploit attempts [Updated - September 26, 2014]

Below is a sample list of suspicious headers that we captured in past 12 hours attempting to exploit the Shellshock vulnerability (CVE-2014-6271). While majority of these appear to be testing attempts, some of them look malicious.



Check if your server is vulnerable:

It is extremely important for the system administrators to apply appropriate security patch depending on the Linux distribution they are running. Below is a code snippet posted by Redhat that you could use to determine whether your BASH version is vulnerable or not:

env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"

Conclusion

We rate the severity of this vulnerability to be as critical as that of Heartbleed vulnerability discovered earlier this year. We are still investigating the level of impact associated with this threat.

Zscaler customers are protected from this threat and associated malware family. Zscaler ThreatLabZ is actively monitoring this threat and associated attacks in the wild.

Friday, February 21, 2014

Probing into the Flash Zero Day Exploit (CVE-2014-0502)

Yesterday, a targeted campaign leveraging a Flash zero day exploit hit the news. Adobe has now released a security bulletin regarding this vulnerability. Based on the attack vector mentioned in prior research, we have concluded that recently observed .SWF exploitation is related to the recent zero-day threat flagged as CVE-2014-0502. Upon successful infection, the exploited victim is served a RAT (Remote Access Trojan). 

While we were doing our daily review of logs, we found a significant number of transactions related to this campaign. We specifically started looking for those compromised servers which have been mentioned in prior research.  We began investigating all suspicious transactions which used a known compromised site as a referral location. 



After some brief inspection of this location, we found not only the malicious .SWF, but also all other connected malicious files detailed in the analysis below. We will cover the dropped Flash file that exploits the vulnerability using an image that contained embedded shell code. This shellcode is then used to download the malware.

The Flash file was found to be encrypted using the DoSWF flash encryptor.



Upon throwing the Flash file into an ActionScript viewer, we immediately see the script shown below. The script tries to make a URL Request to a GIF Image file, which contains the embedded shellcode for an ROP exploit.

The script checks for the presence of a cookie labeled 'XPT2013111'. If this cookie is not already present, it sets the same.





The script then checks the operating system version and in the case of Windows XP, further checks the OS language. Details of the OS language and version are then used to determine the base address for the exploit. In case of Windows 7, the script further probes for unpatched and outdated versions of Java (Web Start 1.6 and 1.7) or Microsoft Office (Sharepoint OpenDocuments 3 or 4).




Here we can see on XP, based on the version and language, the base address for the exploit is determined by the script. Then the ROP sled is built to carry out the exploit.

The GIF image used for embedding the shellcode is shown below, which of course seems innocuous to the victim.

 


When opened in a hex editor, the magic bytes for a GIF image file can be seen.



However, upon careful examination, we further see extra bytes appearing toward the end of the image as shown below.


Using a shellcode emulator like libemu, we can see that this extra data represents the shellcode to be executed.


Here we see that the shellcode makes a call to the LoadLibraryA function and then to VirtualProtect to allocate memory in which to place the shellcode. It then checks for the /temp folder path and makes calls to InternetOpenUrlA to download the malware from a remote location http://[x.x.x.x]/common/update.exe and drops it into the /temp folder.

A sandbox analysis of the final dropped file can be seen here.

Browser plugins continue to be the Achilles heel of enterprise security. While enterprises struggle to ensure that browser plugins are up to date on all end user systems to prevent browser exploit kits from targeting known vulnerabilities, here we see yet another demonstration where even that is not enough. Attackers continue to identify and exploit 0day vulnerabilities in popular web browser plugins such as Adobe Flash, which unfortunately has a long history of dealing with such threats.


Monday, January 14, 2013

Are you vulnerable to yet another Java 0Day exploit?

Test to see if you're vulnerable.

Only five months after the last high profile 0-day Java vulnerability, there is new 0-day being exploited through Java plug-ins. This vulnerability is present in Oracle Java 1.7.0 to 1.7.10 and has already been included in a variety of browser exploit kits. On January 13, 2013, Oracle released a fix for the issue in the form of Java 1.7.11.

Java has a long history of 0-day vulnerabilities being actively exploited. Exploits are usually drive-by attacks: users get infected by navigating to hijacked websites where an invisible Java applet drops a malicious executable on the user's machine. The very popular, Blackhole exploit kit includes numerous Java exploits.

This vulnerability has been exploited very quickly on the Internet. Firefox reacted quickly by flagging all versions of Java as vulnerable plugins. This means Java is disabled by default on Firefox and users get warned if a page requires the use of Java. It would appear that the work they recently did on their Click to Play feature for vulnerable plugins has paid off. Apple took a similar approach by pushing out a new malware definition list that rather than blocking malware, as it generally does, simply disabled the Java Web Start browser plugin altogether.

Are you vulnerable?

The latest iteration of Java is version 1.7 revision 11. This is now the default version on Windows. Although Java 1.6 is not vulnerable to this latest threat, Java 1.6's end of life is February 2013, so you should not downgrade to that version.

One annoying fact with Java is that new versions are installed on top of each other. As such, you are likely to have multiple versions of Java installed on your system. Internet Explorer may not even be using the latest version of Java that you have installed.

We have therefore created a new page to list all of the versions of Java installed on your computer. You can test your browser here.

Disable Java

To be on the safe side, you can disable Java in your browser to prevent malicious applets from running.

Firefox

Go to Tools - Add-ons - Plugins

Look for Java Deployment Toolkit and/or Java Platform SE. Disable them all.

Java disabled in Firefox

Chrome

Go to WrenchSettings and Show advanced settings... - Privacy and Content settings - Plug-ins - Disable individual plug-ins... - Java - disable. It is quite difficult to find!

Java enabled in Chrome

Internet Explorer

Go to Tools - Manage Add-ons. Disable Java(tm) Plug-in SSV Helper and Java(tm) Plug-in 2 SSV Helper.


Java disabled in Internet Explorer 9
Update: To completely disable Java in Internet Explorer, follow the steps at http://www.kb.cert.org/vuls/id/636312#disable_java_in_IE.


Safari

Go to Safari - Preferences

Look for Web Content: Enable Java and uncheck the option.




Test it

Now go to our Java test page to ensure that Java has indeed been disabled in your browser.

Click to Play

If you need Java occasionally, you can enable it on-demand with Click to Play. I described Click to Play, a way to manually enable plugins only on visible content, in a previous post. This feature is only available in Firefox, Chrome and Opera.

Firefox also offers several browser extensions to easily enable/disable java with one click. I personally like Quick Java.

Take this opportunity to check all the plugins running in your browser and disable the plugins that you do not really need. Don't give the bad guys an attack surface that's any larger than it needs to be!

Tuesday, August 28, 2012

Are you vulnerable to the latest Java 0-day exploit? (Updated)

Test to see if you're vulnerable.

You may be aware that a 0-day vulnerability in the latest version of Java is presently being exploited on the Web. This vulnerability affects all versions of Java 1.7 (aka Java 7). Oracle has not yet released a fix and if they stick to their quarterly patch cycle, one isn't likely to emerge until October.

Java has a long history of 0-day vulnerabilities being actively exploited. Exploits are usually drive-by attacks: users get infected by navigating to hijacked websites where an invisible Java applet drops a malicious executable on the user's machine. The very popular, Blackhole exploit kit includes numerous Java exploits.

In 2010, we reported a 300% increase of malicious JAR (Java archive) files. Recently, in March 2012, Java made the news due to the Flashback Trojan, a piece malware targeting an older Java version that shipped with Mac OS X. As can be seen, Java is constantly under attack.

Update: new Java version available

Oracle has released java 1.7.7 and 1.6.35 to fix the vulnerability. You can update your java version from Java.com.

We have updated our Java test page to take the new versions into account.

Are you vulnerable?

The latest iteration of Java is version 1.7 revision 6. This is now the default version on Windows. Mac OS X still uses Java 1.6 (latest version: 1.6.33). Java 1.6.33 is NOT vulnerable to the latest 0-day exploit. However, I would not suggest that anybody downgrade from Java 1.7 to Java 1.6 as it is not yet known if version 1.6 is vulnerable to other flaws fixed in 1.7.

One annoying fact with Java is that new versions are installed on top of each other. As such, you are likely to have multiple versions of Java installed on your system. Internet Explorer may not even be using the latest version of Java that you have installed.

We have created a new page to list all of the versions of Java installed on your computer. You can test your browser here.

Disable Java

To be on the safe side, you can disable Java in your browser to prevent malicious applets from running.

Firefox

Go to Tools - Add-ons - Plugins

Look for Java Deployment Toolkit and/or Java Platform SE. Disable them all.

Java disabled in Firefox

Chrome

Go to WrenchSettings and Show advanced settings... - Privacy and Content settings - Plug-ins - Disable individual plug-ins... - Java - disable. It is quite difficult to find!

Java enabled in Chrome

Internet Explorer

Go to Tools - Manage Add-ons. Disable Java(tm) Plug-in SSV Helper and Java(tm) Plug-in 2 SSV Helper.


Java disabled in Internet Explorer 9
Update: To completely disable Java in Internet Explorer, follow the steps at http://www.kb.cert.org/vuls/id/636312#disable_java_in_IE.


Test it

Now go to our Java test page (updated) to ensure that Java has indeed been disabled in your browser.

Click to Play

If you need Java occasionally, you can enable it on-demand with Click to Play. I described Click to Play, a way to manually enable plugins only on visible content, in a previous post. This feature is only available in Firefox, Chrome and Opera.

Firefox also offers several browser extensions to easily enable/disable java with one click. I personally like Quick Java.

Take this opportunity to check all the plugins running in your browser and disable the plugins that you do not really need. Don't give the bad guys an attack surface that's any larger than it needs to be!

Friday, June 17, 2011

Oh Flash! CVE-2011-2110 0-Day

This past Tuesday, June 14, a vulnerability (CVE-2011-2110) in the Adobe Flash Player was patched. This vulnerability is actively being exploited in the wild - prior to the patch, the earliest exploitation that we have seen in our logs thus far, dates back to early last Thursday (June 9th).

Attackers have/are embedding redirects into compromised legitimate websites (including an Indian government site, a US airport site, and an aerospace site, among others). The redirects direct user's web-browsers to access the flash exploit - once the victim machine is exploited it downloads, decodes, and executes malcode.

Working with Steven from Shadowserver we were able to collectively share information to benefit the community and a public, detailed report was subsequently released on their website. Their report lists the sites/servers that we helped identify that have hosted the malicious content, as well as provides guidance for handling this threat. Among the recommended guidance:
  • Patch! Flash Player older than 10.3.181.26 (or 10.3.181.24 for Android) is vulnerable. You can check your version here.
  • Block the identified malicious servers/pages/binaries - this has already been done for customers using our cloud.
  • Block/monitor for additional sites using the same attack pattern - this has already been done for customers using our cloud. Shadowserver released a Snort signature in their report to assist with identifying this pattern as well.
A special thanks to Steven from Shadowserver.

Monday, January 25, 2010

IE 0-Day on GOV.CN

A few days back, there was a post on a forum about malware warnings displayed when visiting: www[dot]latax[dot]gov[dot]cn


Translates:



Upon analysis of the page, it appears that this GOV.CN page is hosting a page exploiting the Internet Explorer 0-day vulnerability (CVE-2010-0249). The same vulnerability exploited to compromise Google, Adobe, and other vendors in an attack dubbed 'Operation Aurora.'

Here is a snippet of the GOV.CN source, building the shellcode variable:

There is a slight deviation to the way that the shellcode is constructed (visible in above image) from some of the other variants that we have seen. Though, it uses the same exploit structure as past variants, including the ev1() and ev2() function names.
The ev1() function is used to dereference the previously declared event object:and attack the vulnerability
using the ev2() function to load the shellcode into memory and call the previously dereferenced object:
The JavaScript loads the shellcode and exploits the vulnerability, which downloads the payload v.exe from the same GOV.CN domain.
VirusTotal identifies 12/41 Anti-Virus engines detect the v.exe payload. It is a variant of the Chinese based Hupigon Backdoor, which F-Secure lists some of its features as:
• It allows others to access the computer
• Allows for recording with the user's webcam
• Can make the user's computer to attack various servers
• Send victim's computer messages
• Has rootkit functionality so it has a stealth component that hides files
• Create logs from keystrokes, steals passwords, and sends this information to remote servers

The Hupigon malware kit is described as being "maintained in a very professional fashion with a highly developed User Interface (UI)." Screenshot below:


This is just one example of this IE 0-day impacting GOV.CN sites; I have seen a few other reports of this. While there are several other examples of malware being hosted on GOV.CN domains, for example,
  • .wscz.gov.cn
  • .zhepb.gov.cn
  • .jssalt.gov.cn
  • .xfgh.gov.cn
  • .laspzx.linan.gov.cn
  • .zsjs.nmfc.gov.cn
The question is: are these CN Government sponsored for the purposes of potentially spying on its citizens, or have GOV.CN websites been infiltrated by hackers? In either case, browse safe, and if you are using IE 6, please upgrade or consider a different browser.