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


  • Zero-Day Alerts

  • Hacking Team Leak

  • Recent Posts

  • Calendar

    August 2015
    S M T W T F S
    « Jul    
     1
    2345678
    9101112131415
    16171819202122
    23242526272829
    3031  
  • Email Subscription

  • About Us


    Author Archive - Jack Tang (Threats Analyst)




    Java used to be a favored vulnerability target for cybercriminals. However, in recent years that has not been the case. The now-fixed Java zero-day that was used in the Pawn Storm campaign was, in fact, the first time in nearly two years that a zero-day had been found and reported in Java.

    This can be attributed, in part, to stepped up security measures for Java. As Oracle notes on the Java home page itself, out of date Java plugins are now disabled by major browsers. In addition, Java 7 Update 51 (released in January 2014) tightened the rules on what kind of applets could be run. By default, self-signed and unsigned applets (the ones most likely to be used by attackers) would not run by default in browsers. JRE also has click-to-play protection for all applet (signed and unsigned). Taken together, these have made Java a far less attractive platform for attackers.

    Now that the Java zero-day (designated as CVE-2015-2590) has been patched, we can talk about some more technical details. This exploit has two components: one bypasses the click-to-play protection in Java. We will not disclose this portion of the vulnerability, but we can discuss the other component. As we noted earlier, this has now been fixed in the newest Java version (Java 8 Update 51).

    Java provides a class ObjectInputStream to deserialize buffers to objects. The buffer (which is to be deserialized) contains the object’s class information and filed data. More details about this class can be found in the Official Java documentation.

    The vulnerability is in how these objects are deserialized. An attacker can use this vulnerability to modify a field in the deserialized object (even if it is private) and introduce other class information. The Java Runtime Environment allows an attacker (in some cases) to read an object’s fields from a stream buffer even if the object or the object’s outer object’s class type is not found in the serialized buffer. The figure below shows the impact of the vulnerability:

    Figure 1. Vulnerability impact

    In Figure 1, the objects in the serialized objects buffer will be desterilized. During the process, Object A can intercept the desterilized process with an overriding function (for example, readResolve). In the function, the attacker coder can return to other object with other class which are not in the serialized object buffer (see the red word in F.1) to overwrite the original private field. In most cases, JRE can find it and raise exception. But if the objects, which are the outer objects of A, are crafted and overload readObject function to raise “Class Not Found ” exception. The vulnerability will trigger. In one words, the vulnerability give attacker a way to change directly one deserialized object ‘s private filed with class type which is not in the stream buffer.

    How does an attack proceed?

    First, an attacker crafts a serialized buffer. This contains an AtomicReferenceArray object. After exploiting the vulnerability, an AtomicReferenceArray class object’s private field array points to a Help type object array. After this step, memory layout like this:

    Figure 2. Memory layout

    In the above figure, the rar variable is a reference to the AtomicReferenceArray object which is deserialized and the AtomicReferenceArray object’s array references the array variable. Help is a subclass of the ClassLoader class. In other words the array variable control the AtomicReferenceArray object’s private field array.

    Next, the attacker gets a current ClassLoader object.

    The rar variable’s element is set to the acquired ClassLoader Object. (The attacker uses an index of 0.) Because rar.array is a reference to the Helper[] array, the real object of array[0] is changed.

    The type of array[0] in this case is Help. In the Help class, an attacker can use array[0] to access the function ClassLoader.defineClass. (This is a protected function; if an attacker directly uses the ClassLoader object to call defineClass in the current class scope, it will raise a compile error.)

    An attacker can use this access to define a privileged class and close SecurityManager. This allows the attacker to run their malicious code. One can ask why the attacker didn’t use the AtomicReferenceArray public API  to get the field array’s content? This is because the JRE will check whether the type’s element is correct for the type that it is to be cast to.

    Overall, the steps necessary to perform this exploit are similar to other previous exploits. For example, CVE-2012-0507 used a similar technique many years ago.

    Because of the severity of this vulnerability, we highly recommend that Java users update to the latest version.

    Other posts related to Operation Pawn Storm can be found here:

     



    Earlier this week, the Italian company known as Hacking Team experienced a breach, with more than 400GB of confidential company data made available to the public. The company was known for selling what it described as tools used to lawfully intercept communications that could be used by governments and law enforcement agencies. The company has stated they do not do business with oppressive countries.

    Much of the leaked information covered Hacking Team’s business practices, which seemingly contradict their official statements on who they sell their products to. However, the leak also included the tools provided by the company to carry out attacks, including several exploits targeting Adobe Flash Player and Windows Kernel.

    Since we have already discussed one of the Adobe Flash Player vulnerabilities, I decided to look into the Windows Kernel vulnerability. The vulnerability exists in the OpenType manager module (ATMFD.dll), which is provided by Adobe. The DLL is run in the kernel mode. An attacker can exploit the vulnerability to perform privilege escalation which can bypass the sandbox mitigation mechanism.

    Looking into the vulnerability

    The vulnerability‘s root cause is simple. When the application calls for some GDI API (e.g., GDI32!NamedEscape), it can specify which font driver can be used in the font processing. ATMFD.dll is one of the font drivers. While the module processes the font data, there exists a buffer underflow, which is caused by a signed number extending.

    I have simplified the vulnerability below:


    Figure 1. Simplified vulnerability code

    In line 5, the code is signed extending.  If i is 0x8000, then index will be 0xffff8000.  The check in line 6 will be successful, because index has a very small value (negative value) from the signed number view. In line 8, index*2+6 will become a negative value, so buffer_base[index*2+6] will point to a position which is in front of the buffer_base.

    The font buffer’s content can be prepared by an attacker, so that the vulnerability can be used to write controlled content to the position which is front of the input buffer.

    Additional information about this leak and the other exploits can also be found in our entry, Unpatched Flash Player Flaw, More POCs Found in Hacking Team Leak. We will update this entry should any information be made available.

    Related posts

     



    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.

     

     
    Posted in Vulnerabilities |



    Our analysis of the win32k.sys vulnerability used in a recent targeted attack reveals that it opens up an easy way to bypass the sandbox, making it a bigger threat than originally thought.

    As mentioned in Microsoft security bulletin MS15-051, CVE-2015-1701 is an elevation of privilege vulnerability that exists when the Win32k.sys kernel-mode driver improperly handles objects in memory. The vulnerability exists in Win32k.sys, which is a weak security point in Windows.

    Elevation of privilege vulnerabilities are technically less dangerous since they can’t be exploited remotely, but since this vulnerability can be used to bypass the sandbox — a security feature designed to keep attackers from being able to execute malicious files in users’ environment — this becomes a viable tool for attackers.

    The vulnerability exists in the Windows OS process of creating windows for applications. To illustrate, we’ll first look at the processes involved when an application wants to create a window:

    1. The application registers a window class to System, which defines the window’s style and behavior. The most important property of window class is window procedure which defines the window ‘s behavior when there’s an incoming message. The window procedure is provided by the application.
    2. The application then calls the API CreateWindow/CreateWindowEx with the window class to create the window. These APIs will switch to kernel mode to call service routine NtUserCreateWindowEx. NtUserCreateWindowEx is complicated function and does the real job of creating the window in Windows system.  During the function execution, it will switch to user mode many times to call many functions that exist in user mode. These function do jobs which is fit to run in the user mode (example: to load an image, etc.).

    Since this is a lengthy process, I’ve simplified the process of creating a window, leaving only the key point related to the vulnerability: Read the rest of this entry »

     



    One of the vulnerabilities recently patched by Microsoft can be exploited in the same way as Heartbleed, and needs to be addressed immediately.

    Addressed in the April batch of Patch Tuesday fixes (in Microsoft Security Bulletin MS15-034, specifically), the Microsoft Windows HTTP.sys Integer Overflow vulnerability, or CVE-2015-1635, is a remote code execution vulnerability that exists in HTTP.sys, or the HTTP protocol processing module in Microsoft Internet Information Service. Integer overflows have long been known as one kind of notorious and fairly old vulnerability – so why the sudden interest? I found that the vulnerability can be easily used for denial of service (DoS) attacks or data leaks similar to last year’s Heartbleed attack, in which information is copied from memory and sent to the client.

    A researcher already published a checker script for this vulnerability on Pastebin and showed how it can be used to carry out DoS attacks or to leak information. Additionally, another researcher published a POC for information leaks.

    Detailed analysis of DoS attacks and Information leak attacks via CVE-2015-1635

    In this blog post I will explain in detail how the vulnerability can be used for DoS attacks and data leak attacks. Before I dive into the vulnerability, let’s introduce some background information.

    Figure 1. Architecture of IIS

    After installing IIS (Internet Information Service) on the system, there is a service named the World Wide Web Publishing Service, which I call the WWW service. When a client sends an HTTP request to the system, the WWW service starts up or selects a worker process (W3wp.exe) based on load balancing policy to process the HTTP request and send the appropriate HTTP response. The file W3wp.exe uses HTTP.sys to do many tasks related to HTTP protocol handling, which include HTTP protocol parsing, response content assembling, and content caching. HTTP.sys receives the HTTP request and sends the HTTP response via TCPIP.sys.

    How can this be used in DoS attacks?

    Let’s prepare a HTTP request to start our DoS journey. The testing environment I used was Windows 8.1 (32-bit version) plus IIS 8.5.

    First, we take the IIS ‘s default web page iisstart.htm (file size 694 bytes) as an example. We compose a HTTP request as follows:

    GET /iisstart.htm HTTP/1.1\r\nHost: aaaaa\r\nRange: bytes=284-18446744073709551615 \r\n\r\n

    The HTTP range request start position is 284, and the end position is 18446744073709551615. The hexadecimal value of 18446744073709551615 is 0xFFFFFFFFFFFFFFFF. The range length is huge—it must be over the size of the requested web page file, which appears suspicious. I will explain later why I selected the start position as 284.

    After the request is sent to HTTP Server, one w3wp.exe handles the HTTP request processing. TCPIP.sys forwards any HTTP protocol content to HTTP.sys. If the request is a HTTP range request, it will call the function UlpParseRange(). The function parses the request to get the requested range’s start position and end position and calculates the range’s length. We can see that the first integer overflow happens in code which calculates the range’s length. The code is as follows:

    Figure 2. Range Length code

    When the end position=0xFFFFFFFFFFFFFFFF and start position=0, the integer overflow happens and the Range Length equals 0. The code does not check whether there is an overflow and does not take the error handling action.

    In our case, the integer overflow does not happen. The end position=0xFFFFFFFFFFFFFFFF and start position=284, while Range Length equals -284, whose hexadecimal value is 0xFFFFFFFFFFFFFEE4. If this is interpreted as an unsigned integer, the value is very huge.

    After finishing parsing the HTTP request, it will call the function UlAdjustRangesToContentSize(). The function adjusts the Range’s start position and length if the start position and length is “invalid”. The definition of “invalid” contains several scenarios which indicate the Range is over the requested web page content. Examples include:

    • Range Start Position is 0xFFFFFFFFFFFFFFFF
    • Range Length is 0xFFFFFFFFFFFFFFFF
    • Start Position >= the requested web page length
    • End Position >= the requested web page length

    The second integer overflow can be found in the last function. It uses the following code to get the Range End Position:

    Figure 3. Adjustment action

    In this case, the Range Start Position equals 284, Range Length equals 0xFFFFFFFFFFFFFEE4, so an overflow happens, Range End Position equals 0 and the adjusted action is bypass.

    If one same request is received continuously, the request‘s response will be cached and will be taken from the cache and sent to the requester. It will call the function UxpTpDirectTransmit().One job of the function is to calculate the HTTP response packet length. The simplified code is as follows:

    Figure 4. Simplified HTTP code

    Using our case‘s value:

    Range Count = 1;
    Range Boundary and Range Info length = 0; // (This will be explained later.)
    Range Tail Boundary Length = 0; // (This will be explained later.)
    Range Length = 0xFFFFFEE4; // (The value is already cast to 32 bit)
    HTTP Head Length = 283;

    The HTTP Response Length‘s result is 0xFFFFFFFF. The whole length is 4G. Systems will consider that this HTTP response total size is 4G. This means that there is a HTTP response packet whose calculated size is larger than the real size. This is why we used 284 as the Range Start Position.

    HTTP Response Length = HTTP Head Length + (Range End Position – Range Start Position + 1)
    = HTTP Head Length + (0xFFFFFFFF – Range Start Position + 1
    = HTTP Head Length - Range Start Position

    If Range Start Position less than <= HTTP Head Length, it will trigger an overflow. The HTTP Response Length value range is [0, HTTP Head Length).

    Because we want to launch a DoS attack, this is not the result we want. We want the HTTP Content Length value to be large. The preferred range for Range Start Position is [HTTP Head Length+1, target page size). In this range, it does NOT trigger an overflow and the HTTP Content Length value will become large, and will then allow a DoS attack.

    After the HTTP response package is assembled, HTTP.sys will forward the packet information to the protocol stack driver to send it. TCPIP.sys‘s function TcpSegmentTcbSend() will traverse every part content of the packet. There is integer overflow in the function. Here is a list of some simplified code:

    Figure 5. Simplified code

    In the above code, line 15 will trigger the overflow. In our case, the HTTP Response Length is 0xFFFFFFFF. The “virtual address’” initial value must be a kernel address ( >=0x80000000). Because HTTP Response Length is very large, the loop will run many times. When the loop has run many times, the “virtual address” will become a very small value after triggering the integer overflow. In the loop, it will use the “virtual address” to build a partial memory descriptor list (MDL). Because the range is not a sub range in the source range, it leads to a Blue Screen Of Death (or BSOD). The DoS attack is complete.

    How can this be used in an information theft attack?

    We prepare a request as follows:

    GET /iisstart.htm HTTP/1.1\r\nHost: aaaaa\r\nRange: bytes=3-18446744073709551615, 1-600"+ "\r\n\r\n"

    The reason for using multiple ranges will be explained later. We take 3-18446744073709551615 as Range1 and take 1-600 as Range2.

    In function UlpParseRange(),the code can be seen in Figure 3. For this case, we have 2 range lengths:

    Range1 Length = 0xFFFFFFFFFFFFFFFF - 0x3 + 1 = 0xFFFFFFFFFFFFFFFD
    Range2 Length = 600 -1 + 1 = 600

    After parsing the HTTP request, it will call the function UlAdjustRangesToContentSize(). The code is in Figure 3. Range1 will trigger integer overflow (3 + 0xFFFFFFFFFFFFFFFD => 0), so bypass adjust action, even if the Range1 Length is invalid. Range2 is valid, so it should not be adjusted.

    If the same request is received continuously, the request‘s response will be cached and will be taken from the cache and sent to the requester. It will call the function UxpTpDirectTransmit() . The code in Figure 4 is executed, using the following values:

    • Range Count = 2
    • Range1 Length = 0xFFFFFFFFFFFFFFFD
    • Range2 Length = 600
    • Http Head Length= 0x127 //HTTP head content, see Figure 6
    • Range1 Boundary and Range1 Info length = 0x7a
    • Range2 Boundary and Range2 Info length = 0x69
    • Range Tail Boundary Length = 0x32; //see Figure 8

    By using a multi-range request, there is a Range bound tag and Range Information (Content-Type, Content-Range) before each range content. (See Figure 7 for this.)

    Figure 6. HTTP Head

    Figure 7. Range boundary tag and Range Information

    Figure 8. Range Tail

    From Figure 4, we can see that HTTP Response Length = HTTP Head Length + Range Boundary and Range Info length + Range1 Length + Range Boundary and Range Info length + Range2 Length = 0x127+7a+0xFFFFFFFD+0x69+0x258+0x32 => 0x491. At line 5 of Figure 4, an integer overflow occurs when 0xFFFFFFFD is added. At this time, the system takes 0x491 as the HTTP response length.

    The memory status can be described as following:

    Figure 9. Memory status

    After assembling the HTTP response package, HTTP.sys will forward the packet information under the protocol stack driver to send it. TCPIP.sys ‘s function TcpSegmentTcbSend() will traverse every part content of the packet (see Figure)

    See the code in Figure 4. In this case, the HTTP response length is 0x491. When handling the part which length is 0xFFFFFFFD, line 7’s condition is met, Part Length‘s value will be set by Remain Length. At that point, Remain Length is 0x2f0 (0x491 – 0x172- 0x7a). It will use [0x3, 0x3+0x2f0] as a buffer range to read and send to client. Our target web page iistart.html has a length 0x2b6. The status is the following:

    Figure 10. Buffer status

    In Figure 10, the red part is the leaked information buffer. Compared with the code in Figure 5, the condition at line 24 is satisfied and breaks the loop. That is to say, the parts after the part which has 0xFFFFFFFD length will not be sent to client. At this point, we can see why we used a multi-range request.

    Using multi-range requests can let the HTTP response length (calculated in step 3) become larger to leak more information. If only a single range is used, the HTTP response length becomes either too big or too small. If the HTTP response length is too big, it will lead to BSOD, as it was described in the previous section. If the HTTP response length is small, it doesn’t make a range to cover the buffer after the target web page content to do information leak. Attackers use many range to leak more information. For example, I created a multi-range request as follows:

    GET /iisstart.htm HTTP/1.1\r\nHost: aaaaa\r\nRange: bytes=3- 18446744073709551615,1-32,32-64, 64-96,96-128,128-256, 129-130,130-140,160-170,180-190, 190-200"+ "\r\n\r\n"

    In the request, I use 11 ranges. The leaked information can be seen in the following picture:

    Figure 11. Information leakage

     

    Given these attack scenarios, I strongly advise users and network administrators to apply the patch, if they haven’t. Aside from the update provided by Microsoft, Deep Security also protects users from this through the following Deep Security rule:

    • 1006620 – Microsoft Windows HTTP.sys Remote Code Execution Vulnerability (CVE-2015-1635)

    This blog post is a follow-up to our previous blog entry on CVE-2015-1635:
    IIS At Risk: The HTTP Protocol Stack Vulnerability

     
    Posted in Exploits, Vulnerabilities |


     

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