Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    January 2015
    S M T W T F S
    « Dec    
  • Email Subscription

  • About Us

    Every Android app comprises of several components, including something called the AndroidManifest.xml file or the manifest file. This manifest file contains essential information for apps, “information the system must have before it can run any of the app’s code.” We came across a vulnerability related to the manifest file that may cause an affected device to experience a continuous cycle of rebooting—rendering the device nearly useless to the user.

    The Manifest File Vulnerability

    The vulnerability can cause the OS to crash through two different ways.

    The first involves very long strings and memory allocation. Some apps may contain huge strings in their .XML files, using document type definition (DTD) technology. When this string reference is assigned to some of the tags in AndroidManifest.xml (e.g., permission name, label, name of activity), the Package Parser will require memory to parse this .XML file. However, when it requires more memory than is available, the PackageParser will crash. This triggers a chain reaction wherein all the running services stops and the whole system consequently reboots once.

    The second way involves .APK files and a specific intent-filter, which declares what a service or activity can do. An icon will be created in the launcher if the manifest file contains an activity definition with this specific intent-filter:


            <action android:name=”android.intent.action.MAIN”/>

            <category android:name=”android.intent.category.LAUNCHER”/>


    If there are many activities defined with this intent-filter, the same number of icons will be created in the home page after installation. However, if this number is too large, the .APK file will trigger a loop of rebooting.

    If the number of activities is bigger than 10,000:

    • For Android OS version 4.4, the launcher process will undergo the reboot.
    • For version L, the PackageParser crashes and reboots. The malformed .APK will be installed but no icon will be displayed.

    If the number of activities is larger than 100,000, the devices will undergo the loop of rebooting.

    Testing the Vulnerability, Part 1

    We created an .APK file with a manifest file containing a huge string reference, as seen in Figure 1. During installation, the device reboots, seen in the logcat information in Figure 2.

    Figure 1. AndroidManifest with DTD huge string reference

    The OS crashes and reboots during installation

    We have tested and proven that this created APK could crash both Android OS 4.4.4, Android OS L, and older versions of the platform.

    Testing the Vulnerability, Part 2

    We also created an application with the manifest file as shown in Figure 3, which can make Android devices undergo a loop of reboots. After installation, the device was unresponsive, save for the rebooting. A user will not even be able to uninstall the APK or switch off the device. It will simply reboot until the device runs out of the power. The only solution is to flash the ROM or install the platform again.

    Figure 3. AndroidManifest.xml with 100,000 icons

    Knowing the Risks

    While this vulnerability isn’t a technically a security risk, it does put devices at risk in terms of functionality. This vulnerability can essentially leave devices useless. Affected devices can be “rescued” but only if the Android Debug Bridge (ADB) is activated or enabled. The only solution would be to connect the device to a computer, boot the phone in fastboot mode, and flash the ROM. Unfortunately, such actions can only be done by highly technical users as a mistake can possibly brick a device. For this issue, we recommend that users contact customer service (if their devices are still under warranty) or a reputable repair shop.

    We have notified Google about this issue.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    8:07 am (UTC-7)   |    by

    The remote access tool (RAT) HAVEX became the focus of the security industry after it was discovered to have played a major role in a campaign targeting industrial control systems (ICS). While observing HAVEX detections (known by different vendors as Dragonfly, Energetic Bear, and Crouching Yeti), we noticed something interesting.

    The Dragonfly campaign was previously believed to be compatible with only for 32-bit versions as most mission critical systems would most likely Windows XP, which has since been listed as end of support. In contrast, we came across two interesting infections running on Windows 7 systems.

    First 64-bit HAVEX Sighting

    Based on our analysis (seen in the chain below), a file called TMPpovider023.dll, detected as BKDR64_HAVEX.A, was found, which creates several files in the file system. It should be noted that TMPprovider0<2-digit version number>.dll is a known indicator of HAVEX and is the component of this threat that interacts with the command-and-control (C&C) servers to perform downloads or receive execution commands associated with it.

    Figure 1. File installation chain

    This is interesting because we’re seeing three indicators of BKDR_HAVEX:

    • The file TMPProvider023.dll, as indicated above, with the number indicating the version of this HAVEX RAT (v023)
    • A dropped file named 34CD.tmp.dll, detected as BKDR_HAVEX.SM. At this point, the file is being repeatedly detected and quarantined by the installed Trend Micro product. This was later found out to be version 29 or v029 of HAVEX.
    • C&C communication from the host and back

    Figure 2. The dropped file detected as BKDR_HAVEX.SM

    A Closer Look at the First 64-bit HAVEX Sighting

    To better understand how these two files (TMPProvider023.dll and 34CD.tmp.dll) work, we need to determine the other files that were related to the infection chain. With this, we noticed two other dropped files.


    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    With the finalization of HTML5 standard by World Wide Web Consortium (W3C) last October, there will be a rapid growth of new HTML5 web apps coming out in the near future. Considering the platform independent characteristic in web apps, we foresee that HTML5 will accelerate the repackaging from web apps to mobile apps for malicious intent.

    A Quick Overview of HTML5 Android Apps

    According to our monitoring, the amount of new HTML5-packaged apps coming to the Android platform increased by 200% in 2014 from its numbers in 2013. The numbers have noticeably gone up to 600% from its original count in 2012.

    Figure 1. Distribution of new HTML5-packaged apps in Android from 2012 to 2014

    We noticed that the amount of HTML5 packaged malware or potentially unwanted apps (PUAs) were also on the rise. Almost 50% of these mobile malware/PUAs were disguised as games.

    Figure 2. Distribution of new HTML5-packaged malware/PUAs seen in Android from 2012 to 2014

    One example of mobile malware/PUA is the app pretends to be a legitimate game called Tiny Rifles (package: com.html5.game2), an HTML5 game. Accessing the fake game on a browser loads the HTML5 game webview but also injects aggressive Adware SDK into the code. The malicious app has since been removed from Google Play. We detect this as a potentially unwanted app (PUA).

    Figure 3. Fake Tiny Rifles game

    Two Attack Methods for HTML5 Android Malware

    Based on our analysis, there are two major kinds of attack method the HTML5-packaging malwares may take:

    Method #1: Initiating local webview

    This is a popular attack method that may be carried out without modifying a single line of code from the original HTML5 app. Hackers only need to initiate a local webview to load the attached or remote HTML5/JavaScript/CSS codes. By doing this the main functionalities will work and a new Android format app can be released.

    However, most hackers will not stop at this step since it is meaningless to only convert a web app to an Android app. Hackers often inject malicious Java code into the app before releasing it.

    Figure 4. Malicious Java code injection in the HTML5-packaged apps

    By packaging apps this way, the malicious code and normal code can be separated in the source; hackers can only focus on the injected part and takes little effort to original HTML5 parts, which makes the code logic clear and simple.

    Method #2: Packaging HTML5 apps to middleware injected with malicious JavaScript code

    As Android becomes more and more popular, a lot of middleware are coming out to convenient developers to develop apps cross-platforms. Middleware is a third-party software/framework that works between apps and the operating system (OS) .

    For HTML5 and related web apps, there now several open frameworks to support cross-platform developing, such as: Phonegap, Apache Cordova, Crosswalk, Cocoonjs, and more. These middleware often support HTML5. An example is middleware Apache Cordova is famous and mostly frequently used in Android.

    Apart from running HTML5/JavaScript/CSS codes in webview, apps integrated with these middleware are running in the core of those framework libraries, usually something like deeply customized browsers. With the powerful APIs provided by these middleware, developers can interact with Android only by JavaScripts.

    Figure 5. Malicious JavaScript code injection to send SMS by Cordova execution


    HTML5 makes it easier to develop more powerful web apps and will definitely benefit Android in a certain sense since web apps are platform-independent. To developers, the cost of cross-platform developing is low and  the “write once, run anywhere” (WORA) program capability is available. There will be never platform-developing latency. To users, they may share favorite apps among different mobile platforms any time, which means that adapting HTML5 for web app development is always a win-win situation.

    While cross-platform benefits may also mean cross-platform infections, the difficulty of JavaScript code protection often makes web apps easy to be copied and repackaged. Theoretically, by the way of code injection and repackaging, hackers can pirate any web apps they want to support any platforms.

    In the foreseeable future we may be seeing a type of malware that can hit different mobile platforms (such as: iOS, Android, Windows Phone) all at the same time. To prevent from this, developers need to spend more efforts on code obfuscation or other coding tricks to secure their apps. Home users also need to take care of new app installations by only downloading from official app stores.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    A few months back, we discussed the Android Same Origin Policy (SOP) vulnerability, which we later found to have a wider reach than first thought. Now, under the collaboration of Trend Micro and Facebook, attacks are found which actively attempt to exploit this particular vulnerability, whose code we believe was based in publicly available Metasploit code.

    This attack targets Facebook users via a link in a particular Facebook page that leads to a malicious site. This page contains obfuscated JavaScript code (see in Figure 1 below), which includes an attempt to load a Facebook URL (seen in Figure 2) in an inner frame. The user will only see a blank page as the page’s HTML has been set not to display anything via its div tag (Figure 3), while the inner frame has a size of one pixel (Figure 4).

    Figure 1. Malware code segment upon opening the Facebook page

    Figure 2. Corresponding content of opened Facebook page

    Figure 3. The main page is set to be invisible

    Figure 4. The inner frame has a size of one pixel

    While these routines are being carried out, the SOP bypass is being performed. A remote JavaScript file is loaded from a legitimate cloud storage provider:


    Figure 5. The JavaScript file that performs SOP bypass

    The said file contains the malicious code of this attack and allows attackers to carry out the following activities or routines on Facebook:

    1. Add friends
    2. Like and follow Facebook pages
    3. Modify subscriptions
    4. Authorize a Facebook app to access the user’s public profile, friends list, birthday information, likes and friends’ likes
    5. Steal the victim’s access tokens and upload them to their server  at http://{BLOCKED} $token;
    6. Collect analytics data (such as victims’ location, HTTP referrer,  etc.) using the legitimate service at https://whos.{BLOCKED}

    In addition to the code at the above site, we found a similar attack at http://www.{BLOCKED} We believe both of them are created by the same author because they share several function names, as well as the client_id of the Facebook app.

    Which app was authorized?

    The client_id involved in this malware was “2254487659”. This is an official BlackBerry App  maintained by BlackBerry. We confirmed with BlackBerry and clarified that this malware is trying to take advantage of the trusted BlackBerry brand name and steal user’s access-tokens, which can be used to make requests to Facebook APIs and read user’s information or to publish content to Facebook on behalf of a person. Blackberry released this statement:

    “The mobile malware using the Android SOP Exploit (Android Same Origin Policy Bypass Exploit) is designed to target Facebook users regardless of their mobile device platform. However, it attempts to take advantage of the trusted BlackBerry brand name by using our Facebook web app. BlackBerry is continuously working with Trend Micro and Facebook to detect and mitigate this attack. Note that the issue is not a result of an exploit to Blackberry’s hardware, software, or network.”

    Google has already released fixes for this vulnerability as noted in our earlier post. However, not all users may be able to update their browser and/or Android version. Until device vendors are able to release patches, users will still be at risk.

    The threats related to this attack are detected by Trend Micro products as JS_ANDRSOPEXP.A and HTML_ANDRSOPEXP.A.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    3:18 pm (UTC-7)   |    by

    In recent weeks, a major Korean electric utility has been affected by destructive malware, which was designed to wipe the master boot records (MBRs) of affected systems. It is believed that this MBR wiper arrived at the target systems in part via a vulnerability in the Hangul Word Processor (HWP), a commonly used application in South Korea. A variety of social engineering lures were used to get would-be victims to open these files. Below is a quick overview of the attack with the infection chain starting from a spearphishing email sent to the employees’ inboxes.

    Malware Behavior

    We detect the malware as TROJ_WHAIM.A, which is a fairly straightforward MBR wiper. In addition to the MBR, it also overwrites files that are of specific types on the affected system. It installs itself as a service on affected machines to ensure that it will run whenever the system is restarted. Rather cleverly, it uses file names, service names, and descriptions of actual legitimate Windows services. This ensures that a cursory examination of a system’s services may not find anything malicious, helping this threat evade detection.

    Figure 1. List of legitimate service names used by TROJ_WHAIM.A


    Similarities to Previous MBR Attacks?

    This particular MBR-wiping behavior, while uncommon, has been seen before. We observed these routines in March 2013 when several attacks hit various South Korean government agencies resulting in major disruptions to their operations. The malware involved in this attack overwrote the MBR with a series of the words PRINCPES, HASTATI, or PR!NCPES. The recent attack on Sony Pictures also exhibited a similar MBR-wiping capability.

    There are also similarities to the previous MBR wiper attacks as well. All three attacks mentioned earlier overwrite the MBR with certain repeated strings. This attack uses the repeating “Who Am I?” string, while the Sony attack used a repeating 0xAAAAAAAA pattern.

    Figure 2. Screenshot of ‘Who Am I’ message seen upon bootup of infected systems

    Destructive Malware and Demands

    It has been claimed that the attack on Sony Pictures was because of that studio’s production of the film The Interview. While we cannot independently verify the veracity of these claims, something similar has happened with this incident. We’ve noticed a particular Twitter user tweeting his demands toward the affected company, and if not met, would subsequently release various KHNP documents. Among these demands are the shutdown of nuclear power plants in Korea (nuclear provides for 29% of South Korean electricity requirements).

    No Definitive Attribution

    While there are definite similarities in the behavior of all these attacks, this is not enough to conclude that the parties behind the attacks are also related. All three attacks have been well documented, and it is possible that the parties behind each attack were “inspired” by the others without necessarily being tied. Without sufficient evidence, we cannot make claims either way.

    These attacks highlight our findings about the destructive, MBR-wiping malware that appear to have become a part of the arsenal of several threat actors. This is a threat that system administrators will have to deal with, and not all targeted attack countermeasures will be effective. Techniques to mitigate the damage that these attacks cause should be considered as a part of defense-in-depth networks.

    With additional insights by Abraham Camba, MingYen Hsieh, and Rika Gregorio

    Update as of 11:29 P.M. PST, December 23, 2014

    Upon further analysis, we confirmed that TROJ_WHAIM.A checks if the current date and time is Dec 10, 2014 11:00 AM or later. If it meets this condition, it sets the registry, HKEY_LOCAL_MACHINE\SOFTWARE\PcaSvcc\finish to 1, thus triggering the MBR infection. Otherwise, it sleeps for a minute and checks the system time again.

    Aside from the MBR infection capabilities and overwriting certain strings, another similarity of this attack to the March 2013 incident is its ‘time bomb’ routine. A certain action is set in motion once the indicated date/time by the attackers is reached by the infected system.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  


    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice