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    
     12
    3456789
    10111213141516
    17181920212223
    24252627282930
    31  
  • Email Subscription

  • About Us


    Author Archive - Virendra Bisht (Vulnerability Researcher)




    Unpatched versions of Microsoft’s Internet Information Services (IIS) web server are vulnerable to a remote denial of service attack that can prove to be very threatening if set against critical systems.

    The vulnerability, which was fixed by Microsoft in MS15-034 as part of the April 2015 Patch Tuesday cycle, can trigger the blue screen of death or more commonly known as BSOD. While there are no indications of possible remote code execution, it is still very important for users to apply the update, especially in systems that require 100% uptime.

    The following versions of Windows are at risk:

    • Windows 7
    • Windows Server 2008 R2
    • Windows 8/8.1
    • Windows Server 2012/2012 R2

    What is the HTTP Protocol Stack?

    The IIS web server has an HTTP listener as a part of the networking subsystem of Windows. This is implemented as a kernel-mode device driver called the HTTP protocol stack (HTTP.sys). It parses the HTTP request and provides a response to the clients.

    HTTP.sys provides the following benefits:

    • Kernel-mode caching. Requests for cached responses are served without switching to user mode.
    • Kernel-mode request queuing. Requests cause less overhead in context switching, because the kernel forwards requests directly to the correct worker process. If no worker process is available to accept a request, the kernel-mode request queue holds the request until a worker process picks it up.
    • Request pre-processing and security filtering.

    For this vulnerability to pose a risk, kernel caching should be enabled in IIS. This is enabled by default in IIS. Several modules in IIS perform tasks related to caching in the request-processing pipeline. Caching improves the performance by storing the processed information (such as Web pages) in memory on the server, and the same data is reused when requested by other requests. IIS Manager has a feature called “output caching”, which is controlled using the following settings:

    Figure 1. HTTP request that will trigger vulnerability

    Exploit and Attack Scenario

    This vulnerability is exploited using the Range HTTP header. This HTTP header allows clients to request specific contents from server at their demand. For example, a client that only needs few bytes of a file, can opt only to request specific parts, instead of the entire file. RFC 2616 (which defines HTTP) explains the definition of Range headers. There is a corresponding header (Accept-Ranges), which is used by servers to notify clients that they are supporting the Range header.

    Typically, the Range header contains values like this:

    Range:  bytes=124-5656

    It could also have values like this:

    Range: bytes=0-

    If the upper bound in the Range header isn’t present, it is considered that client is requesting the complete data. This is as good as not using the Range header at all. What if instead, a very high upper bound is specified by the attacker?

    All an attacker would have to do is send a specially crafted HTTP request with a special Range value, which would cause an overflow of the Range variable on the server. This is already being done by publicly available exploit code:

    Figure 2. HTTP request that will trigger vulnerability

    The cURL command can also be used as below to send the same exploit:

    $ curl -v example.com  -H "Host: example.com" -H "Range: bytes=0-18446744073709551615"

    The upper bound of the Range header is 0xFFFFFFFFFFFFFFFF, which is the largest 64-bit unsigned integer. The large value specified above will cause an integer overflow. A vulnerable server for such request reply with HTTP status line as “Requested Range Not Satisfiable”.

    Figure 3. Reply to exploit code by unpatched server

    This means that that the client asked for a part of the file that lies beyond the end of the file on the server. A successful attack could cause BSOD, leading to a denial of service. Microsoft has said that this vulnerability could lead to remote code execution, although no exploit that is capable of this is publicly known.

    After the fix, the HTTP headers are now checked for errors. A different error is returned if the same attack as before is sent:

    Figure 4. Reply to exploit code by unpatched server

    A response that includes the string “The request has an invalid header name” indicates that server is patched and attack it will fail. Proof-of-concept code is already using this information, as seen below:

    Figure 5. Proof of concept source code

    Conclusion

    This is a very easy vulnerability to exploit. A remote unauthenticated attacker could easily perform remote denial of service attacks on web servers running a vulnerable version of IIS. While remote code execution exploits are not known, there is a possibility of such exploit appearing in future. Administrators are advised to apply the patch; if that cannot be done immediately disable IIS kernel caching is a possible workaround.

    We have released the following Deep Security rule to protect Trend Micro customers:

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



    GnuTLS is a secure communications library implementing the SSL, TLS, and DTLS protocols. It provides applications a way to use the above protocols without having to create their own cryptographic code. It is aimed to be portable and efficient with a focus on security and interoperability. In many cases, it is used instead of other libraries because GnuTLS is distributed under the GNU Lesser General Public License.

    However, it was found that the GnuTLS X.509 certificate verification code fails to properly handle certain error conditions that may occur during the certificate verification process. While verifying the certificate, GnuTLS would report it as successful verification of the certificate, even though verification should have resulted in a failure. This means that invalid certificates may be accepted as valid,

    What makes this flaw truly problematic is that GnuTLS is used in many applications and software packages, including Exim, Weechat, Mutt, Lynx, CUPS, and gnoMint. It could be used for web applications, e-mail programs, and other code that use the library. Therefore, it’s very difficult to ascertain the number of affected applications. Some of the few operating systems that support GnuTLS include:

    • Red Hat Enterprise Linux Desktop (v. 6)
    • Red Hat Enterprise Linux HPC Node (v. 6)
    • Red Hat Enterprise Linux Server (v. 6)
    • Red Hat Enterprise Linux Server AUS (v. 6.5)
    • Red Hat Enterprise Linux Server EUS (v. 6.5.z)
    • Red Hat Enterprise Linux Workstation (v. 6)
    • Ubuntu 12.10
    • Ubuntu 12.04 LTS
    • Ubuntu 10.04 LTS
    • openSUSE 11.4

    An attacker can use a specially crafted invalid security certificate and it will be accepted as valid by an application (e.g., browser, email client, feed reader, etc.) that uses GnuTLS. This can lead to disclosure of confidential information and may lead to complete control of victim’s system through a combination with another vulnerability.

    A Brief Look at the X.509 Code

    The X.509 protocols rely on a hierarchical trust model. Certification Authorities (CAs) are used to certify entities. Usually, more than one certification authorities exist, and certification authorities may certify other authorities to issue certificates as well. One needs to trust one or more CAs for secure communications. In that case, only the certificates issued by the trusted authorities are accepted.

    The root cause is a simple coding flaw that might have been present in several applications, including Linux OSs, for many years. More specifically, the bug involves GnuTLS’s library functions which are used for processing certificate verification of X.509 certificates.

    The main issue of the bug is the goto statement along with an uninitialized variable. goto is an infamous statement which has been criticized by many security researchers. In this instance, if the goto statement is being executed under certain error conditions, it can short-circuit the verification checks and bypass the certificate authentication process, allowing certificates to be presented as verified.

    In the verify.c function, check_if_ca returns “true” or rather 1, when the certificate is genuine or issued by the certified authority (CA). The return value should be zero if the certificate is not genuine or not issued by a certified authority. Few other functions return a negative value when they fail. In most programming languages, 0 evaluates to “false” and any other [integer] value to “true” . So the function is used by gnutls_x509_crt_verify, which verifies X509 certificates, passes the invalid certificate as genuine.

    In C, the programming error handling return codes are checked through the following:

    1. Return zero for success and non-zero (or less than zero mostly) for failure.
    2. Return code explicitly and check them later (for example, “yes”, “no,” etc.)
    3. Return 1 for success and 0 for failure.

    It appears that for GnuTLS , methods 1 and 3 are used together for return codes.

    For the bug fix, the “goto cleanup;” is replaced with “goto fail;”

    Label fail is defined as under
    Fail:
    result = 0;

    Before the bug fix, the cleanup label is defined as under cleanup:

    gnutls_datum_t cert_signed_data = { NULL, 0 };
    gnutls_datnum_t cert_signature = { NULL, 0 };
    gnutls_x509_crt_t issuer = NULL;
    int issuer_version, result;

    After the bug fix, the cleanup label has been changed as under cleanup:

    gnutls_datum_t cert_signed_data = { NULL, 0 };
    gnutls_datnum_t cert_signature = { NULL, 0 };
    gnutls_x509_crt_t issuer = NULL;
    int issuer_version, result=0;

    A comparison of of the fix can be viewed below:


    Figure 1. Screenshot of corrected return codes taken from Gitorious

    Methods of Attack

    An attacker could exploit this issue in many ways, depending on the usage of the vulnerable library. The bug may be exploited in man-in-the-middle attacks. If a victim tries to log in to a site, the attacker can present his own certificate, pretending to be that site. The fake certificate will pass the verification process and will be presented as an authentic certificate. It will thus appear as normal to the victim while the attacker will be able to intercept confidential data. Attacks like these are highly effective and often difficult to detect.

    An attacker could also host his own web server, with some web application having a fake certificate pretending to be any site of his choice. Through social engineering, he can then exploit this vulnerability.

    Mitigating Attacks 

    GnuTLS developers has issued an advisory regarding this issue. Any application using digital certificate verification libraries with other than latest patched version of GnuTLS are affected by this vulnerability. Users of GnuTLS are advised to upgrade to the following version to address the issue:

    • GnuTLS version (3.2.12 or 3.1.22)

    Users can also apply the patch for GnuTLS 2.12.x. All applications linked to the GnuTLS library must be restarted for the update to take effect.

     

    Hat tip to Nikos Mavrogiannopoulos of the Red Hat Security Technologies Team for spotting this flaw.

     
    Posted in Vulnerabilities | Comments Off on A Look at the GnuTLS X.509 Verification Code Flaw


     

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