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

  • Recent Posts

  • Calendar

    May 2015
    S M T W T F S
    « Apr    
  • Email Subscription

  • About Us

    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

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    A new online banking malware with the same technique used in Operation Emmental has been hitting users in Japan. Detected as TROJ_WERDLOD, this new malware has been causing problems in the country since December 2014 with more than 400 confirmed victims.

    This threat changes two settings that allows information theft at the network level (i.e., without using information-stealing malware). This has the advantage of not requiring a reboot or any memory-resident processes on the affected systems.

    One of the two settings modified is the system’s proxy settings. This routes some of the user’s Internet traffic to a proxy controlled by the attacker. The second is the addition of a malicious root certificate to the system’s trusted root store. This allows malicious site certificates added in man-in-the-middle attacks (as done by the malicious proxy) to be used without triggering alerts or error messages.

    This technique of a malicious proxy combined with an added root certificate was also used in Operation Emmental. This attack indicates that the technique has now reached Japan.

    Infection vector

    TROJ_WERDLOD infects users via spam mails with an attached .RTF document. The document claims to be an invoice or bill from an online shopping site. Once the .RTF file is opened, the user is instructed to double-click the icon in the document (as seen below), leading to TROJ_WERDLOD being executed.

    Figure 1. Spam mail leading to TROJ_WERDLOD’s infection

    Setting a malicious proxy

    Once infected, it modifies the registry value at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL to refer to a proxy.pac file which has been prepared by the threat actors behind this banking Trojan. A proxy.pac file contains automatic settings for a system’s proxy servers. This may include JavaScript code to determine which proxy will be used by a system.

    Figure 2. Modified registry setting

    Both Internet Explorer and Google Chrome obey this system setting. Mozilla Firefox uses its own settings (stored in the pref.js file), but this malware targets that setting as well.

    This proxy.pac file is obfuscated and Figure 3 shows the decrypted version. It shows how the network traffic for several domains is directed via malicious proxy servers. The enumerated domains include 26 Japanese domains including several online banks. Because of this, we believe Japanese users were specifically targeted.

    Figure 3. Decrypted proxy.pac file (click to enlarge)

    Adding a malicious root certificate

    Routing network traffic through malicious proxy servers allows cybercriminals to carry out a main-in-the-middle (MITM) attack. However, online banks use SSL/TLS to encrypt their traffic. Using the proxy server to decrypt this encrypted traffic would result in SSL errors at the endpoint, alerting users that something is wrong.

    To get around this, TROJ_WERDLOD can add its own root certificate into the trusted root store of systems. This certificate is disguised as one that belongs to a known (and trusted) root CA, but the signature does not match the legitimate certificate.

    Normally, a security warning will be shown before the fake certificate is added to the trusted root store. However, TROJ_WERDLOD can automatically push the “yes” button of the error message, installing the certificate without the user noticing.

    Making MITM attacks on SSL/TLS possible

    This is how an attack against an online banking site targeted by the attacker would proceed. The list of targeted sites is contained within the downloaded proxy.pac file. Traffic going to any of these sites will be routed through the malicious proxy.

    The malicious proxy performs a MITM attack against the secure connection. Normally, this would lead to SSL errors, as the fake SSL certificate used by the proxy would not be seen as valid. However, because of the added certificate in the root store, no error messages will be seen. The attacker can then intercept any credentials sent to the banking site; alternately the attacker might instead show a fake website and ask the user to enter their credentials.

    SSL/TLS should be able to avoid MITM attacks, but in this case, the presence of the malicious root certificate obliterates the trust model. This leaves the user at risk of attack.

    Countermeasures against TROJ_WERDLOD

    Opening email attachments has long been recognized as an infection vector. It is advisable that users not open these attachments, unless they are explicitly expected by the recipient.

    Many financial institutions have started using EV (Extended Validation) certificates. These will be issued through stricter screening system than normal SSL server certificates. Stricter screening includes checking if the issuer has been registered, or if the issuer can be contacted.

    EV certificates are more reliable than typical Domain Validation certificates, which can be issued to anyone who can prove they own a domain. When the server is using an EV certificate and working normally, a “green bar” is shown in the address bar, as shown below:

    Figure 5. User interface for a site with an EV certificate

    Where possible, companies that already use SSL/TLS for their login pages should adopt EV certificates. Organizations that use EV certificates may, in effect, “train” their customers to spot MITM attacks, protecting both parties in the transaction.

    TROJ_WERDLOD in the future

    As we mentioned earlier, the use of a fake certificate and proxy was previously found in Operation Emmental. That also used fake mobile apps that stole SMS messages from online banks. It is possible that this particular behavior may be seen in the future, although Japanese banks rarely use SMS authentication.

    Remove the infection

    To restore an infected PC to its normal condition, the following steps need to be performed to remove the malware and undo the two setting changes.

    1. Remove the proxy automatic setting (proxy.pac) in Windows and Firefox, or change it back to the previous setting (if one was provided by the ISP and/or system administrator.)
    2. Remove the malicious root certificate installed by TROJ_WERDLOD from the the trusted root stores in Windows and Firefox. (Instructions on how to do so are provided by Microsoft and Mozilla.) This malicious root certificate has the following signature:
      • A134D31B 881A6C20 02308473 325950EE 928B34CD

    Trend Micro solutions

    Trend Micro endpoint solutions such as Trend Micro™ Security, OfficeScan, and Worry-Free Business Security include behavior monitoring to detect this type of threat. File reputation can detect all the malware we encountered in this attack, including TROJ_WERDLOD. Email reputation can block emails from suspicious users and malicious emails. Mail Security gateway products use the content filtering function and enable to filter emails which include executable files as attachments. Web reputation can block accesses to malicious sites where the related backdoor malware connects and communicate.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    Casinos and resort hotels are the most recent victims of an attack that used RawPOS, an old POS malware, to steal customer data. The victims include establishments in the United States, Canada, Europe, Middle East, and Latin America.

    Touted as the earliest of its kind, very little research and documentation exists about RawPOS. As such, we will attempt to give light on this threat that may have been instrumental to previous credit card breaches documented and not previously attributed to this particular PoS threat.

    RawPOS, Then and Now

    The earliest reference to RawPOS we came across was around October 2008, with the  Visa Data Security Alert about debugging or parsing memory of point-of-sale systems to extract the full magnetic stripe data from volatile memory. Details from this advisory were observed in other security advisories released in 2008 and 2009.

    The latest security advisory regarding RawPOS was released in March 2015. The advisory talks about its involvement with attacks related to the hospitality industry—a report that matches our own findings.

    Configurable, Modular Design

    RawPOS has a modular design that is highly configurable and has always been a multi-stage scraper. Brought about by pioneers in PoS malware threats, the design they chose has now proven to be enduring till today:

    • The multi-stage or multi-component strategy ensures a high success rate for the chosen environment, while making prevention and detection harder –no matter what type of solution.
    • The threat is still successfully victimizing businesses, and the threat actors behind it are very familiar with how networks within small-to-medium business segments are designed.
    • It is fault-tolerant, persistent and very specific – incident responders and threat investigators may chance upon a specific file that has only been deployed for that specific business.

    Multiple Software Support

    Aside from being multi-component, RawPOS is notable for its support for multiple PoS software. Since business establishments would have different PoS software, attackers have modified RawPOS’ code to support multiple PoS software over time. Below is a table showing the different PoS software that is supported by RawPOS.

    Figure 1. Supported PoS software (click the image to enlarge)

    It should be noted that the list is compiled against what Trend Micro had seen in terms of file samples. While this PoS software listing tries to be as complete based on this file samples we have acquired, RawPOS and its components are highly configurable and we can certainly be sure that RawPOS has been modified to adapt to more PoS software.

    Additional analysis by Kenney Lu, Dark Luo, Marvin Cruz and Numaan Huq

    More details about RawPOS, as well as best practices and available Trend Micro solutions, can be found in our RawPOS Technical Brief.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    Millions of sites running the popular WordPress blogging platform are at risk from recently discovered zero-day vulnerabilities. These vulnerabilities were discovered by Finland-based security researcher Jouko Pynnönen, and could allow an attacker to execute JavaScript code in the website administrator’s browser window, and can further perform malicious tasks using administrator’s privileges. The attacker can even take control of the server. WordPress has released an update to WordPress, which they have called a “critical security release” that they urge all users to update to.

    The vulnerabilities allow an attacker to launch a stored cross-site scripting (XSS) attack via comments, forums, discussions, etc. This type of XSS attack is the most dangerous type. The attack is carried out by adding HTML and JavaScript content along with 64kb of text to comments on a WordPress-hosted blog or site. This code is then stored in the WordPress database. When a website administrator accesses the portal to review the comment, the script is executed.

    The malicious script then performs tasks like uploading a shell file (backdoor) to the server or adding other users with administrative privileges. The attacker is also able to access the server using the uploaded backdoor, or can login using the newly created user with administrative privileges. This all happens in the background, without the administrator’s knowledge or approval.

    Recommendations and Trend Micro Solutions

    We urge site administrators to upgrade their versions of WordPress to the latest version (4.2.1), which fixes these vulnerabilities. This can usually be easily done via the WordPress dashboard.

    In addition, the following Trend Micro Deep Security XSS prevention rule covers these vulnerabilities. The rule is available out of the box in the product and prevents attacks from leveraging these vulnerabilities. It is also advised to check whether your server is still compromised after applying the rule.

    • 1000552 – Generic Cross Site Scripting(XSS) Prevention
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  

    If you’ve read enough crime novels or seen enough action movies, the plot is all too familiar to you: an insider – acting to correct some slight or insult he or she received years ago – turns against an organization and inflicts significant damage. Sometimes the insider is on the side of the good guys, sometimes on the bad guys.

    This makes perfect sense. An insider knows exactly how an organization does things, what they consider valuable, and how they will respond to an attack. Who else would be better to carry out an attack than an insider?

    However, that assumes that an “insider threat” is by design. Fortunately, most people are not out to destroy the organization they belong to. Most people want the group that they are part of to succeed and do well. Unless you’re in an organization that deals with national security, this is probably something you don’t have to worry about.

    The problem is that not all “insider threats” are deliberate. “Insiders” could end up leaking information to attackers inadvertently. Social media has provided users with many new and interesting ways to communicate, and unfortunately sometimes this includes confidential information that shouldn’t be communicated.

    If people are already leaking information online, what more if you have a social engineer trying to squeeze information from others? Social engineering can be defined as the art of getting others to do what you want. It’s an art that’s been practiced in one way or another for thousands of years, so it shouldn’t be a surprise that threat actors have become very good at it.

    Almost all targeted attacks begin with some form of social engineering. While it is not a simple task, you can – and should – attempt to defend against these types of attacks.

    There are two ways that an organization can defend against these attacks, but these ways are not mutually exclusive. First, there are technical means of defense. For example, email blocking can help prevent attacks that are designed to impersonate other parties (such as banks or other trusted organizations.) Heuristic- and email reputation-based solutions are useful in this regard.

    The second way is to harden your users. Teach them to be more careful, vigilant, and aware of the threats going on today. Make sure that instead of just ignoring these attacks, they report them to your own security team so that the entire organization can stay aware of what’s going on.

    Even more important than how to protect data is deciding what data to protect. It is difficult, if not impossible, to protect everything. What you need to decide is: what matters most to your organization and needs to be protected? I would recommend using three categories:

    1. Data which is not sensitive
    2. Data which has a negative impact on your organisation if leaked
    3. Data which destroy your business if leaked

    This organization sounds simple, but a lively debate is likely to ensue when classifying which data goes in what category. However, this is necessary: you need to figure out what is really important and what is core to your organization. Protect that first before anything else.

    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   StumbleUpon  


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