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

  • Recent Posts

  • Calendar

    February 2015
    S M T W T F S
    « Jan    
    1234567
    891011121314
    15161718192021
    22232425262728
  • Email Subscription

  • About Us

    As operating system developers are always keen on improving exploit mitigation technology, Microsoft has enabled a new mechanism in Windows 10 and in Windows 8.1 Update 3 (released last November) by fault. This technology is called Control Flow Guard (CFG).

    Previous mitigation techniques like address space layout randomization (ASLR) and Data Execution Prevention (DEP) have been successful in making exploitation of vulnerabilities more difficult, even if these techniques are not perfect. ASLR causes the development of heap sprays, and DEP results in return-oriented-programming (ROP) techniques showing up in the exploit code.

    To explore this particular technology, I used the Windows 10 Technical Preview (build 6.4.9841),  with test applications built using the Visual Studio 2015 Preview. Because the CFG implementation of the latest Windows 10 technical preview build (10.0.9926) has a slight change at that same point, I will point out the difference.

    To fully implement CFG, both the compiler and the operating system must support it properly. As an exploit mitigation mechanism in the system level, the CFG implementation requires cooperation from the compiler, the operating system user mode library, and the kernel mode module. A blog post on MSDN outlined the steps that developers need to do to support CFG.

    Microsoft’s implementation of CFG is focused on indirect call protection. Consider the following code in the test program I created:

    Figure 1. Code of test application

    Let’s take a look at what the encircled code compiles into if CFG is not enabled.

    Figure 2. Assembly code of test program

    In the above figure, there is one type of indirect call. Its target address is not decided at compilation and is instead decided at runtime. An exploit can abuse this as follows:

    Figure 3. How to abuse the indirect call

    Microsoft’s implementation of CFG focuses on mitigating problems if the indirect call is exploited and an invalid target is called (in an exploit, this would be to first stage shellcode).

    The invalid target has a distinguishing characteristic: in most cases it is not a valid function starting address. Microsoft’s CFG implementation is based on the idea that an indirect call’s target must be the start of a valid function. What is the resulting assembly code if CFG is enabled?

    Figure 4. Assembly code, with CFG enabled

    Before the indirect call, the target address is passed to the _guard_check_icall function, which is where CFG is actually implemented. In versions of Windows without CFG support, this function does nothing. In Windows 10, which does have CFG support, it points to ntdll!LdrpValidateUserCallTarget. This function takes a target address as argument and does the following:

    1. Access a bitmap (called CFGBitmap) which represents the starting location of all the functions in the process space. The status of every 8 bytes in the process space corresponds to a bit in CFGBitmap. If there is a function starting address in each group of 8 bytes, the corresponding bit in CFGBitmap is set to 1; otherwise it is set to 0. The figure below is an example of a portion of CFGBitmap:

      Figure 5. Representation of CFGBitmap

    2. Convert the target address to one bit in CFGBitmap. Let’s take 00b01030 as example:

      Figure 6. Target address

      The highest 3 bytes (the 24 bits encircled in blue) is the offset for CFGBitmap (unit is 4 bytes/32 bits). In this example, the highest three bytes are equal to to 0xb010. Therefore, the pointer to a four byte unit in CFGBitmap is the base address of CFGBitmap plus 0xb010.

      Meanwhile, the fourth bit to the eighth bit is (the five bits encircled in red) have the value X. If target address is aligned with 0x10 (target address & 0xf == 0), then X is the bit offset value within the unit. If the target address is not aligned with 0x10 (target address & 0xf != 0), the X | 0x1 is the bit offset value.

      In this example, the target address is 0x00b01030. X has the value of six. The formula 0x00b01030 & 0xf has a result of zero; this means the bit offset is also six.

    3. We look at the bit identified in step #2. If the bit is equal to 1, it means the indirect call target is valid because it is a function’s starting address. If the bit is 0, it means the indirect call target is invalid because it is not one function’s starting address. If the indirect call target is valid, the function will do nothing and let it go. If the indirect call target is invalid, an exception will be raised which should prevent further exploit code from running.

      Figure 7. Value in CFGBitmap

    The implementation of CFG should be useful in preventing some classes of exploits. This will help reduce the threat from software vulnerabilities in the long run.

    We will release a detailed analysis of this in an upcoming technical report.

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

    The DYRE/Dyreza banking malware is back with a new infection technique: we observed that it now hijacks Microsoft Outlook to spread the notorious UPATRE malware to target an expanded list of targeted banks.

    Last October 2014 we observed a hike in UPATRE-DYRE malware infections brought by the CUTWAIL spambot, a pattern we observed was similar to the propagation technique used in the ZeuS variant, Gameover.

    DYRE’s recent design and structure overhaul includes an improvement in its propagation and evasion techniques against security solutions, putting it on our watch list for notable malware for  2015.

    New DYRE Infection Chain

    DYRE typically arrives in users’ systems via an UPATRE downloader detected as TROJ_UPATRE.SMBG that arrives as an attachment spam emails.

    Figure 1. Sample spammed emails with UPATRE downloader attached

    In this new infection chain, we observed that once DYRE is installed, it downloads a worm (or WORM_MAILSPAM.XDP) that is capable of composing email messages in Microsoft Outlook with the UPATRE malware attached.

    (more…)

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

    Jan29
    12:54 am (UTC-7)   |    by

    Home surveillance/security cameras have been available for quite some time, and can be used to keep track of one’s home, children, pets, or business.  These devices are, in some ways, the first exposure of people to the Internet of Things.

    For most people, home surveillance means setting up a camera and using the Internet to access the camera feed in real-time. Higher end camera models can even be controlled remotely, making them useful for monitoring a large area with a single camera. This is a marked difference from previous iterations of home surveillance, which had restrictions or limitations in terms of accessibility.

    Online and Open Accessibility

    The older generation of security cameras required the configuration of the home router such as port forwarding, so that you can view the video feed remotely. While convenient, this set-up means that the camera is also accessible to pretty much anyone with an Internet connection.

    There are websites that scour the Internet for Internet-connected security cameras. One such site is Shodan. By logging in to Shodan, a person can find a specific camera based on the brand and IP address.


    Figure 1. Search results from Shodan

    There are even sites that offer streaming videos of publicly accessible cameras. A now-inaccessible Russian site took advantage of default usernames and passwords to access and upload camera feeds online. According to an article by CNN, the site featured streams from 4,600 cameras in the U.S. and thousands more in 100 countries. A quick online search revealed the existence of other, similar sites. There are even mobile apps that provide real-time streaming from cameras across the world.


    Figure 2. Camera feeds all over the world

    Managing Access

    Perhaps in a direct response of this issue, the newer generation of security cameras usually provides some form of cloud management and/or viewing functions.  Once configured, the camera communicates to the vendor cloud servers, allowing users to view the feed by logging into a web portal or by using mobile apps published by the vendor.

    In this set-up, the camera communicates to the vendor cloud servers only.  Connections initiated from the Internet cannot reach the camera, as the home router blocks them.  The camera is more secure from activities like unauthorized remote viewing.

    Vendor and User Security

    Accessibility issues aside, another important issue for these cameras is data protection. Vendors should provide strong encryption for all data/video feed from device to cloud servers to protect user privacy.  However, we found that some popular camera brands are still lacking in their security implementation.

    For example, the screenshot below is the packet capture between a D-Link DCS-932L camera communicating with the D-Link cloud server.  Certain traffic from the camera to the cloud servers is encrypted, but not all. There is still clear text communication over the Internet. Such an issue can only be addressed by the vendor, not the users.


    Figure 3. Clear text communication between server and camera

    The Importance of User Initiatives

    While some issues can only be addressed by camera vendors, this doesn’t mean that users should rely on security features offered by the cameras. The existence of the live stream sites shows the importance of changing default login credentials and using strong usernames and passwords. Strong authentication should be also used for home networks, to avoid any unauthorized access.  Users can also refer to our entry, Security Considerations for Consumers Buying Smart Home Devices, for a comprehensive discussion on buying smart devices.

     

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

    Researchers at Qualys have found a vulnerability in the GNU C Library (alternately known as glibc), which can be used to run arbitrary code on systems running various Linux operating systems. The vulnerability (assigned as CVE-2015-0235) has been dubbed GHOST and is the latest vulnerability to receive a “friendly” name, joining others like Heartbleed, Shellshock, and POODLE. However, closer inspection reveals that this particular vulnerability, while serious, is not easy to exploit and has a very limited attack surface.

    GHOST is a buffer overflow vulnerability triggered by calling the gethostbyname*() functions in glibc. These functions are used to resolve domain names into IP addresses by various applications. Theoretically, any application that uses these functions (practically any application that goes online) is at risk of being exploited.

    At first glance, it would seem that this poses a massive security problem. Fortunately for most users, there are many factors that mitigate any risk due to GHOST.

    First of all, this vulnerability has long been patched. The underlying problem was first introduced into glibc in 2000, but was fixed by May 2013. This means that many newer Linux operating systems were never at risk. (Like Shellshock, Windows-based systems are generally not vulnerable either.)

    Secondly, not all applications are at equal risk. Exploitation is very difficult as an attacker only has a small amount of initial exploit code that can be used: 4 or 8 bytes (depending on whether the system is a 32- or 64-bit system). Additional code must be written to an address referenced by a pointer which the attacker can modify. As a result, many apps are not at risk. So far, we are not aware of any potential web attack vectors, which reduces the attack surface considerably.

    Thirdly, the functions that are the subject of this vulnerability are obsolete. They cannot be used to translate domain names to IPv6 addresses; newer applications use the getaddrinfo() function, which does have IPv6 support.

    Taken together, the risk of actual exploits targeting GHOST is relatively small compared to other vulnerabilities like Shellshock or Heartbleed. Yes, the underlying vulnerability is problematic, but defense in depth by other vendors means that the actual risk is relatively low. So far, only Exim Mail Transfer Agent has been confirmed to be remotely exploitable, but there could more. With only four or eight bytes as the initial exploit vector, gaining further access is highly dependent on application design and memory usage. This is a significant barrier to exploitation.

    This doesn’t mean that system administrators can ignore the problem altogether, but it does mean that they can respond in a calm and orderly manner. Linux distributions have released patches that upgrade the version of glibc in use. Administrators should roll these out as soon as possible.

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

    Part of this January’s Patch Tuesday releases was MS15-004, which fixed a vulnerability that could be used in escalation of privilege attacks.

    I analyzed this vulnerability (designated as CVE-2015-0016) because it may be the first vulnerability in the wild that showed the capability to escape the Internet Explorer sandbox. As sandboxing represents a key part of exploit mitigation techniques, any exploit that can break established sandboxes is worth a second look.

    The vulnerability in the module TSWbPrxy.exe, which is an ActiveX Control. This module acts as the web proxy of the Microsoft Remote Desktop.

    To examine the patch, I used a Windows 7 32-bit system with the unpatched TSWbPrxy.exe at version 6.1.7600.16385.

    Patch differences

    First, I used the IDA plugin patchdiff2 to see what modifications the patch had made. This was in the function CTSWebProxy::StartRemoteDestop.

    Using OleView, I loaded TSWbPrxy.exe to see the definition of CTSWebProxy::StartRemoteDestop.

    Figure 1. Definition of StartRemoteDesktop

    I found that StartRemoteDesktop has two parameters, both related to mstsc.exe, which is the Remote Desktop application:

    • bstrMstsc: the file path of mstsc.exe
    • bstrArguments: the parameters of mstsc.exe

    The StartRemoteDesktop function creates a process to launch mstsc.exe. I used the IDA plugins to show more clearly the differences between the patched and unpatched versions:

    Figure02_patchedunpatched

    Figure 2. Differences between patched and unpatched versions
    (Click to enlarge)

    On the left is the patched version of this procedure. On the right is the unpatched version. On the patched version, before the call for CreateProcessW is carried out, check_path (shown in grey) is called. No such call exists on the unpatched version.

    (more…)

     
    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