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

  • Recent Posts

  • Calendar

    February 2014
    S M T W T F S
    « Jan   Mar »
     1
    2345678
    9101112131415
    16171819202122
    232425262728  
  • Email Subscription

  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Archive for February 18th, 2014




    Earlier we talked about some Flappy Bird-related threats. In the course of uncovering their background, we found several third-party app stores that distributed or created similarly dangerous mobile apps.

    These third-party app stores target mobile users in Vietnam and inject advertising or even malicious code into popular apps. These apps put the user’s privacy at risk, and may even cause financial loss – the recent Trojanized Flappy Bird app used premium service abuse to profit, and also connected to a command-and-control server in order to receive commands.

    This example of a third-party app store imitates the Google Play store and contains various well-known apps that have been Trojanized. Even a fake version of the Google Play app itself is present, but it leads to their own third-party store.

    140218comment01

    Figure 1. Example of imitated Google Play’s page

    The apps in this store contain added advertising code; the profit from these ads goes to the cybercriminals and not the app developers. Among the information sent is the user’s phone number, email address, and device information.

    Figure 2. Advertising information

    In addition, this advertising module may remotely load code to be executed on the device, effectively acting as a backdoor. This poses a great risk for users.

    Figure 3. Backdoor code

    Apps with this malicious code are detected as ANDROIDOS_FLEXLEAK.HBT.

    Another third-party store was even riskier – this single store contained more than 500 OPFAKE malware variants. One of the malicious Flappy Bird apps was downloaded from this store. Not only do they contain the potentially malicious advertising code, they also abuse premium service numbers in order to get money directly from the user.

    Adult apps are also present on this store, with the users having to pay via SMS to use these apps.

    Figure 4. Second malicious third-party store

    A third app store has similar threats as the other stores mentioned in this post. This one, however, has higher download counts (more than 70,000 downloads).

    Figure 5. Third malicious third-party store

    These incidents highlight the possible dangers from downloading apps from third-party stores. Users often visit third-party app stores to obtain apps that may be unavailable in official app stores or  even pirated apps (like free versions of paid apps). Some users, meanwhile, rely on these sites because of the unavailability of official app stores in their region.

    However, visiting these sites can often be a hit-or-miss. Third-party app sites may not be as strict in monitoring and removing malicious apps compared to, say, Google Play. Apps from these third-party sites should be treated as potentially malicious, as a user has no easy way to determine what malicious code was added.

    We detect all the apps listed in these stores that contain malicious content or may violate a user’s privacy.

     
    Posted in Malware, Mobile | Comments Off



    Any vulnerability in Internet Explorer is a large issue, but last week’s zero-day vulnerability (designated as CVE-2014-0322) is particularly interesting. It used what we call a “hybrid exploit”, where the malicious exploit code is split across multiple components that use differing technology: in this case, the exploit code was split between JavaScript and Adobe Flash. The use of “hybrid exploits” provides attackers with a way to evade existing mitigation technology like ASLR and DEP.

    Let’s go over how this exploit was delivered to users. The victim website was compromised, and two malicious files were uploaded to it:

    • Erido.jpg (detected as HTML_EXPLOIT.PB, MD5 hash: 00ae7a1514809749a57d4d05d8c969b5)
    • Tope.swf (detected as SWF_EXPLOIT.PB, MD5 hash: 732b6a98b0a7b2ee795f2193a041520d)

    The overall flow can be found in the following diagram, which will be explained in the text.

    Figure 1. Overall control flow

    A page on the website (img.html) was modified with additional JavaScript and an iframe to load the malicious Flash file, as follows:

    <embed src=Tope.swf width=10 height=10></embed>

    When called, the Flash file carries out a heap spray. Control is then passed back to the JavaScript, via a function call in the Flash file. The actual malicious code that triggers CVE-2014-0322 is actually found here, and not in the Flash file. (To prevent further attacks that may exploit this vulnerability, we will not provide further details about the exploit.) Control is then passed back to the Flash file, where the code responsible for arbitrary memory reads and writes is located.

    From here on, the goal of the code is simple: it searches for return-oriented programming (ROP) gadgets in the memory (specifically, it uses ROP gadgets in ntdll.dll), constructs the ROP chain, and overwrite the virtual table of a Flash object in order to hijack the execution flow of the Flash virtual machine.

    Two ROP gadgets were used in this attack:

    • 77a646a8 94 xchg eax,esp // Pivot the stack pointer
    • ntdll!ZwProtectVirtualMemory (1a1b3000, 1000, PAGE_EXECUTE_READWRITE)

    The first ROP gadget pivots the stack pointer to let it point to controlled data; the second gadget calls ZwProtectVirtualMemory to change this shellcode’s protection to PAGE_EXECUTE_READWRITE, to bypass DEP protection.

    If this shellcode needs to call APIs, it will first check whether the API is hooked inlineby checking the starting byte code of the API. If that is the case, then it will skip the first 5 bytes of the API, to escape from the hook. This technique is used to bypass the detection of security products that are watching for this behavior.

    Figure 2. Malicious shellcode

    The above shellcode does the following:

    1. Decode two PE files using the data in the file Erido.jpg
    2. Drops the two PE files to:
      • %Temp%\sqlrenew.txt
      • %Temp%\stream.exe
    3. Load the contents of sqlrenew.txt into memory
    4. Return to the caller to prevent a Flash or IE crash

    The contents of sqlrenew.txt merely executes the other dropped file, stream.exe. However, this will only happen when IE has been terminated and the module itself is being unloaded.

    Figure 3. Malicious shellcode

    Conclusions

    Any zero-day vulnerability in a widely used program like Internet Explorer is significant, but this one appears to be doubly so. To avoid known exploit mitigation techniques like ASLR and DEP, this attack uses multiple web objects interacting with each other to carry out the exploit instead of a single easily detected file.

    It is likely that we will see more of this technique in the future as cybercriminals try to make their exploits more effective on all platforms. Both developers and security vendors will need to respond to this emerging threat in order to keep users safe.

     
    Posted in Exploits, Vulnerabilities | Comments Off


     

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