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


  • Recent Posts

  • Calendar

    July 2015
    S M T W T F S
    « Jun    
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • Email Subscription

  • About Us


    Author Archive - Trend Micro




    Recently, researchers announced that a vulnerability in Samsung Android devices had been found which allowed attackers to run malicious code on vulnerable devices if they became the targets of a man-in-the-middle attack.

    In this post we will explain how this vulnerability works, and what can users do to protect themselves.

    The Vulnerability

    The stock Android keyboard on these affected Samsung devices includes some features based on the Swiftkey SDK. To implement these features, it downloads files that are specific to each keyboard language, as seen below:

    Figure 1. Downloaded keyboard file

    These files are downloaded whenever the language for the device is set up, such as when it is turned on for the first time, or after a factory data reset (where all data and configuration is deleted). This narrows down the window of vulnerability because the files will no longer need to be downloaded after the language is set, unless the user decides to update and download a language pack.
    The files contain important information necessary to each keyboard language. These include character sets and punctuation rules. However, note that the files are downloaded via HTTP, not HTTPS. (We just recently discussed why using HTTPS is a good idea.) This means that an attacker would be able to replace these files if the attacker already had the capability to carry out a man-in-the-middle attack. (There are some countermeasures designed to help defend against this attack. However, these can be bypassed without much difficulty by an attacker that can already carry out MITM attacks.)

    By itself, this would not necessarily be a problem. However, the downloaded files are saved (and were created with) permissions for the system user, which is analogous to the root and Administrator users on Linux and Windows devices. This user has elevated privileges, which means that any code that is downloaded also runs with these elevated privileges.

    The combination results in a rather clever attack: the attacker carries out a man-in-the-middle attack that replaces the files downloaded by the keyboard. The replacement files have been specially crafted so that once processed by the keyboard app, aribitrary code of the attacker’s choosing can be run on the phone, giving the attacker complete control of the device.

    Potential countermeasures

    Currently, no patch exists for this vulnerability. Samsung has indicated that they will use their Knox security solution to remotely issue a fix, but when this will be released is unclear. In the official statement released by Samsung, they only mention that they will “begin rolling out a security policy update in the coming days.” Samsung has also advised users to ensure their devices automatically receive security policy updates. Steps to configure their devices to do so can also be found in the statement.

    Until then, there are two possible countermeasures. The first countermeasure is to only connect to Wi-Fi networks that are secure, in order to prevent any man-in-the-middle attacks. This can be a problem if the user has to connect to public Internet connections. The use of a Virtual Private Network (VPN) helps secure a user’s connection in these cases.

    Secondly, the user can stop the use of the default Samsung keyboard. To do this, they have to do two things: first, select an alternate keyboard instead of the default system keyboard. This can be done under the Language and input section of the device’s settings:

    Figures 2-4. Steps to change Android keyboard

    However, using a different keyboard is not enough. The system keyboard itself has to be turned off. Unfortunately, this has to be done every time the device is turned on. This can be done under the Applications part of the settings menu:

    Figures 5-7. Steps to disable system keyboard

    These steps will mitigate the risk to the user from this vulnerability.

     



    Companies risk losing all their customers if they continue neglecting their app store presence. While malicious mobile apps do bring serious security concerns to the fore, (70% of top free apps have fake and mostly malicious versions in app stores) companies and developers also face another challenge in the form of copycats.

    For a company that needs to maintain an official mobile app on Google Play, fake or impostor apps can mean trouble for both their credibility and revenue. For users, the impact is similar, although on a more personal level. If users get fooled into downloading these apps, it can eventually lead to information theft, reputation damage, and overall dissatisfaction with the company’s brand and service.

    Companies that maintain official apps in app stores like Google Play have a big role to play in minimizing the risk of their users installing fake apps. By properly establishing their identity and their apps, they can greatly help their users sort out the real apps from the fake ones. For example: ideally, all apps are released under one developer, as is the case for the various Trend Micro apps:

    Figure 1. Trend Micro apps on Google Play

    However, we have noticed that some organizations are not able to do this. Instead, multiple developers all publish various versions of official apps.

    Figure 2. Various banking apps with different developer names

    Why is this the case? Android requires that all apps should be signed (even with a self-signed certificate). Large organizations will, of course, have different teams responsible for developing different apps. Different private keys may be used to sign any created apps, even if they are consolidated under one account. Furthermore, different accounts may be used to upload the apps, even if they’re all related to the same company.

    The practice can cause confusion among users (as seen in Figure 2), where it is not clear which is the official account. Even if the apps are consolidated under one account, outside of the Google Play store there is no way to identify that these apps as legitimate or not (since the certificate is used to identify the author). This can cause confusion if an app is legitimate or not in third-party stores.

    For developers, the main impact here is that their customers might not be able to properly identify their app and they may lose potential install base. For users, however, this can turn into a big risk, since this makes it harder to spot “legitimate” versions of the app (e.g., the developer name used might not make it clear who published the app). In addition, if the user checks what other apps were published by a specific developer there may not be other apps to be found. In and of themselves, these are not necessarily bad, however malicious apps can share these traits as well.

    How do we know who is faking it?

    Companies need to ensure that they properly identify themselves as the credible source for their apps. It is not extraordinarily difficult for organizations to adopt proper key management to allow all apps released to be signed by one key: many large companies are able to do exactly this. The solution is to implement proper key management practices; the IT department of a large organization should be capable of arranging this correctly. Ideally, all official apps should be signed by one certificate, tied to one developer account.

    For consumers, this has one benefit: all apps from an organization would show up as from one developer in Google Play, as well as third-party app stores. With official apps properly identified, this will help users identify fake apps  and prevent from inadvertently downloading them. This protects them from various problems such as information theft.

    For now, we strongly advise users to be careful in choosing which app to download. Checking all details related to the app — developer name, rating, reviews — can help identify fake apps. Additionally, installing a security app such as the Trend Micro Mobile Security and Antivirus can detect fake apps and prevent them from getting installed.

     
    Posted in Mobile |


    Mar22
    9:22 pm (UTC-7)   |    by

    Analysis by Marshall Chen, Yi Lee, and Joe Wu

    Brand owners frequently use SPF and DKIM to protect their brands from email forgery. For example, a brand owner could register the same domain name under multiple top-level domains (TLDs) (such as .com.net.org, etcetera) and announce SPF/DKIM records for all of these domains (even if they were not actively being used). While generally effective, there is one loophole: what about the .gov TLD?

    This loophole was recently exploited in a massive phishing attack against American Express, which started on March 4. The attackers sent out emails that imitated American Express notifications, which contained a link to a phishing site. We identified more than 50 distinct phishing sites used in this spam run. These were hosted on various compromised domains, and all had the format of hxxp://{compromised website}/amerrricaneaxpress/security.html.

    Figure 1. Phishing email (address and phishing URL highlighted)

    So far, this has been a fairly ordinary attack. What we found unusual was one of the supposed email addresses used by the attacker. Three addresses were frequently used in this attack:

    • AmericanExpress@welcome.aexp.com
    • fraud@americanexpress.com
    • noreplay@Americanexpress.gov

    The first two domain names (aexp.com and americanexpress.com) are both registered by American Express, and have SPF/DKIM records published. Emails with these addresses would fail SPF verification, as their IP address would be inconsistent with the authentic ones in the SPF record.

    In the third case, however, no SPF records would be published at all. Only US government bodies can register .gov domains. An SPF verification attempt would return none instead of fail, as there is no SPF record to authenticate at all (the domain is not even registered). Therefore, an email system checking for SPF records would not rule this message to be spam on those grounds alone. This may increase the risk that users would receive these spammed messages.

    Our own sources identified more than 430,000 phishing mails sent from more than 4,600 IP addresses as part of this spam run. These IP addresses were located in more than 120 countries. This spam run took place from March 4 to March 11, with most of the senders located in the United States.

    Figure 2. Distribution of spam-sending IPs by country

    Read the rest of this entry »

     
    Posted in Spam | TrackBacks (2) »


    Mar13
    12:00 am (UTC-7)   |    by

    Ransomware SeriesAnalysis by Jaaziel Carlos, Jonh Chua, and Rodwin Fuentes

    Ransomware has become one of the biggest problems for end users are as of late. In the past months alone, we have reported on several variants of both ransomware and crypto-ransomware, each with their own “unique” routines. We recently came across one malware family, detected as PE_VIRLOCK, as that not only locks the computer screen but also infects files—a first for ransomware.

    Ransomware Routine

    VIRLOCK variants may arrive bundled with other malware in infected computers. We have even seen one VIRLOCK variant in the CARBANAK/ANUNAK targeted attack campaign.


    Figure 1. VIRLOCK infection diagram

    Once inside the computer, VIRLOCK creates and modifies registry entries to avoid detection and ensure execution. It then locks the screen of the affected computer, disabling explorer.exe and preventing the use of taskmgr.exe. Meanwhile, it also checks the location of the affected system to display the appropriate image for the ransom message.


    Figure 2. Sample ransom message

    Read the rest of this entry »

     



    Information about the overall threat landscape can be gathered from many sources. One useful method is by looking at the overall activity of command-and-control (C&C) servers, as used in botnets, targeted attacks, and in attacks against the broader Internet user base.

    We are able to combine various threat intelligence sources, including feedback from the Trend Micro™ Smart Protection Network™, to get a glimpse of C&C server activity. (these are displayed in real time on the Global Botnet Map). Our findings below reflect the information we gathered throughout all of 2014. We are able to examine the location of C&C servers, the location of endpoints, as well as the malware families that use these servers.

    So what can we learn from these numbers, and can IT professionals help reduce this threat?

    Malware using more ways to ensure server communication

    We measured the most commonly used malware families, as measured by the number of command-and-control servers tied to these specific families. For all C&C server activity, these were the most commonly used families:

    1. CRILOCK
    2. RODECAP
    3. ZEUS
    4. FAKEAV
    5. BLADABINDI

    For targeted attacks, these were the most commonly seen families:

    1. DARKCOMET
    2. XTREME
    3. NJRAT
    4. GHOSTRAT
    5. START

    Some trends can be seen from these numbers:

    • Malware families that use domain generation algorithms (DGAs) like CRILOCK are well-represented in the lists, highlighting their popularity.  Despite the differences in underlying behavior (crypto-ransomware versus information stealers), DGAs are popular as they make blocking of malicious domains more difficult with relatively little added expenditure of effort on the part of attackers.
    • Compromised sites are also popular C&C servers. ZeuS/ZBOT and RODECAP are both known to use compromised sites for their C&C servers, and both families are known to use this particular tactic extensively.
    • Similarly, free web hosting providers and dynamic IP redirection services are commonly used by some malware families such as NJRAT and DarkComet.
    • Many remote access tools (RATs) that were initially used in targeted attacks have now been used in various cybercrime-related attacks as well. This highlights the increased availability of these RATs, as well as the low entry barrier to registering and setting up C&C domains.

    Taken together, these developments show how attackers are adopting more techniques to try and obfuscate the C&C servers under their control. This can make forensic analysis of these attacks much more difficult, making detection and attribution potentially problematic.

    Read the rest of this entry »

     
    Posted in Targeted Attacks | Comments Off on Investigating and Detecting Command and Control Servers


     

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