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

  • Recent Posts

  • Calendar

    January 2015
    S M T W T F S
    « Dec    
     123
    45678910
    11121314151617
    18192021222324
    25262728293031
  • Email Subscription

  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Author Archive - Pawan Kinger (Director, Deep Security Labs)




    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.

     
    Posted in Exploits, Vulnerabilities |



    With the New Year celebrations safely behind us, it’s time to look forward and plan for 2015. Before we can do that, however, we need to spend a few minutes to remember the vulnerabilities of 2014 and what we can take away from these.

    Every year there are several zero-days and tons of undisclosed vulnerabilities fixed by software vendors. This year was a little different:

    • The total number of disclosed vulnerabilities per year almost hit 10,000. Because of this, the maintainers of the CVE database announced that the CVE syntax would be modified, which now allows up to 10 million vulnerabilities to be assigned identifiers annually.
    • Major “named” vulnerabilities like Heartbleed, Shellshock, Poodle, and WinShock were disclosed and became widely known within the security industry. These vulnerabilities were notable for their severe impact, widespread attack surface, and difficulty in patching.
    • There was an increase in amplification distributed denial-of-service (DDoS) attacks. These attacks are used to create high volumes of traffic used in denial of service attacks. It exploits weakness in network protocols to “elicit” large volumes of response packets which can be “redirected” to a victim to cause denial of service against them.
    • Some good news – there were no Java zero-days in 2014! However, that doesn’t mean that Java vulnerabilities weren’t exploited. They are still being actively exploited by exploit kits. Users still running older versions of Java should upgrade.
    • For Adobe products, it was a mixed story. Overall, the number of vulnerabilities in Adobe products declined from 2013. However, the number of  vulnerabilities in Adobe Flash went up from 56 to 76. Vulnerabilities in Acrobat/Reader went down by almost 30%.

      Figure 1. Number of vulnerabilities in Flash Player and Acrobat/Reader

    • There were a lot of vulnerabilities found in OpenSSL, not just Heartbleed. In 2014, 24 vulnerabilities were found – which equaled the number from the previous three years combined.

    With the above events in mind, what should be some of our key takeaways from all this?

    Read the rest of this entry »

     
    Posted in Exploits, Vulnerabilities |



    Software vulnerabilities exist – it’s a fact of life that we all have to live with, and if we’re both lucky and diligent enough, we can patch it before any cybercriminals can exploit it. That isn’t always the case, but thankfully that’s the exception, not the rule.

    However, news broke out recently of a vulnerability in the Heartbeat extension of OpenSSL, an open-source toolkit that helps webmasters and developers make transactions safer and more secure. This vulnerability, if taken advantage of – and there’s no way of knowing if cybercriminals already have, due to the nature of the vulnerability itself – could mean the compromise of a lot of transactions on websites and applications that use OpenSSL.

    What is the Heartbeat OpenSSL Extension?

    OpenSSL introduced an extension called Heartbeat around December 2011, with its 1.0.1 build release as defined in the RFC 6520 TLS/DTLS Heartbeat Extension. This extension’s function was to help avoid reestablishing sessions and allow for a mechanism by which SSL sessions could be kept alive for longer. The RFC proposed a HeartbeatRequest which must be answered with a HeartbeatResponse message. This results in a conservation of network resources, resources that would generally be used for full session renegotiation.

    It’s to note here that OpenSSL is used by many websites and software, from open source servers such as Apache and nginx to email servers, chat servers, virtual private networks (VPNs) and even network appliances.

    As such, it’s reasonable to assume that the Heartbeat extension is very widely used, thus making the scope of this vulnerability quite wide indeed.

    Understanding The Heartbleed Bug

    The vulnerability, dubbed as the Heartbleed Bug, exists on all OpenSSL implementations that use the Heartbeat extension. When exploited on a vulnerable server, it can allow an attacker to read a portion  up to 64 KB’s worth  of the computer’s memory at a time, without leaving any traces.

    This small chunk of memory could contain user-critical personal information  private keys, usernames, passwords (in cleartext in a lot of cases), credit card information, and confidential documents for example. The attacker could request this chunk again and again in order to get as much information as they want – and this bug could be exploited by anyone on the Internet, anywhere.

    A major Internet content provider was also affected by this bug and they fixed it quickly and diligently. But before it was fixed, some malicious actors had already stolen sensitive information.

    At its core, the Heartbleed bug is a simple and usual programming error, the kind of which leads to security issues. In simplified terms, it returns memory contents without checking on how much it actually reads and returns.

    As such, the user can ask for more information, and it gives the user more from the memory without checking to see if the user is in fact authorized to see that information. There is a payload length field that can be manipulated to grab the memory contents by tricking the server.

    Figure 1. Payload Length of the Heartbleed Bug

    This vulnerability has been assigned with the identifier CVE-2014-0160.

    Since this attack leaves no traces at all – it is an abuse of a bug in the code – it is hard to say if it’s being exploited in the wild. We will be monitoring our sensors for any such behavior.

    Which versions of OpenSSL are affected? Am I affected?

    As per the OpenSSL advisory:

    “Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.”

    Any other versions of OpenSSL are NOT affected by this bug. If you compiled your applications with any of these versions, then you may be affected.

    Users can also check if their server is affected by the Heartbleed vulnerability with this website.

    The fixed version is 1.0.1g, which was released on April 7, 2014.

    What should I do if I am affected?

    Affected users must upgrade to OpenSSL version 1.0.1g which has the Heartbleed bug fixed.

    If an upgrade is not possible you must recompile your applications to turn off the Heartbeat extension. This can be accomplished by using the -DOPENSSL_NO_HEARTBEATS flag.

    SSL certificates must also be revoked and replaced with new ones. With SSL certificates installed with the affected version of OpenSSL, the private keys could be potentially exposed. With no specific method of knowing which existing certificates are affected, new SSL certificates must be generated.

    End-users should also consider changing their passwords for their online accounts as the Heartbleed bug exposes sensitive information such as usernames and passwords. To avoid compromised accounts, users must reset all their passwords as soon as they are prompted to do so. They should also monitor for any suspicious activity involving their accounts, especially those financially related.

    Trend Micro Solution

    Trend Micro Deep Security customers should upgrade to DSRU-14-009 and assign the following rules:

    • 1006010 – Restrict OpenSSL TLS/DTLS Heartbeat Request
    • 1006011 – OpenSSL TLS/DTLS Heartbeat Information Disclosure Vulnerability
    • 1006012 – Identified Suspicious OpenSSL TLS/DTLS Heartbeat Request

    It is also possible to check for attempts to exploit the vulnerability through visibility and control of what goes on within a network. Through Deep Discovery, it is possible to monitor a web server and check for SSL/TLS-related traffic through the rule CVE-2014-0160-SSL_HEARTBEAT_EXPLOIT. Once found, Deep Discovery searches for Heartbeat message responses and checks for characteristics that indicate an exploit, specifically those related to the number of consecutive responses, the amount of information being echoed back, and others. This makes it possible to detect: attacks against a monitored server, as well as attempts to exploit the Heartbleed vulnerability from within a monitored network. This new Deep Discovery rule is released and automatically applied as part of the automatic update process for Deep Discovery.

    Update as of April 14, 2014, 7:41 A.M. PDT

    Client applications are also vulnerable to the Heartbleed vulnerability. If they connect to a malicious server, the Heartbleed bug can be exploited to read the client system’s memory. Last April 11th, Trend Micro released the following rules to protect customers using Deep Security and IDF from this exploit:

    • 1006016 – OpenSSL TLS/DTLS Heartbeat Message Information Disclosure Vulnerability
    • 1006017 – Restrict OpenSSL TLS/DTLS Heartbeat Message

    For other posts discussing the Heartbleed bug, check these other posts:

     
    Posted in Bad Sites, Vulnerabilities | Comments Off



    There are now less than two weeks left until Microsoft terminates support for the incredibly long-lived Windows XP. Rarely has a tech product lasted as long as XP has – from XP’s launch on  October 25, 2001 to its last Patch Tuesday on April 8, 2014 a total of 12 years, 5 months, and two weeks will have passed. Despite that, as of the month of February, StatCounter data indicated that almost one in five PCs still used Windows XP.

    There has been plenty of concern—and in some quarters, hysteria—over this event. When it would happen has been known for some time. Informed users also know that Windows XP was developed in very different circumstances—the famous Bill Gates trustworthy computing memo was sent after Windows XP had been developed and released to the public.

    The end of support for Windows XP concretely means two things: newly discovered vulnerabilities in Windows XP will not be patched anymore, nor will they be documented and acknowledged by Microsoft. This represents an increase in the risk of using Windows XP. Over time, this risk will increase as more issues are found and exploited –  although it may also fall, as the ever-decreasing numbers of Windows XP users means it will no longer be worthwhile to create exploits for an aging operating system.

    However, managing and mitigating risks is what security is all about. We will continue to provide our customers with the necessary tools to help manage the risks facing Windows XP systems. The most valuable tool in managing these risks is virtual patching/vulnerability shielding; products like Deep Security and OfficeScan with the Intrusion Defense  Firewall (IDF) module  scan and inspect network traffic before they reach the user’s applications, providing an opportunity to protect servers and endpoints from vulnerabilities.

    Another solution can be in hardening the endpoints. Endpoint security software will still protect users, if the security software vendor provides continued support for their products. (Trend Micro will continue to provide support for our endpoint software on Windows XP until 2017.) In addition, locking down these systems may be even more appropriate. For example, Trend Micro Endpoint Application Control can help lock down systems by preventing unwanted and unknown applications and processes from running.

    The underlying point is this: yes, Windows XP’s end of support is something that people should worry about—but it  is something that can be planned and prepared for. The tools and expertise are available for users to help protect their systems and networks as needed. We have prepared a primer titled Managing Your Legacy Systems to go into this topic in more detail.

     
    Posted in Vulnerabilities | Comments Off



    About two weeks ago, Oracle published a blog post describing – and promising – to improve the security of Java. Since then, I’ve been asked a few times: what exactly did they say, and what does it mean for end users?

    First, Oracle talked about how they’re now handling security patches. They pointed out how recent patches had, in fact, solved more security holes than previous patches. What’s more important to take away is that Java’s update schedule has been brought in line with other Oracle products: it will receive patches every three months, starting in October of this year. This should help get potential problems fixed more quickly before they are exploited by attackers. Of course, Oracle will continue to deliver out-of-band updates as needed for critical vulnerabilities.

    Java has also been brought under Oracle’s Software Security Assurance policies. As part of this, for example, Oracle will now use automated security testing tools to prevent regressions and new issues from showing up when a bug is fixed. This is welcome news, as it means that bugs will be patched more quickly in the future.

    Next, they discussed how they had been working to improve the security of Java as it is used in browsers. More important than the discussion of what was done in the past is what Oracle will implement soon: future Java versions will no longer allow unsigned or self-signed apps to run. It’s not clear when this will happen, but if it does, it will be a significant increase in Java security. It means that attackers will have to acquire or compromise a code signing key to get their Java applets to run: while this will not stop a truly determined attacker, less targeted attacks will fail.  In addition, Oracle is also working to improve how Java processes revoked signing signatures, so that this process can be turned on by default at a later time.

    For enterprise users, there’s good news too. Future versions will add support for security policies enforced by Windows itself, so that system administrators can set network-wide policies that can restrict or relax Java usage without having to set these per system. In addition, a new type of Java distribution – Server JRE – is being created specifically for servers running Java apps. This distribution will have several libraries removed to reduce the potential attack surfaces.

    All of these changes are for the better – Oracle is acknowledging that there have been challenges when it comes to Java security in the past, and they’re working hard to improve it moving forward. We appreciate these efforts and hope that they succeed in reducing the threat from Java exploits, which is completely in line with Trend Micro’s goal of creating a world safe for exchanging digital information.

    In the meantime, we strongly urge that users do their part to keep their Java installs safe: update to the latest version of Java. We earlier discussed how to secure Java in the blog post How to Use Java – If You Must.

     
    Posted in Vulnerabilities | Comments Off


     

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