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

  • Recent Posts

  • Calendar

    September 2014
    S M T W T F S
    « Aug    
  • About Us

    The introduction of personal devices (or Bring Your Own Device) into the workplace brings about issues about control and data protection. BYOD has not only blurred the lines between corporate and personal data but it has also ushered in risks, such as lost or stolen devices or data breaches via employee-owned devices.

    Enter mobile device management (MDM). Mobile device management allows IT administrators to secure and monitor corporate data and apps found in personal devices. And yet, MDM is not without some drawbacks.

    Cause for Concern

    One of the major concerns for mobile device management remains to be security. A Black Hat conference presentation this year highlighted some of the possible security risks associated with MDM. Their demonstration revealed that vulnerabilities were present in these security tools. Some of these include “ignoring authentication” and “sending login tokens without encryption.” The researchers even found that it was possible to launch an attack that can mimic a phone’s identity on the attacker’s device.

    This isn’t the first time this concern has been raised over MDM. Last year’s Black Hat Europe conference also featured a presentation about attacks against MDM. This presentation focused on the ways an attacker can extract sensitive information, specifically through the use of “spyphones.”

    Rethinking MDM

    These attack scenarios show that rather than becoming a method of security, MDM has the potential to become yet another attack surface. This is the very reason why companies need to be discerning when it comes to selecting the right tools and interfaces to protect their devices.  Enterprises looking to utilize a MDM-type of environment should look for the following features.

    Simplified User Experience. Employees should be able to install the necessary programs or apps easily into their devices. The MDM apps should be available for different platforms like Android and iOS. The apps should provide a familiar and fluid experience for both smartphones and tablets, ensuring that employees can easily navigate within the apps.

    Using apps that provide a familiar experience for employees addresses the problem that often arises with the use of container technology, a technique often used in BYOD environments. Container technology allows the IT department to manage a specific, “cordoned off” section of the employee’s device. This container has all the corporate apps and data.

    Unfortunately, most apps in the container have a different user interface (UI) that employees, which might put off employees. Additionally, “secure” containers depend on the integrity of the host system. This means that once the host system has been compromised, the contained portion becomes less secure. It should be noted that the corporate data and the apps are still located in the employee’s device; these aren’t fully controlled and hosted by the company’s IT team. This set-up may pose a severe problem should the device be stolen or lost by the employee.

    Simplified Management. IT admins should be able to centrally manage all users from a single console, allowing for ease and visibility. Options such as managing by profile are highly advantageous. Of course, one feature that IT administrators should look for is easy deployment of the system.

    Security.  Security should be the top concern for enterprises. They need to look for solutions and options that prioritize securing the work-related apps and data. They can even look into options that stores the apps and data in separate, secured corporate, to be managed by the company’s IT administrators. This can address the issue of stolen or lost devices, as the apps and data are stored on the servers and not on the device. Employees should be provided a secured environment within their device—often a virtual workspace—to ensure that data remains protected from possible attackers.

    Building Blocks of Security

    Of course, no two enterprises are alike. They may require MDM configurations or set-ups that are unique to their environment. However, all businesses can use the features mentioned in this entry as the building blocks for creating a secure and safe BYOD environment. Once these “blocks” are in place, IT administrators will have an easier time monitoring and protecting the corporate data and apps that can be found in the employees’ devices.

    Enterprises looking to secure employee devices may consider Trend Micro™ Safe Mobile Workforce™. Safe Mobile Workforce allows IT administrators complete control of corporate data assets without being obtrusive to employees.

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

    Cryptolocker, a refinement of Ransomware with file-encryption capabilities emerged in the wild last October 2013. It continuously evolves as seen in the inclusion of new tactics and methods to avoid early detection and convinces unsuspecting users to pay the ‘ransom’ to get their files back.

    Cryptographic Locker Ransomware

    We recently spotted a ransomware variant that claims to be Cryptolocker. Trend Micro detects this as TROJ_CRITOLOCK.A. Dubbed as Cryptographic Locker ransomware, TROJ_CRITOLOCK.A has an MSIL compiled packer, which means that it needs a .NET framework in order to work, as opposed to the previous Cryptolocker version.

    TROJ_CRITOLOCK.A encrypts a wide array of files with extensions such as .DOCX, .PSD, .RTF, .PPT, .PPTX, .XLS, .XLSX, and .TXT, among others. It then renames these encrypted files to {original file name and extension}._clf. It uses a Managed Version of Rijndael Symmetric Algorithm, which is different from Cryptolocker’s asymmetric algorithm.


    Figure 1. TROJ_CRITOLOCK.A displays this wallpaper on infected systems 

    Based on our analysis, once TROJ_CRITOLOCK.A encrypted the files on the infected system, it displays the following message informing users that their files have been encrypted. It then demands users to pay a ransom amount in bitcoins in order to retrieve a “private key” for users’ encrypted files.  The bitcoin price will then depend on the packet the C&C server sends along with the bitcoin address. At the time of infection, we received a request 0.2 bitcoin ransom.


    Figure 2. Users are asked to pay ransom via bitcoins

    The malware also randomly generates the “key” and “initialization vector” on the affected machine. It sends this information to its C&C server. In addition, it gathers certain system information and connects to certain URLs to send and receive information, thus compromising the system security. It also terminates several processes.


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

    Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), are designed to provide a secure, encrypted connection between a client and a server online. For further authentication and encryption, the server is required to provide certificates. By doing so, the server can prove its identity directly and effectively.

    With an SSL connection, both sides can guarantee the validity and security of the communication. This is especially advantageous for services, such as online banking, email, social networks, which require secure tunnels to exchange data between clients and servers.

    Unfortunately, this technology has become a double-edged sword. Android malware are now utilizing SSL to hide their routines and to evade detection.

    Use of SSL Servers

    SSL servers have become a target of Android malware. Malware can use any of the three types of servers.

    Unknown self-hosting servers - By maintaining an unknown self-hosting SSL server, malware authors need to build a custom TrustManager (which can decide to accept credentials) and SSLSocket that will make its malicious app trust the server’s certificate. Creating a custom TrustManager and SSLSocker is required because the malware server’s certificates are not usually included as a default in the Android OS. This often requires much effort: when a server or domain is changed (often as a reaction to AV detection), the SSL connection may fail during verification. Malware authors have to update both the certificate and client app to re-establish the connection. In addition, working with self-signed certificates and static servers will be easily and quickly detected by security companies. It’s little surprise that few malware go for this method.

    Known public web-hosting SSL servers - Considering the difficulty in maintenance for self-hosting SSL server, making use of known public web-hosting SSL servers is much more convenient. These servers and domains are often public, stable, and authorized. They have certificates which are often signed by Trusted Third Party (TTP) certificate authorities (CAs).By default, the Android OS will trust these certificates since these CAs are already pre-loaded into the system default truststore. Malware authors can fake their identity and host malicious services on these known web-hosting servers to provide encrypted connections with those infected devices.

    For example, a malware detected as AndroidOS_Exprespam.A, hosts a malicious backend service on a well-known US web-hosting server, which also provides HTTPS connection with a certificate issued by RapidSSL CA.With the authorized certificate, the malicious app can simply upload stolen information to the server via HTTPS without the need to customize the TrustManager.

    Figure 1. Certificate of the known server

    Figure 2. Information is posted via HTTPS to the server

    Known public services - Android malware can also take advantage of known public services for attacks. Based on our analyses, three types of application services are frequently exploited by Android malware: e-mail over SSL, Google Cloud Messaging (GCM) for Android, and popular social networks. By using known public services based on SSL, attackers can launch command-and-control (C&C) attacks easily and without calling attention to themselves.

    The Abuse of Known Public Services

    We have observed several Android malware exploit the aforementioned public services:

    Use of email - ANDROIDOS_GMUSE.HNT pretends to be a file manager app. This malware steals user and device information, such as the IMEI, phone number, and images stored in the SD card. Whenever the user starts the app or once the phone reboots, the app will start a backend service to dump the aforementioned information and use a hard-coded Gmail account and password to send the information to a particular email address.

    Figure 3. Snippet of code including the Gmail account

    Google Cloud Messaging - ANDROIDOS_TRAMP.HAT attempts to disguise itself as an official Google service. It collects user information like the phone number, location, and contact list. Upon execution, it registers GCMBroadCastReceiver. The malicious app will then post the stolen data via Google Cloud Messaging. Google Cloud Messaging is used for C&C communication of the malicious app. Commands such as “send message,” “block call,” and “get current location” are sent and received via Google Cloud Messaging.

    Figure 4. Malware uses Google Cloud Messaging to track current location

    Popular social networks - ANDROIDOS_BACKDOORSNSTWT.A triggers its C&C attack through Twitter. The malware crawls for Twitter URLs and combine the obtained information with a hard-coded string to generate a new C&C URL for attacks. The stolen information is sent to the generated URL.

    Figure 5. ‘this.WILLIAM’ contains the crawled strings 

    The SSL (Dis)Advantage

    There are several possible reasons why cybercriminals are using SSL. Compared to plaintext transmission, data sent through SSL cannot be easily uncovered. Some dynamic analysis methods based on TCP traffic monitoring may not work well.

    Cybercriminals may have also targeted SSL servers and services because because they do not need to exert much effort into gaining access to these sites. They can do so via normal and legal means, such as buying a virtual host from web-hosting services or registering a new account on Twitter. Should we see more use (and abuse) of SSL, detecting malicious apps may not be enough. Collaboration with server providers and services will be needed in removing related URLs, email addresses, and the like.

    Given the constant evolution of Android malware, we advise users to download Android apps only from legitimate sources. Third-party app stores may not be as strict when it comes to scanning for potentially malicious apps. We also advise users to use a security solution that can detect and block threats that may cause harm to mobile devices.

    We have notified Google about this issue.

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

    We have previously discussed about certain file locker apps that fail to hide files properly. We recently came across yet another file locker app, AppLock, which has the same issue. However, the vulnerability concerning this app goes beyond improperly hiding files—the vulnerability can allow other apps to manipulate the app’s configuration files. The configuration files include data such as the application’s preferences files, login passwords and emails, and even the Google Ad Publisher ID, which is used for Google AdSense accounts.

    Access to Configuration Files

    When a user tries to “lock” or “hide” a file, the app just moves from its original location into specific location on the SD card, which is a subpath under /sdcard/.MySecurityData/dont_remove/. The “hidden” file is neither encrypted nor encoded in any way. Information related to the file, such as the file name, the extension and the timestamp, will be inserted in a world-readable database in the SD card, with the path /sdcard/.MySecurityData/dont_remove/ 6c9d3f90697a41b. And because this database is world-readable, any app can actually read or access this database.

    Bad guys can use this access to manipulate the app’s configuration files. One way to manipulate the files is to alter the app’s Google Ad Publisher ID. As mentioned, this ID is used for Google Adsense, as a way to generate income by ads. Attackers can begin this by locking a file then by accessing the database.

    Given that the database is stored in the SD card, no special or unique permissions are required to edit the files. It only requires the permissions commonly used to read and write the files, android.permission.MOUNT_UNMOUNT_FILESYSTEMS and android.permission.WRITE_EXTERNAL_STORAGE.

    Figure 1. Reading the database

    Attackers can then create a fake Google Ad configuration file and put it in a specific path. The database can then be updated to point to that particular path, triggered by the “unlock” function of the app. As illustrated in the screencap below, the configuration file was successfully changed.

    Figure 2. Fake Google Ad configuration file was successfully inserted

    User Information Leakage

    Manipulating the configuration files can also open the door for data leakage. Cybercriminals can update the media table of the database file and change the paths directories. Once the unlock function is triggered, the media table can be copied to an accessible directory in the SD card. The stored password and email account can then be leaked.

    Figure 3. The email address and password can be seen

    The password is encrypted but this can be decrypted through an decrypter service or MD5 rainbow tables.

    Figure 4. Encrypted passwords can be obtained via different tools

    Crashing the Application

    Manipulating the configuration files can also result in the application crashing. If someone includes a non-existent path in the file, the app will pause for several minutes and finally crash.

    Losses for Developers and Users

    The accessibility of the configuration files spells trouble for both developers and users. The developers can lose income if their connection to their Google AdSense account is cut. For users, a major concern would be the potential data leakage of their account credentials and their email accounts.

    We have notified both the developers and Google about this issue in early August. As of September 4, the developers of AppLock have stated that a new version of the app will be made available, which addresses the issues discussed in this entry.


    Update as of September 18, 2014, 11:53 P.M. PDT:

    The developers of AppLock have informed us that the updated version (version 2.03) of their app is now available on Google Play.

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

    We have been investigating the MIRAS malware family, which was recently linked to attacks that targeted a Europe-based IT company. Our analysis shows that MIRAS, or BKDR64_MIRAS.B is a 64-bit malware that was used for the data exfiltration stage in a targeted attack. MIRAS is available in 32-bit (BKDR_MIRAS.B) and 64-bit (BKDR64_MIRAS.B) Windows operating systems.

    An analysis of BKDR64_MIRAS.B

    To serve as an overview for MIRAS, the backdoor’s capabilities mainly include file/system manipulation, which indicates that attackers know the victim’s credentials.

    Apart from the backdoor’s information-stealing routines, it appears to specifically target systems connected to a Remote Desktop (RD) Session Host. It uses the RD services API, WTSEnumerateProcesses instead of the usual Process Status API, EnumProcesses. The attackers are also capable of listing running processes, from which we can surmise that they now know how their targeted users log in to their work stations (i.e. through RD session host server).


    Figure 1. BKDR64_MIRAS.B uses the remote desktop services API ‘WTSEnumerateProcesses’


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


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