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

  • Mobile Vulnerabilities

  • Zero-Day Alerts

  • Recent Posts

  • Calendar

    August 2014
    S M T W T F S
    « Jul   Sep »
  • Email Subscription

  • About Us

    Archive for August 21st, 2014

    In the past few weeks, an exploit kit known as FlashPack has been hitting users in Japan. In order to affect users, this particular exploit kit does not rely on spammed messages or compromised websites: instead, it uses a compromised website add-on.

    This particular add-on is used by site owners who want to add social media sharing buttons on their sites. All the site owner would have to do is add several lines of JavaScript code to their site’s design template. This code is freely available from the website of the add-on.

    The added script adds an overlay like this to the site’s pages:

    Figure 1. Added share buttons

    To do this, a JavaScript file on the home page of the add-on is loaded. This alone should raise red flags: it means that the site owner is loading scripts from an external server not under their control. It’s one thing if it loads scripts on trusted sites like Google, Facebook, or other well-known names; it’s another thing to load scripts on little-known servers with no name to protect.

    As it turns out, this script is being used for malicious purposes. On certain sites, instead of the original add-on script, the user is redirected to the script of FlashPack, like so:

    GET http://{add-on domain}/s.js HTTP/1.1
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20101203 Firefox/3.6.13
    Accept: */*
    Accept-Language: en-us,en;q=0.5
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 115
    Connection: keep-alive
    Referer: {victimized website}
    Host: {add-on domain}

    The text above is the HTTP request for the script of the add-on, with the URLs partially obfuscated. Below is the reply from the server:

    HTTP/1.1 302 Found
    Date: Thu, 14 Aug 2014 02:39:45 GMT
    Server: Apache/2.2.26 (Unix) mod_ssl/2.2.26 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/
    Location: {exploit kit URL}
    Content-Length: 386
    Connection: close
    Content-Type: text/html; charset=iso-8859-1

    Note that loading the s.js file directly will simply load the “correct” script for the add-on. One site which, if found in the Referer header, will trigger the exploit kit is a well-known free blogging site in Japan. The exploit kit delivers various Flash exploits to targeted users; in at least one of these cases a Flash vulnerability (CVE-2014-0497) which was patched in February was used in the attack. We have seen that  TROJ_CARBERP.YUG is downloaded onto the affected system.

    The attack itself is aimed heavily at Japanese users. At least approximately 66,000 users have been affected by this attack, with more than 87% of these coming from Japan. The landing pages of the exploit kit are hosted in servers in the Czech Republic, the Netherlands, and Russia.

    Number of Hits by Country-01

    Figure 2. Number of hits by country from August 1 to 17

    How can users and site owners prevent these attacks? Site owners should be very cautious about adding add-ons to their site that rely on externally hosted scripts. As shown in this attack, they are trivial to use in malicious activities. In addition, they can slow the site down as well. Alternatives that host the script on the same server as the site itself are preferable.

    This incident illustrates for end users the importance of keeping software patched. The vulnerability we mentioned above has been fixed for half a year. Various auto-update mechanisms exist which can keep Flash up to date.

    Trend Micro products and solutions block the sites and detect the malicious files that are part of this attack. In addition, the browser exploit prevention technology that is a part of our endpoint solutions is capable of preventing this attack from taking place in the first place.

    With additional insights from Walter Liu

    Update as of 7:30 PM, August 24, 2014

    We updated the total number of affected users by this attack.

    Posted in Bad Sites, Malware, Vulnerabilities | Comments Off on Website Add-on Targets Japanese Users, Leads To Exploit Kit

    Vulnerabilities in apps are always a cause for concern, especially when said apps handle sensitive information, particularly financial. We examined two popular in-app payment (IAP) SDKs—Google Wallet and the Chinese payment platform Alipay—and discovered that these contain a vulnerability that can be exploited for phishing attacks. The versions we analyzed were Google IAP versions 2 and 3 and Alipay SDK 1.0.

    We have notified the developers of these findings. As of this writing, Alipay has patched the vulnerability. Meanwhile, Google is encouraging developers to use a newer version of its platform, which offers better security. They have also notified developers of several apps who are using the specific SDKs.

    The Issue with Intents and Intent-Filters

    The vulnerability is related to the intent and intent filter used by the apps. The intent is a “messaging object” that can be used to request an action or process from an app component. They (intents) can be used for communication between app components. Explicit intents are used if the developer wants an action to be performed by a specific component in a specific app. Implicit intents are used when a developer allows the process to be performed by components of other apps. For example, if an app needs to show the user a specific location, it can allow a different app to receive the GPS location.

    The Android platform uses intent-filters of apps to determine which app can perform the implicit intent. If an app contains the matching intent-filter, it can perform the task requested by the intent.

    There appears to be a flaw in the communication between the mobile payment application and the payment client applications. The mobile payment apps used an implicit intent, which can be intercepted by a malicious app via a high priority intent filter. An intent filter can be made “high priority” by combining several system APIs.

    The Flaw in the Google Wallet SDK

    For transactions involving the affected Google Wallet SDK, the app must communicate with the Google Play app on the device so that Google Play can notify the user about the payment and then request confirmation.

    Figure 1. Confirmation message

    However, the IAP SDK uses an implicit intent,  ACTION=”,” which can be intercepted by the intent filter action android:name=””  A malicious app can use the same intent-filter to display a phishing page such as the one below.

    Figure 2. Sample phishing message

    Phishing Via the Alipay SDK

    Alipay has the same process as that of Google Wallet. After the user clicks the “pay” button, the app will communicate with the Alipay mobile client so that the client will display a confirmation message. And just like the flaw in Google Wallet, the communication can be intercepted by a malicious app by using the same intent-filter. In this case, the intent filter is action android:name=”” The malicious app can then send its own message in lieu of the legitimate message.

    Figure 3. Fake Alipay message


    Third party apps employ Google Wallet or Alipay SDK  to communicate to the legitimate Google Wallet or Alipay  SDK and for real payment process. The purpose of the said SDK is to send the pay intent to the Google Wallet or Alipay. A malicious app can replace the real Google Wallet or Alipay to receive the payment intent.

    For example users make a payment via third party apps and of course, they expect to see the legitimate Google Wallet or Alipay. In this case, however, a phishing app may come out to appear like the real Google Wallet or Alipay. As such, users may trust the phishing app and input his/her password and bank account details.

    Phishing and Financial Loss

    These fake messages show the potential for phishing attacks. However, phishing attacks could just be the beginning. Once cybercriminals have access to user accounts, they can then proceed to steal information stored in the account. Given that the affected apps handle payments, it’s a very likely that credit card and other payment information could be stolen. They can then use that information or sell it in the cybercriminal underground.

    Moreover, users may not suspect these malicious messages. Since the apps handle payments, they might assume that the messages are simply intended to confirm the accounts before proceeding with the actual payment.

    Fixing the Flaw

    Developers should always use explicit intents for processes dealing with sensitive information. In such cases, only the desired app will be able to perform the process, minimizing the possibility of interception via malicious app. However, explicit intents are not enough. Developers can also require that their apps check for the signatures of other apps as proof of their legitimacy before communicating with them.

    As previously mentioned, we informed Google and Alipay about this issue on May 27th. Alipay fixed the issue by July 18th, rolling out the SDK version 2.0. Google has informed us that the current IAP code includes code that uses an explicit intent. We advise developers to use these new versions for their applications. Google has also stated that they are currently monitoring for and have not seen any evidence of exploits of the said vulnerability.

    We continue to actively monitor for any threats that may take advantage of this vulnerability. We advise users to install security software in their mobile devices to detect and block malicious apps that may take advantage of vulnerabilities such as this one.

    Posted in Mobile, Vulnerabilities | Comments Off on Vulnerability in In-App Payment SDKs May Lead to Phishing


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