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

    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.

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    The past week has seen some interesting news in the world of online security. First, the US government announced that all websites maintained by federal agencies must be using HTTPS by the end of 2016. Second, the Wikimedia Foundation (best known for Wikipedia) announced that they, too, were rolling out mandatory HTTPS for their own sites as well, with full completion expected “within a couple of weeks”.

    With large organizations moving to full-time HTTPS, and browser vendors pushing for it as well (Mozilla has gone on record that eventually, new features will only be for sites running HTTPS), is it time for smaller site owners to make the move as well? Should end users pressure their favorite sites to adopt HTTPS? Will it really help online security?

    The short answer is yes. Site owners should strongly consider enabling HTTPS for their sites. It’s been clear to many people that in the long run, meaningful adoption of HTTPS would increase the security of the Web. Web giants such as Google and Mozilla, plus international bodies like the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C) have all spoken out in favor of this. Sites that are being set up now should use HTTPS from the start. That’s the direction the web is going today, and a site that’s being set up now should be built with the safety and privacy of its users in mind. For existing sites, enabling HTTPS as soon as is practical is something that owners should strongly consider, especially if sensitive data is being handled.

    Another thing to consider for website administrators is that in the long run, search engines may make HTTPS usage part of their ranking algorithms. Google is already doing just that. While for now it’s not a particularly significant “signal”, down the road that could change. It’s a good idea for site owners to get ahead of the curve and move their users to a more secure and private web.

    HTTPS: A Good Start

    It is important to note that while the mandate to adopt HTTPS is a very important step to improve online security, the effort should not stop there. HTTPS is definitely an improvement, but it is not perfect and is far from a cure-all when it comes to online security.

    Think of it as the equivalent of sending a letter in a secure container; a safe, for instance. An attacker could replace the entire container by their very secure but fake safe, steal the letter after it’s opened (steal the decrypted data from the user’s own machine), or send the user a very secure safe with a bomb inside (direct the user to a malicious  site through a secure channel).  HTTPS deals with the issue of security “in transit”, i.e., while the data is being sent across the Internet. It doesn’t solve other problems with online security, and was never meant to.

    These developments to make HTTPS implementation a norm on the Web is definitely a step into the right direction and it is crucial for website owners to follow suit.

     

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    The recent Duqu 2.0 targeted attack used several zero-day vulnerabilities as part of its attack. One of the vulnerabilities used was CVE-2015-2360, which was fixed by MS15-061 as part of the June Patch Tuesday release. Like CVE-2015-1701, this is also in the Win32k.sys file, which is commonly targeted by attackers to bypass existing vulnerability mitigation techniques.

    The vulnerability lies in how windows are handled by the operating system. Some background information about this is necessary:

    1. If an application wants to show a window, it needs to perform two steps:
      1. Registering a window class. This will lead the OS kernel to create a window class object, which exists in kernel space and an application program cannot access it directly from user mode. The structure is named tagCLS. The window class object specifies the window ‘s style and behavior.
      2. Creating a window with the window class object which was registering in the previous step. The progress will lead the OS kernel to create a window object, which exists in kernel space and application program cannot access it directly from user mode. This structure is named tagWND.
    2. Every window has a window procedure to handle window messages. The window procedure can be run in user mode or kernel mode. It depends on the window class object’s file named CSF_flags. If the CSF_flags field has the flag “Server Side Proc”, the window object’s window procedure can be run in kernel mode. If it does not have the flag, the window object’s window procedure can be run in user mode. If one application program provides its own window procedure which is not the default window procedure, the window procedure only runs in user mode: the window class object’s CSF_flags field doesn’t include “Server Side Proc” flag.

    Figure 1. tagCLS structure

    From Figure 1, we can see the tagCLS structure’s CSF_flags field is a 32-bit number. Every bit represents one Characteristic. The first bit is the flag for the “Server Side Proc” characteristic.

    1. win32.sys has a characteristic that it will switch to user mode to run some user mode callback functions to do some work which is fit for user mode. This is frequently exploited by attackers.

    Let’s take a look the vulnerability. The vulnerability can be summarized in the following figure:

    Figure 2. Vulnerable message handling process

    When a window message is received (for example, from WM_SetIcon), the kernel will handle the message. The process is lengthy. In the above illustration, I only included the parts which are related to the vulnerability. The vulnerability exists in the step 4: it doesn’t check that the tagCLS object is valid after it switches back from user mode and continuously does some operation on the tagCLS object. This poses a serious security risk

    Exploitation

    This type of vulnerability is not very easy to exploit, because the attacker needs to be very familiar with the working model of win32k.sys This type of vulnerability can be exploited with several common techniques; I list one possibility below:

    Figure 3. Possible exploit methodology

    After step 7, the attacker can create a window with the modified tagCLS object which has “Server Side Proc” flag. The window’s procedure can be run in kernel mode. This means that the attacker can now run their code with elevated kernel mode privileges, effectively allowing for a complete compromise of the affected system.

    Solutions

    The most effective solution for this vulnerability is to roll out the appropriate official patch. It is also worth noting that this vulnerability is only an escalation-of-privilege vulnerability. Other attack techniques are necessary to get code running on the targeted system in the first place; solutions that focus on preventing and detecting these may also be useful to administrators.

     

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    It doesn’t take an advanced malware to disrupt a business operation. In fact, even a simple backdoor is enough to do it.

    Earlier this year the Trend Micro Forward-Looking Threat Research Team closely monitored the operations of two Nigerian cybercriminals — identified through aliases Uche and Okiki — who attacked small businesses from developing countries to steal information and intercept transactions with their targets’ partners. All this was done through HawkEye, a simple backdoor that costs around $35.

    While the malware used is simple, the cybercriminal operation itself is not. The operations run by Uche and Okiki, the cybercriminals we investigated on, move away from what we normally see in one-man operations where stolen information is simply sold off to others. Uche and Okiki made use of the information they captured in looking for more opportunities to steal from their victims.

    Taking their Time

    Unlike in typically-seen operations where cybercriminals prefer the “smash and grab” technique — where they send out spam emails with a malware attachment and bank on the chance that the victim runs it — Uche and Okiki took their sweet time engaging with their victims. Specifically targeting company mailboxes meant to receive inquiries from external parties, the cybercriminals sent emails to their targets that didn’t come with any malicious attachment or agenda, and actively communicated with them.


    Figure 1. Sample of actual email sent out by Okiki to his targets

    Once they have gained their targets’ trust, they then used the context of their communication to send HawkEye, ensuring infection and system compromise.

    Bigger Payout

    Instead of aiming to steal information like online banking or social networking credentials, Uche’s and Okiki’s schemes had a different target: the company webmail account. This difference in strategy created more opportunities for these cybercriminals, as getting access to the target’s company email gave them visibility of correspondences between the target and their partners and customers, their transactions and all other information.

    With access to their victims’ transactions, Uche and Okiki used this visibility to launch more schemes which varied from targeting the victims’ affiliates, performing lateral movement to their targets’ bigger offices, to conducting “change of supplier” fraud.

    The “change of supplier” fraud scheme is one that we think brought bigger payouts for Uche and Okiki, since it involves intercepting communications between a supplier and their customers in terms of payment details. What the cybercriminals do is send an email to the customer using the victim’s account (in this case, the supplier) to wrongly inform them that the account details to where they can send in their payment has changed. What is then provided is not an account owned by the supplier, but by the cybercriminal himself. “Change of supplier” schemes ran using Predator Pain and Limitless in the past netted attackers up to $75 million US dollars.

    Big Threat to Small Businesses

    Our findings on these operations show how clever cybercriminals can get in using the tools and information they have in order to steal as much as they can from their targets. This level of focus from cybercriminals, combined with the challenges small businesses face in building a solid security strategy for their network, make up a scenario that is strongly in favor of the bad guys.

    Our full documentation of Uche’s and Okiki’s operations and technical analysis of HawkEye are all in our research paper, Piercing the HawkEye: Nigerian Cybercriminals Use a Simple Keylogger to Prey on SMBs Worldwide.

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    Adobe may have already patched a Flash Player vulnerability last week, but several users—especially those in the US, Canada, and the UK —are still currently exposed and are at risk of getting infected with CryptoWall 3.0. The Magnitude Exploit Kit included an exploit, detected as SWF_EXPLOIT.MJTE, for the said vulnerability, allowing attackers to spread crypto-ransomware into their target systems. We first saw signs of this activity yesterday, June 15, through our monitoring of threat intelligence from the Trend Micro™ Smart Protection Network™.

    This particular vulnerability, identified as CVE-2015-3105, was fixed as part of Adobe’s regular June Update for Adobe Flash Player which upgraded the software to version 18.0.0.160. However, many users are still running the previous version (17.0.0.188), which means that a lot of users are still at risk.

    As of this week, these are the top 10 countries most affected by this threat:

    1. United States
    2. Canada
    3. UK
    4. Germany
    5. France
    6. Australia
    7. Italy
    8. Turkey
    9. India
    10. Belgium

    Ongoing Exploit Problem

    This is another example of how cybercriminals rapidly take advantage of recently-patched vulnerabilities through exploit kits. We saw a similar incident in March, where exploits for an Adobe Flash Player vulnerability were added to the Nuclear Exploit Kit just a week after the patch was released. We also noted earlier this month that Flash Player was being targeted more frequently by exploit kits, and that shows no sign of changing soon.

    Figure 1. Flash version used in testing

    The SWF sample we acquired is heavily obfuscated using secureSWF, and uses two shaders for the actual exploit code.

    Figure 2. Shaders used in exploit code

    Widely-used exploit kits such as Magnitude are often well-maintained with new vulnerabilities. Our research on these tools reveals that Magnitude is one of the most used exploit kits by cybercriminals along with SweetOrange and Angler.

    CryptoWall is also another notable threat in and of itself. We initially saw CryptoWall last year spreading through spam, and again later this year partnering with information stealing malware FAREIT.

    Figure 3. Ransomware demand page

    Trend Micro is already able to protect users against this threat. The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can be used to detect this threat by its behavior without any engine or pattern updates.  Meanwhile, the Browser Exploit Prevention feature in the Endpoint Security in Trend Micro™ Smart Protection Suite blocks the exploit once the user accesses the URL it is hosted in. Browser Exploit Prevention protects against exploits that target browsers or related plugins.

    We recommend that users stay up-to-date with the latest Flash Player version, and this incident is an excellent reminder of just how important it is to do so. We also note that Google Chrome automatically updates its own included version of Flash Player.

    The malicious Adobe Flash exploit is detected as SWF_EXPLOIT.MJTE. Below is its SHA1:

    • 16ad317b7950c63720f9c7937a60ee3ea78cc940

    Additional analysis by Brooks Li and Joseph C Chen

    Update as of June 16, 2015, 8:30 A.M. PST: We have updated the entry to include the detection name for the exploit.

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  



     

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