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

    10:23 am (UTC-7)   |    by

    For many users today, how they use technology is defined by mobile devices. Their primary device is not a desktop computer, or even a laptop. Instead, it’s a tablet or a smartphone. Instead of data stored on a hard drive or a USB stick, corporate data is now stored in the cloud and accessed as needed by users. If we look at the number of PCs versus smartphones sold, the trend is clear. In the 3rd quarter of 2014, analysts estimate that 79.4 million PCs were sold – compared to 301 million smartphones in the same period.

    This changes the relationship that IT people have with end users. In the past, they would have given their users PCs that they could centrally control. However, for many organizations, that policy has not been acceptable: mobile devices are thought of as “personal” in a way that PCs are not.

    The result has been the rise of BYOD, short for Bring Your Own Device. Users buy their own devices and are responsible for them, but the company pays at least some of the costs.  In theory, everyone is happy: the user gets to use a device they chose, the company sees reduced costs and increased usage of newer, more efficient IT systems. What could possibly go wrong?

    Unfortunately, BYOD can turn out not be a dream, but a nightmare. Company data ends up being mixed with personal data and thus put at a higher risk of leakage. The devices can also be compromised and used to target the rest of an organization. BYOD can turn out to be Bring Your Own Disaster.

    There have been attempts to try and fix this, but they don’t work all that well. They try to separate the personal and the work-related on the device, but for both the user and the company they’re difficult to use.

    So, what is a good solution to this seemingly intractable problem? We can look to the world of PCs for a possible solution. In a Virtual Desktop Infrastructure (VDI), users access virtual machines running on a server. Why can’t we do something similar for mobile devices?

    Let’s call it a Virtual Mobile Infrastructure, or VMI. The client on the phone will do nothing but access a virtual mobile operating system running on company servers. Because it’s essentially the same OS as they’re used to on their devices, user acceptance should be high.

    More importantly, though, a properly implemented VMI solution would not leave data at risk on the user’s device. There are many industries where this would be useful: for example, in medicine, there would be no risk that sensitive medical data would actually leave hospital servers. In industries where there are severe regulatory restrictions on how and where data can be accessed, this can allow employees to work in a more flexible manner.

    VMI is an option that enterprises looking into implementing BYOD policies should seriously consider. BYOD brings many benefits to a company, but also attendant risks. VMI helps manage those risks so that companies can fully enjoy BYOD while reducing any potential problems.

    For more information, you can watch the video below.

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

    We recently reported that the EMEA (Europe-Middle East-Africa) region experienced a surge in ransomware, specifically, crypto-ransomware attacks. It appears that these attacks are no longer limited to that region. Research from Trend Micro engineers shows that the ANZ (Australia-New Zealand) region is the latest to be greatly affected by this type of malware—this time by TorrentLocker ransomware.

    The Infection Chain

    Figure 1. Infection diagram for ANZ attacks

    The malware arrives through emails that pretend to be penal notices from the New South Wales government (referred in this entry as “NSW”) or shipping information from the Australia Post. Once users click the link, they will be redirected to a spoofed page bearing a newly-registered domain similar to the official, legitimate one.

    The page instructs users to download a file by first entering a CAPTCHA code. If correctly entered, it triggers the download of the malicious file in a zipped format from SendSpace, a file-hosting site.

    If the user opens the zipped file and executes the malware, it will connect to secure command-and-control (C&C) servers. After successful sending and receiving of information, the malware will then encrypt files in the users’ machines using Elliptic Curve Cryptography Encryption and appends the string .encrypted. Afterwards, it drops an .HTML file with decryption instructions and displays a ransom page. It also deletes the shadow copy of the infected system by executing the command line instruction vssadmin.exe Delete Shadows /All /Quiet, thus preventing the user to restore their files from back-up.

    Based on feedback from the Smart Protection Network, 98.28% of the recipients are from Australia.


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

    I do not exaggerate when I say that it is only a matter of time before your company has to deal with a targeted attack, if it has not yet. In 2014, we saw many victims grapple with an invisible enemy. A very big and recent example of this is the Sony attack which caused a lot of problems from the company, as well as the leakage of a lot of data. As threat defense experts, we strive to make the invisible visible: what are the most important things you should have learned from the cyber-attacks in 2014? What lessons can we bring into 2015?

    Secure your data in the cloud


    Accountability for cloud computing security became very clear in 2014. Cloud computing is a powerful capacity extender that is increasingly adopted by small, medium, and very large enterprises alike. And while users can expect a certain level of security under the “shared responsibility” model — such as in the way cloud service providers run cloud services and infrastructure including physical hardware and facilities — users must not forget that access to data in the cloud can be wholly compromised at their end.

    In what turned out to be a prevalent “developer bad habit” discovered in March, for instance, thousands of secret keys to private accounts were found to be accessible in GitHub, a code-sharing site. This is the equivalent of having consumer user names and passwords leaked in public forums. In some ways this is even more critical, since the exposure of the keys mean that thousands of secret company documents, applications, software can be accessed by threat actors. And since the intruder will essentially log in as the developer, he/she can wipe out entire environments or hold them hostage.

    In a much more fatal example, Code Spaces had to close down in 2014 after an attacker gained access to its control panel account and started deleting customer databases indiscriminately. For a business whose nature relies so strongly on software services, “paranoid security” should be a foregone conclusion. Cloud services have two- or multi-factor authentication options, completely private modes, or identity-/role-based management that can greatly reduce or make intrusions like this much more difficult for attackers.


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

    2015 has just begun, but we’re already seeing old problems crop up again – particularly the abuse of a lot of legitimate web sites. Since the start of the year, we’ve been seeing a significant increase in the number of spammed messages with links that lead to various Russian dating sites.

    Figure 1. Sample of dating site spam

    While messages of these types are fairly common, this recent wave is unusual in several ways. First, the level of dating site spam is higher than normal. On one day alone (January 4), we identified more than 150,000 email samples which had been received by our honeypots. These have been sent by more than 50,000 unique IP addresses.

    The senders of these messages are also unusual. These types of spam messages tend to be sent from known spam-sending IPs. That was not the case here. These senders were sent from IPs that had not been used to send spam before. In addition, these IP addresses appear to be part of /23 or /24 IP address blocks, without any associated domain names (or meaningless ones).

    These spam-sending IPs are located in a wide variety of countries. Of the more than 50,000 spam-sending IPs we mentioned earlier, only Iran has a double-digit share with 11.37% (more than 5,700 IPs). The rest are distributed across various countries, with Spain, Vietnam, Argentina, and Germany rounding out the top five.

    The links in these spam messages do not directly lead to the dating sites. Instead, they pass through various message boards that contain spammed post with full-length versions of the pitches in the emails:

    Figure 2. Spammed post on message board
    (Click for full-size version)

    These message boards do not appear to be complicit in these attacks; we believe they have been victimized by various bots that target these forums. Large numbers of forums have been targeted; in one day alone, we saw emails that sent links to more than 700 different forums. Sites that run on phpBB and Discuz!, both popular forum software, have been targeted in this manner. These sites are generally ranked as non-malicious, which may help evade spam filters.

    While dating site spam is currently being sent in this manner, we can’t rule out further attacks that take advantage of similar methods to try and evade spam filters; we currently block these types of spam messages and will block any similar types that appear in the future.

    With additional analysis from Jimmy Lin, Jon Oliver, Matt Yang and Yi Lee

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

    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  


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