Archive for August, 2012

Once, we used to talk about the cloud when we think of the weather. Today, we talk of the cloud that stores data, runs applications, and houses software. You often hear it in conversations. You read about it online. You know the cloud exists, but really, what is it?

Whenever you store photos on Facebook or upload files on Google Drive, you interact with the cloud. On a smaller scale, consumers like you are contributing to the growing ecosystem of the cloud. It is a concept as real as the threats cybercriminals exert in trying to steal the data it stores.

There is more to the cloud than virtually infinite storage or real-time communication. Blindly using the cloud without fully grasping it can give you more trouble than good. It isn’t just about trying out the fanciest apps. It is about knowing the pros and cons of “putting your data out there.”

Before you let go of data in your desktop or mobile devices, explore the risks you’ll go through when you put it in the cloud. Find out what the cloud is, why it is fast becoming a revolutionary tool for technology and business, and how you can also safely soar like the millions who benefit out of it through our fresh perspective e-guide: Files in Flight: What You Need to Know About Cloud Storage.

The security community has been focused on the new Java zero-day exploits that appear to have been taken from a Chinese exploit pack (known as Gondad or KaiXin) used in targeted attacks by the “Nitro” cyber-espionage campaign and then incorporated into criminal operations using the BlackHole Exploit Kit. While the connections between these developments are starting to emerge, it is important to remember that campaigns, such as Nitro, don’t “come back” because they don’t go away. The Nitro attackers continued to be active after their activities were documented in 2011.

In fact, before they acquired this Java exploit, the Nitro attackers were continuing to send out emails to their targets with direct links to Poison Ivy executables in early August 2012 (On a related note, another email was spotted in April 2012).

The file Flashfxp.exe was hosted on one of the same servers that hosted the Java zero-day and Poison Ivy payload, and it connects to ok.{BLOCKED}n.pk which resolves to the same IP address, {BLOCKED}.{BLOCKED}..233.244. This is the same address as hello.{BLOCKED}n.pk, the domain used as the command and control server for the Poison Ivy payload dropped by the Java zero-day.

Despite having at least two staging servers hosting the malicious files for the Java zero-day exploit (and at least three staging servers hosting executables), all the Poison Ivy payloads connect to domains that resolve to the same IP address. Numerous domain names used as Poison Ivy controllers related to the Nitro campaign also resolve to that IP address. While there was some initial skepticism regarding whether or not this Java exploit was used in targeted attacks, there appears to be increasing evidence that it was used by the “Nitro” attackers.

Oracle has released an out-of-bound patch for Java which patches this zero-day exploit. The update increments the version number to Version 7 Update 7 for users on the latest JRE version; users still using Java 6 are also receiving an update that will increment their version to Version 6 Update 35. Users should immediately update their systems to protect against this threat.

Back in October of 2010, Apple announced they would drop support for Java. This did not spur Oracle to directly support this Unix platform as it did for other Unix operating systems. The delay this caused in Java updates allowed OS X to play a role in clickfraud schemes among other nefarious activities. Apple finally responded by producing their own updates culminating in Java 6 update 33. Since then, another change to Java 6 affects time zone changes in two different regions. It seems unlikely OS X will receive further updates for Java 6 by Apple.

On August 14th 2012, Oracle released Java 7 update 6 for Lion and Mountain Lion OS running on Apple’s Mac platform. Oracle’s direct support for OS X brings an end to blaming Apple for slow Java updates. The future of Java and its relative security is now clearly in the hands of Oracle. Within two weeks of Oracle releasing their version of Java 7 update 6 for OS X, an exploit was discovered that affected Windows, where OS X and Linux have the same vulnerability. This vulnerability affects Firefox, IE 9, and Safari 6. Oracle’s record is not sterling at offering timely Java exploit patches, and the clock is ticking.

A Java in Mac Background

Java was invented at Sun in the early 1990s. This programming environment helped bridge differences between operating systems from mainframes to embedded devices. Java was even seen as an alternative control method to that of Microsoft’s ActiveX, introduced in 1996, to extend Microsoft’s COM and OLE OS communications. In 2000. Windows replaced JavaScript with ActiveX as their API for their browser. This plugin API had been developed for Netscape. JavaScript is not Java, but Netscape considered Java to represent a client-server solution offering a distributed OS. Microsoft’s Internet Explorer 5.5 ActiveX exposed OS applications to the network, where Microsoft expected broad adoption of their applications would increase Windows’ influence over the Internet.

Microsoft’s stated reason for making the change to ActiveX extending their browser was to improve security. This occurred as Microsoft dropped Windows Internet Name Service (WINS) in favor of DNS that offered name hierarchy, the basis for today’s certificate authority. ActiveX seemingly became a replacement strategy for WINS as their means to dominate the Internet. Instead, malefactors used ActiveX over the Internet to control Windows applications. ActiveX did not establish Windows as a dominant player on the Internet, nor did ActiveX improve security.

Android adopted Java in 2005 to establish a Java Runtime Environment (JRE). Sun open-sourced Java under the GPLv2 in November 2006. Unhappy exceptions were not permitted for mobile applications, Google developed its own Java Virtual Machine (JVM) technology, called Dalvik that avoided programming interface constraints and transformed JRE’s stack approach into Java Virtual Machine’s (JVM) use of registers.

Since then, Sun was acquired by Oracle in 2010. Apple has not offered an uninstaller for Java, and programs using Java may not heed disable checks in Apple’s Java control panel and attempt to use Java anyway. Many of these same programs also fail to notice Oracle’s control panel for Java 7 update 6, nor accept the location of the Java 7 environment as being valid. These Java issues will take some time to be resolved, but Apple has made their intentions clear by no longer automatically installing Java and not supporting Java 7.

Apple App Rules

The Mac App Store Review Guidelines rule number 2.24 states that:

“Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected”

By controlling how applications are updated, what meta-information and shortcuts are permitted, prohibiting auto-launching without user consent, and prohibiting the downloading of other applications or modifications – all these has the goal of improving security. Enforcing these security assurances would be less practical and more open to exploitation by malefactors if Java were permitted.

In addition, Apple has a history of shunning cross-platform libraries that pass execution with data structures over the stack they consider inherently less optimal. Apple opted to use Objective-C, which exchanges messages and not execution. This language was developed in the early 1980s for the NeXT multi-media computer that became the platform for the first browsers then ported as Netscape and Internet Explorer.

Will we eventually say goodbye to Java-based apps like Cyberduck and to Java itself on OS X versions that came before Lion?

What does this mean for OS X users?

First, back up your system before making any changes to Java. These changes may break non-Apple applications, particularly those that rely on Java to run. While Java is not used by OS X, be aware if something goes wrong with one of the non-Apple applications or a new vulnerability is actively being exploited. There is no install/uninstall utility friendly to both Apple and Oracle environments to properly install or remove existing Java virtual runtimes.

Users may not have installed the Java provided by Apple. Not installing this will cause OS X to prompt the user to install Java when a application attempts to use Java. Once Apple’s Java is installed followed by the installation of Oracle’s, under System Preferences normally located on the Dock, the Java cache should be cleared by clicking on Java icon located under the Other section.

This action opens the Java Control Panel. In the Java Control Panel, click on Settings under Temporary Internet Files and click on the Delete Files button in the Temporary Internet Files window. This will open the Delete Files and Applications window, click OK to confirm.

If you want to remove Java 7, Oracle has provided removal instructions in this page. Their instructions describe restoring a symbolic link to regain the function of the /Library/Internet Plugins/JavaAppletPlugin.plugin after placing it in the trash as the method for removing Oracle’s version when restoring Apple’s.

Uninstalling Java 6 provided by Apple without installing Oracle’s Java 7 can be done manually by removing “JavaVM.framework,” located at /System/Library/Frameworks/. Additionally, this will also require removing links at the following directories pointing to the runtimes in the framework:

/System/Library/Java/JavaVirtualMachines

/Library/Java/JavaVirtualMachines

Deprecating Adobe Flash and Java by Apple is aimed at ridding OS X and iOS of problematic languages causing the majority of vulnerabilities and problems. A question comes to mind: will HTML5 prove to be safer when everyone still wants to see the dancing fruit?

During one of our brainstorming sessions looking for interesting research projects, our group thought about how most mobile applications are, in essence, “browsers-in-a-box”.

Let me explain. When you open your favorite app, chances are it tries to access certain web pages and display the results in a certain way. Not all mobile apps do this, just most of them. I’m not only talking about those Amazon or eBay apps (which obviously do behave like browsers that limit their queries to their specific servers) but also apps like Flipboard. I love Flipboard, but at the very core of it, it’s just accessing Facebook and Twitter and displaying it in a pretty way (okay, very pretty).

Can this make apps more vulnerable to something that regular browsers are expecting users to do i.e. behaving unexpectedly? For instance, if an app is performing canned requests to a single specific site, can someone take advantage of this behavior to subvert the app or the site?

I set out to work on this and created an environment to sniff all traffic coming to and from mobile applications both in Android and iPhone/iPad environments. I tested lots of apps, checking their traffic and looking for something that might be exploitable and I did find things.

There is one particular resource management game a friend recommended that apparently is very popular. It turns out this game rewards players with a prize every weekend. They don’t do that anymore and it might be my fault, although I never contacted them directly. The way this worked is as follows: if you liked the game’s manufacturer on Facebook, they would share with you a certain password that would unlock resources only during a particular weekend. They’d change the password every weekend and it would only work during those two days.

The way this was implemented was by means of a plain HTTP request ‘here is the password’ and response ‘here is 10 gold and 10 food for you, thank you’. In other words, you could alter the state of the game from the outside by means of a simple, unencrypted HTTP request. Spoofing the server to point to a local server in the lab setup and getting a fake response of ‘here is 10000 gold and 1000 food’ was, of course, trivial. If ever I’ll see my friend again and show him my progress, he’s going to be quite amazed.

The bottom line of this mini-attack was clear: unprotected canned HTTP is not trustworthy.

There were other problems in different applications, like a fitness application that sells exercise routines to be displayed in your Android device. The routines consist of exercise descriptions, images, trainer explanations with instructions, timings and order of each routine. All these materials are contained in an XML file with links to each image and sound file. Yes, you guessed it, the XML was downloaded in plain-text, unencrypted HTTP traffic. I could have tried to access the paid content by guessing the XML file names but I didn’t try.

I saw some others but my problem with the whole project came when I had to put my findings in writing. The problems I found were so heterogeneous that it was difficult to differentiate this project from any web application pentest. So the clients are mobile applications but I was really looking at somebody’s unsecure web code. At the end of the day, my starting axiom was too true: all mobile apps are essentially web clients therefore they are as unsecure as a browser and that’s how you should treat them.

A failed project, I hear you say? Perhaps, but it opened my eyes with respect to how we – and app developers – need to treat mobile applications as untrusted browsers-in-a-box.

An unpatched JRE 1.7/Java 7 zero-day vulnerability (CVE-2012-4681) was recently found to be exploited by a malicious .JAR file hosted on a specific site. Successful exploit leads to the download of a backdoor, in effect allowing remote malicious users to execute their desired commands on the vulnerable system.

The zero-day exploit successfully runs in all versions of Internet Explorer, Firefox and Opera. According to a testing done by Metasploit, the vulnerability also runs on Google Chrome and Safari.

Technical Analysis of the Exploit and Payload

The affected vulnerability is related to the new Java 7classcom.sun.beans.finder.ClassFinder that allows the sun.awt.SunToolkit class to load, modify and execute the malicious code. This threat is composed of an HTML page with malicious JavaScript (index.html detected as JS_FIEROPS.A), a Java applet (applet.java detected as JAVA_GONDY.A), and the malicious binary (FLASH_UPDATE.exe detected as BKDR_POISON.BLW).

Users may encounter this threat by visiting a site, one of which is http://www.{BLOCKED}s.com/public/meeting/index.html, which results to the downloading and loading of the malicious Java applet (JAVA_GONDY.A). It then passes some parameters, which is then used to download BKDR_POISON.BLW.

Based on our analysis of index.html code, the script was heavily obfuscated and encrypted using Dadong’s JSXX 0.44 VIP.

Decompiling this script, we were able to get hold of the parameters being passed to the malicious Java applet. Below is the screenshot that shows the parameters are passed to the CVE2012xxxx.Gondvv.class in order to download and execute the malicious binary FLASH_UPDATE.exe.

When we examined the Java applet, we also noticed the following classes:

cve2012xxxx/Gondzz.class – contains the main codes and the code that exploits JAVA 7 by using the classcom.sun.beans.finder.ClassFinder class.

cve2012xxxx/Gondvv.class – contains the methods that are responsible for downloading and executing the malicious binary.

While the malicious Java applet runs, it calls the disableSecurity() method, which creates a statement that disables Security Manager. This routine then allows the execution of malicious code. It also checks if the running system is Windows and determines the parameters passed from the HTML that points to the URL of malicious binary.

It then downloads BKDR_POISON.BLW and saves it in a temporary folder using the file name update.exe. The malicious Java applet then deletes the binary once executed.

Based on our analysis, the backdoor BKDR_POISON.BLW was found to download and execute other malware onto the system, which leaves the system open to further infection. It is capable of capturing screen shots, webcam, and audio recording from the infected system. This zero-day exploit also reportedly works on Mac OS X platforms, thus Mac users should also be wary of this threat.

JRE 1.7 Zero-Day Exploit and Targeted Attacks

While some reports have gone on to say that this particular zero-day exploit might be used in targeted attacks, our analysis showed that this may not be the case. The sites where the exploit is hosted are known distributors of various malware. The server that BKDR_POISON.BLW connects to is also a known C&C used by malware. Targeted attacks are known to stay under the radar to successfully operate. The domains/IPs this attack use alone say that there was no intention of staying hidden.

Trend Micro Protection

Trend Micro protects users from this threat via Smart Protection Network™, which detects and deletes the exploit and its malware components. It also blocks access to compromised sites where the infection start points reside. Deep Security users are protected from the exploit by applying the rule 1005170 – Java Applet Remote Code Execution Vulnerability.

Update as of August 29 4:36 AM PDT

We were alerted to reports of an email message leading to this exploit. The email purportedly contains a link to a file sharing tool, which is actually a link to the exploit. Trend Micro detects and blocks the related email messages and the link to the exploit. In addition, Deep Discovery™ catches the network activity done by BKDR_POISON.BLW.

Oracle has released an out-of-bound patch for Java which patches this zero-day exploit. The update increments the version number to Version 7 Update 7 for users on the latest JRE version; users still using Java 6 are also receiving an update that will increment their version to Version 6 Update 35. Users should immediately update their systems to protect against this threat.