About a month ago, the Apache Software Foundation released Struts 2.3.15.1, an update to the popular Java Web application development framework. The patch was released because vulnerabilities in older versions of Struts could allow attackers to run arbitrary code on vulnerable servers.

Since then, we’ve found that hackers in the Chinese underground have created an automated tool that exploits these problems in older versions of Struts. We first confirmed the existence of these tools on July 19; this was only three days after the vulnerabilities were disclosed to the public.

Figure 1. Advertisement for hacking tool

A hacking tool like this serves multiple uses in a targeted attack, such as:

• Acquiring information about the target
• Gaining and maintaining access onto the target’s system and network
• Stealing information
• Removing evidence of an attack

We have observed attacks against Asian targets using this specific hacking tool, which indicates these Struts flaws are being actively exploited by potential threat actors in the wild.

The Hacking Tool Itself

The hacking tool targets several different flaws in Struts. These are identified both by their Apache-issued bulletin numbers and their CVE numbers:

• S2-016 (CVE-2013-2251)
• S2-013 (CVE-2013-1966)
• S2-009 (CVE-2011-3923)
• S2-005 (CVE-2010-1870)

All of these vulnerabilities, if exploited, allow arbitrary commands to be run on the target server by an attacker. To demonstrate the capabilities of this tool, we ran it against a test environment which was running a vulnerable version of Struts.

Figure 2. Hacking tool user interface

Some specific commands can be run on the target server by the tool automatically. One of the pre-programmed commands is whoami, which displays information about the target server’s current account.

Figure 3. The generated TCP Stream.

The full list of commands that it can run is as follows:

Table 1. Integrated commands

Setting Up A Backdoor

An attacker’s goal in targeting a vulnerable server is to set up a backdoor. These backdoors allow an attacker to gain and maintain access to the server and use it as they see fit; this tool allows an attacker to do just that with relatively little effort.

The hacking tool contains a “WebShell” feature, which allows the attacker to easily plant a backdoor and a web shell onto the target. These web shells make issuing commands to the backdoor much easier, as it can be done directly from a browser window.

A variety of web shells are available for servers using various frameworks like PHP and ASP.NET; however in this particular case because Struts itself is an app framework that supports Java, the attacker can install JspWebShell, a web shell/backdoor combination that is coded using JavaServer Pages (JSP).

Figure 4. Hacking tool with WebShell feature

The screenshot below shows how JspWebShell has access to the server’s file system.

Figure 5. User interface of JspWebShell

Web shells with more powerful capabilities are easily available in the underground, such as searching for and stealing information and data from the backdoored server.

Summary

In summary, what do we know about this hacking tool?

• It was published three days after the publication date of vulnerability.
• It allows for the easy execution of operating system commands on the targeted server.
• It is possible with just a few clicks of the mouse to establish a backdoor/web shell on the target server to acquire and maintain access.
• Web shells are evolving, and features are being added to these as necessary.

As we noted earlier, this vulnerability has been patched and a new version of Struts released (2.13.15.1). Some applications may break because of the removal of several vulnerable features in the current version, but despite this Apache has said the update is “strongly recommended”. The potential risks from a successful attack outweigh the inconvenience of modifying any deployed apps.

We provide a variety of solutions against these threats. Users of Deep Security have various rules which help block Struts exploits and drop the related malicious packets. In addition, we detect the backdoors planted on affected sites as HKTL_ACTREDIR and JS_SPRAT.SM.

The hash values of the hacking tool sample are as follows:

• MD5: 4674D39C5DD6D96DFB9FF1CF1388CE69
• SHA1: 9C6D1700CF4A503993F2292CB5A254E4494F5240

Instant messaging apps are battling it out and trying to become the next popular means of communication that people will use. For example, in Japan, both Line and KakaoTalk – two popular chat apps – both claim to have more than 100 million users in Japan.

It shouldn’t be a surprise that cybercriminals are using the names of these apps for their own attacks; in this post we’ll show how KakaoTalk is being targeted by attackers. (However, let’s be clear that KakaoTalk is not being the only brand targeted; other brands and apps are also targets as well.) Users need to understand the threats posed by these malicious apps.

First example: Trojanized App

One common way to create malicious apps is to take a legitimate version of the app and add malicious code to it. This creates a Trojanized app which, to the user, can appear to be normal. However, it actually contains malicious code.

This particular Trojanized version of KakaoTalk is detected as ANDROIDOS_ANALITYFTP.A, and was distributed via email. If one examines the details of the app, one can see the differences between the legitimate app and the modified one:

Table 1: Differences between legitimate and Trojanized versions

In addition, when we examine the permissions used by the app, it’s worth noting that the Trojanized app asks for more permissions than the legitimate app.

Figure 1: Permissions of “ANDROIDOS_ANALITYFTP.A”

ANDROIDOS_ANALITYFTP.A seems to be a Trojanized app that can be used by eavesdroppers. This app regularly sends out contact information, text messages, and some phone settings to a command-and-control server from where the attacker can retrieve it.

This process of Trojanizing is made easier because most Android apps are written using the Java programming language. Unless steps are taken to obfuscate it, the source code of any Java app is relatively easy to obtain; the attacker can then add or modify the code to introduce malicious behavior into the app.

Second example: Fake app

Aside from Trojanized apps, fake apps have used KakaoTalk’s name as well. About a month ago, KakaoTalk warned users via their official Twitter account of a “KakaoTalk Security Plugin”:

Figure 2: Twitter alert from KakaoTalk

We detect the fake security as ANDROIDOS_FAKEKKAO.A. Many users have fallen victim to this not just because it uses KakaoTalk’s brand, but also because it uses “Security” in its name as well.

What does this malicious app do when it’s installed? It reads the user’s contacts and uses the phone’s text messaging feature to send messages to all contacts. Because of this, it is quite easy to notice that something has gone wrong with their device.

What’s most interesting about this fake app, however, was how it was distributed. The attackers used a hacked Google Play developer account to distribute a redirector app:

Figure 3: Redirector app

This redirector app contained ads that led to a variety of apps – including the fake security plugin. By doing it this way, the attacker was attempting to avoid scanners like Google’s integrated Bouncer service.

Best Practices

The best way to protect against these threats is to avoid downloading apps from outside of Google Play – a tip we mentioned earlier when talking about the recent Android security vulnerability. Apps arriving from outside the somewhat curated Google Play store have frequently been a source of security problems for Android devices. Even then, users should check the developer of the app they’re downloading, as well as any reviews, to verify that they are downloading legitimate apps.

On-device security solutions (like Trend Micro Mobile Security) detect even threats which arrive outside of authorized app stores, providing an additional layer of protection.

Developers, meanwhile, need to seriously consider the possibility that their apps can be Trojanized and used for malicious purposes. They need to consider putting in place the necessary defenses: obfuscation (to make analysis and Trojanizing of their apps harder) and code integrity monitoring (to ensure that alerts are raised if/when the app’s code is modified and run). In addition, if the app can be built in such a way that sensitive information is handled online – so that stealing information becomes more difficult – it would also help make apps more secure and resistant to these attacks.

Last April 23 – 25, I attended the seventh Counter eCrime Operations Summit (CeCOS VII) initiated by the Anti-Phishing Working Group (APWG). This year, the conference was held in Buenos Aires, Argentina. Security experts from Japan, Paraguay, Brazil, North America, Russia, and India flew to the South American city to discuss about the developments in the cybercrime arena. Together with 8 other participants from Japan, I arrived in Buenos Aires after a 38-hour flight. However, the talks and the level of energy in the conference definitely made the whole trip worth it.

Overall, CeCOS featured 23 sessions divided into eight tracks, including two panel discussions. Aside from attending interesting talks, I also participated as a speaker at the event.

I was very much interested in attending two talks: the National Field Reports and Mobile Attack Sessions. The National Field report particularly intrigued me, as it argues that the threat landscape of a particular country is a reflection of what’s happening globally.

By now, it’s pretty much established that the mobile platform is the latest cybercrime battlefield, so I think it’s crucial to know what’s happening in the mobile threat front.

As I mentioned earlier, I also participated as a speaker. As the representative of the anti-phishing council of Japan (CAPJ), I gave the talk Finding the Banking Trojan in Eastern Asia.

Speaking at CeCOS VII

Japanese-language phishing emails were first spotted in 2004 and since then, these mails have poured in and caused serious damage. As technology developed, these emails took more subtle forms, which made detection more difficult. In addition, instead of direct links to phishing sites or a malicious attachment, phishing sites instead contain links to compromised sites that eventually lead users to malicious sites that contain exploit kits.

As we all know, attackers are already expanding their threats to other platforms, particularly mobile. Thus, I presented my analysis of ANDROIDOS_CHEST, which targets Android OS and was reportedly found affecting South Korea. Users would receive text messages offering free coupons for either movie tickets, fast food, or coffee if the user downloaded an app, which was actually ANDROIDOS_CHEST.

The malware monitors and gathers text messages in order to defeat two-factor authentication done via text messaging. ANDROIDOS_CHEST then sends the gathered messages to the attacker.

The most important question though is, how can users protect themselves from the threats of phishing? The CAPJ has these tips:

1. Keep your computer safe.
2. Beware of suspicious emails.
3. Access and bookmark legitimate URLS.

Another helpful advice is to always keep your systems updated with the latest security patches for your system. As Banking Trojans are usually delivered through exploit kits (by way of phishimg emails), users are protected from exploits that target old vulnerabilities.

Trend Micro provides tools and technologies that help protect users against security breaches and data theft. Trend Micro DirectPass manages your passwords so that using and remembering unique passwords for multiple accounts is no longer difficult. Trend Micro Mobile Security protects against threats like ANDROIDOS_CHEST that are on mobile devices. The Smart Protection Network provides both email and web reputation, blocking these threats before they arrive on user systems.

We’re trying to make the Security Intelligence Blog better. Please take this survey to tell us how.

In this part 3 as the last entry, I will report the result of our investigation on app-related battery consumption issue and its reality.

Android Apps’ Battery Consumption Issue

According to Trend Micro research, almost 47% of smartphone users in Japan are bothered by their device’s battery longevity.

Dubbed “PC on your palm” the smartphone’s design puts prime on portability, which inadvertently leads to battery resource issues. Previously, traditional feature phone devices did not have this concern, as their manufacturing companies were directly responsible for overall development and quality assurance of device’s components e.g. from device’s operating system up to its apps.

With smartphones, users can install third-party apps that are less dependent on the devices and their respective manufacturers. On the positive side, this brought changes to the apps market, in which new players can now participate and release their own apps. In turn, this made the app market dynamic and new apps are regularly introduced.

The downside, however, is that app development is not aligned with smartphone devices and their operating systems, making quality assurance more complicated and fragmented. Because anyone can join this market, even individuals with insufficient technical knowledge can easily release an app. This could be a reason why “potentially unwanted apps” consume too much device resource.

Resource Consumption Used by Free Android Apps

Sampling the top 200 apps (both general apps and game apps) among free apps on Google Play, for August 31, 2012, Trend Micro examined their resource consumption using Trend Micro Mobile App Reputation (MAR). The details of the sampled data are as follows:

Measuring battery consumption is not an easy task since it is determined by complex combination of apps and hardware. In MAR’s investigation, we created three levels of battery consumption using various combinations of factors such as network bandwidth, memory consumption, hardware used, etc.

Read the rest of this entry »

This is the second in a series of blog posts describing the mobile threat landscape in Japan. The first one may be found here. 

Smartphone users in Japan are able to download a wide variety of apps, many of which are either inexpensive or free. Not all of these actually meet what users expect in terms of features, and some even introduce risks that users may not fully understand. In this blog entry, I will report the privacy risks caused by certain apps that we have looked into.

The Ad Delivery Cycle for “Free” Apps

As mentioned in the first entry, we define those apps that demonstrate the following routines without user consent as high-risk apps (referred as “ego apps” in Japan):

• Displaying pop-up ads
• Getting the user’s private information

One reason these apps are significantly increasing lately is the way that ads are sold in Japan.

As you can see in this graph, these ad agents/networks provide software development kits (SDKs) for app developers. By inserting the SDK-provided code into their apps, app developers can have ads appear inside their apps. They would then earn money from how many ads are viewed and/or clicked. This revenue allows the developer to charge little or no money for his app.
Read the rest of this entry »