New Java 0day exploited in the wild

-




A few hours ago, FireEye published some information related to a new Java 0day exploited in the wild.

The malicious JAR file was served from ok.aa24.net / meeting / index.html

The html loads the Java applet passing some parameters that are used later to build the URL to download the payload. The HTML is encrypted using “Dadong’s JSXX 0.44 VIP”.









The Java applet contains the following two .class files:

- cve2012xxxx/Gondzz.class

- cve2012xxxx/Gondvv.class

The applet check if the system is running Windows and gets the parameters passed from the HTML that contains the URL to download the payload. If the system is vulnerable, the payload is downloaded and executed in the system.




On the analyzed sample the payload is downloaded from ok.aa24.net / meeting / hi.exe

https://www.virustotal.com/file/09d10ae0f763e91982e1c276aad0b26a575840ad986b8f53553a4ea0a948200f/analysis/1346055031/

The payload drops C:\WINDOWS\system32\mspmsnsv.dll (replace the file if present) and starts the Portable Media Serial Number Service.

The malware connects to hello.icon.pk port 80. It seems to be a Poison Ivy variant.

hello.icon.pk resolvs to:

223.25.233.244

223.25.233.0 – 223.25.233.255
8 to Infinity Pte Ltd

You can use the following generic Yara rule to detect a malicious .class file exploiting this vulnerability:

rule Java0daycve2012xxxx_generic
{
  meta:
     weight=100
     author = “Jaime Blasco”
     source = “alienvault”
     date = “2012-08″
  strings:
        $ =  ”java/security/ProtectionDomain”
        $ = “java/security/Permissions”
        $ = “java/security/cert/Certificate”
        $ = “setSecurityManager”
        $ = “file:///”
        $ = “sun.awt.SunToolkit”
        $ = “getField”
  condition:
    all of them
}
A module has just been published for Metasploit so it is time to disable Java in all your systems

And remember to search your logs for connections to the Domains/IPs related to this attack.

Have a great day!

for more updates join us :Facebook

Comments

Post a Comment

Popular posts from this blog

AntiCloud Trojan Reverse Engineering Analysis

-
Image
Introduction In this paper we are going to talk about the Anticloud Trojan, also know as the  TrojanDropper:Win32/Bohu.A and  B  variant. This malware originated in China and was designed to target the Cloud-Based Technology of major Chinese AntiVirus Vendors. For this reason, Bohu has also been called  AntiCloud Trojan . This is the first malware to specifically target cloud based technologies and will likely set a trend. As more corporations and governments move applications and services into the cloud, it will become an increasingly important target for malware developers. We can expect sophisticated malware that attacks clients and embeds itself into cloud-based apps, potentially without the user being able to determine that the cloud-based service is compromised. This trojan presents some interesting features, such as: Hash Check Evasion. Packet Interception via NDIS Filter. Cloud-Servers Access Lock via SPI network filter in order to Bypass antivirus Detection. So
Read more

SQL Injection: The Equal Opportunity Vulnerability

-
Image
Introduction In the  first installment of this series , we discussed application security within the Software Development Process by demystifying the adoption of security controls within the development organization. We also took a deeper dive into identifying potential vulnerabilities based on threats to attack surfaces exposed to the application, a process known as threat modeling. In this installment, we are going to take a technical dive into specific vulnerabilities that can be used to compromise the attack surfaces and discuss what is arguably one of the most prevalent attacks to applications and inflicts the most exposure of sensitive data: SQL Injection. Injection attacks attempt to infiltrate an application by injecting malicious content into the application through available input channels. Input channels can be in the form of form fields, uploads, 3 rd  party API, data access channels, configuration files, input files: essentially, any point at which the application r
Read more

Secure Sockets Layer (SSL)

-
Image
Secure Sockets Layer (SSL): How It Works What Happens When a Browser Encounters SSL > A browser attempts to connect to a website secured with SSL. > The browser requests that the web server identify itself. > The server sends the browser a copy of its SSL Certificate. > The browser checks whether it trusts the SSL Certificate. If so, it sends a    message to the server. > The server sends back a digitally signed acknowledgement to start an SSL encrypted session. > Encrypted data is shared between the browser and the server. Encryption Protects Data During Transmission Web servers and web browsers rely on the Secure Sockets Layer (SSL) protocol to help users protect their data during transfer by create a uniquely encrypted channel for private communications over the public Internet. Each SSL Certificate consists of a key pair as well as verified identification information. When a web browser (or client) points to a secured website, th
Read more