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

  • Recent Posts

  • Calendar

    July 2014
    S M T W T F S
    « Jun   Aug »
     12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Archive for July 1st, 2014




    DOWNAD , also known as Conficker  remains to be one of the top 3 malware that affects enterprises and small and medium businesses.  This is attributed to the fact that a number of companies are still using Windows XP, susceptible to this threat.

    It can infect an entire network via a malicious URL, spam email, and removable drives. It is known to exploit MS08-067 Server service vulnerability in order to execute arbitrary codes. In addition, DOWNAD has its own domain generation algorithm that allows it to create randomly-generated URLs.  It then connects to these created URLs to download files on the system.

    During our monitoring of the spam landscape, we observed that in Q2, more than 40% of malware related spam mails are delivered by machines infected by DOWNAD worm.  Spam campaigns delivering FAREIT , MYTOB , and LOVGATE  payload in email attachments are attributed to DOWNAD infected machines.   FAREIT is a malware family of information stealers which download ZBOT .  On the other hand, MYTOB is an old family of worms known for sending a copy of itself in spam attachments.

    Malware Family-01

    Table 1. Spam sending malware

    Based on this data, CUTWAIL (Pushdo) botnet together with Gameover ZeuS (GoZ) are the other top sources of spam with malware. Interestingly, CUTWAIL was previously used to download GoZ malware. However, now UPATRE employs GoZ malware or variants of ZBOT which have peer-to-peer functionality.

    In the last few weeks we have reported various spam runs that abused Dropbox links to host malware like NECURS and UPATRE.  We also spotted a spammed message in the guise of voice mail that contains a Cryptolocker variant. The latest we have seen is a spam campaign with links that leveraged CUBBY, a file storage service, this time carrying a banking malware detected as TSPY_BANKER.WSTA.  Cybercriminals and threat actors are probably abusing file storage platforms so as to mask their malicious activities and go undetected in the system and network.

    As spam with malware attachment continues to proliferate, so is spam with links carrying malicious files. The continuous abuse of file hosting services to spread malware appears to have become a favored infection vector of cyberciminals most likely because this makes it more effective given that the URLs are legitimate thereby increasing the chance of bypassing Antispam filters.

    Although majority of the above campaigns are delivered by the popular GoZ, it is important to note that around 175 IPs are found to be related with DOWNAD worm. These IPs use various ports and are randomly generated via the DGA capability of DOWNAD. A number of machines are still infected by this threat and leveraged to send the spammed messages to further increase the number of infected systems. And with Microsoft ending the support for Windows XP this year, we can expect that systems with this OS can be infected by threats like DOWNAD.

    Trend Micro protects users from this threat via its Smart Protection Network that detects the malicious files and spam emails and blocks all related IPs. Users are also advised to upgrade their Windows OS and be cautious in opening email messages even though the source is seemingly legitimate.

    With additional insights from Maydalene Salvador

     
    Posted in Malware, Spam |



    In the recent Microsoft security bulletin for Internet Explorer, we found an interesting improvement for mitigating UAF (User After Free) vulnerability exploits.  The improvement, which we will name as “isolated heap”, is designed to prepare an isolated heap for many objects which often suffers from UAF vulnerabilities.

    Let’s use Internet Explorer 11 as an example. Before it was patched, the function CHeadElement::CreateElement allocates memory space from the heap. The code is as follows:

    figure1_isolateheap

    Figure 1. The function CHeadElement::CreateElement

    From Figure 1, we can see the memory space is allocated from the heap g_hProcessHeap, which is the IE default heap. In other words, all these IE objects share the same heap.  After the patch, in the sample location, the code was changed to the following:

    figure2_isolateheap

    figure3_isolateheap

    Figures 2 and 3. The function CHeadElement::CreateElement after the patch

    From Figures 2 and 3, we can see that Internet Explorer now allocates memory space from the heap g_hIsolatedHeap. In other words, these class objects which use the isolated heap do not share the same heap with IE’s other objects.

    How can an isolated heap mitigate UAF vulnerability exploits?

    The first routine of UAF vulnerability exploits is to use controlled objects to occupy the memory space which is owned by the UAF object. Some recent Internet Explorer zero-day vulnerabilities such as CVE-2014-0322 and CVE-2014-1776 used this technique.

    We can summarize the technique of occupying space in the following steps:

    1. Use String or Array to make a buffer which can be controlled by attacker.  For example: “var d=b.substring(0,(0×340-2)/2);
    2. Create an IE element object.  For example: “g_arr[a]=document.createElement(‘div’)
    3. Trigger vulnerability to free the target object.
    4. Set the attribute of the objects which is created by step 2 for many times with the String which is created in step 1. For example:

    for(a=0;a<arrLen;++a)
    {
    g_arr[a].className=d.substring(0,d.length);

    }

    In step 4, IE will allocate memory space in the heap g_hProcessHeap.  In the example for step 4, we can see the following part of the call stack:

    figure4_isolatedheap

     Figure 4. The function CAttrArray::Set() calling the function RtlAllocateHeap()

    In figure 4 we see CAttrArray::Set() calling the function RtlAllocateHeap(). The call stack is done with the following code:

    figure5_isolatedheap

    Figure 5. It uses RtlAllocateHeap with heap “g_hProcessHeap” and then copies the String ‘s data to this buffer.

    Before the latest patch, if the RtlAllocateHeap has the correct size, the probability that an attacker-controlled buffer could occupy the freed object’s memory space is high. But after the latest patch, the freed object is allocated in heap g_hIsolatedHeap, so there is no probability that the freed object memory space is occupied by the attacker-controlled buffer. The solution is a good way to mitigate UAF vulnerability exploits.

    From the patch‘s code,the heap g_hIsolatedHeap is used by HTML and SVG DOM Elements (CXXXElement) and supporting elements such as CTreeNode, CMarkup, CAttribute and so on. These objects have a high probability of having the UAF vulnerability, so it is important that they are secured through the isolated heap.

    Can the isolated heap solution mitigate UAF vulnerabilities completely?

    No solution is perfect. The improvement implemented by Microsoft raises the difficulty in creating an exploit, but it does not eliminate the vulnerability completely. There are two theoretical ways to bypass this protection:

    1. If attackers can find an object which meets the following three criteria instead of String:
      1. Allocated with the isolated heap.
      2. Correct size for the UAF object.
      3. Easily control the content of the object.

      What is not clear is if attackers can find a reasonable way to perform the above attack.

    2. Many objects are still using the process heap, not the isolated heap. If these objects encounter UAF vulnerability, the isolated heap solution doesn’t work. However, Microsoft can easily add objects to use the isolated heap if this becomes a problem down the road.

    We are glad that Microsoft is continuing to improve the security of Internet Explorer and mitigating the abuse of vulnerabilities. While the isolated heap is not a perfect solution, it represents a significant improvement that will help mitigate attacks of this type moving forward.

     
    Posted in Vulnerabilities | Comments Off


     

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