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 - Pawan Kinger (Director, Deep Security Labs)




    Support for Windows XP ended over a year ago. By any standard, Windows XP ranks as one of the most influential versions of Windows ever, thanks to its longevity and widespread adoption by enterprises around the world. However, the end of support should have served as a clear signpost to users and organizations to immediately upgrade to newer systems.

    A year later, remarkably, Windows XP isn’t quite dead yet. Its exact share can be debated. Net Market Share data suggests its share as of March 2015 is at around 17%. StatCounter has this figure at over 11%. Analytics data from US government websites can be used to get an estimate as well; this data places XP market share at just under 5%.

    The risks to Windows XP have not gone away, either. A year’s worth of vulnerabilities that may affect Windows XP have not been patched—only once did Microsoft publicly release a patch for a Windows XP zero-day vulnerability. In addition, various security upgrades for later versions of Windows have not been retrofitted to Windows XP: a good example is Control Flow Guard, which is only available in Windows 8.1 Update 3 (from November 2014) and in Windows 10 (currently in Technical Preview).

    Support for Windows Server 2003 to end in July

    In just under three months, however, IT administrators will have to do the upgrade dance again. Windows Server 2003’s support will end in July this year. A survey of IT professionals by Spiceworks outlined the scale of the issue. 61% of organizations still have at least one instance of Server 2003 running; and only 15% of respondents indicated that their organizations had completed migration. Of those who plan to have some Server 2003 systems active even after the end of support, almost everyone (85%) indicated that security risks were a concern.

    As with Windows XP, we highly recommend that organizations prepare and implement migration plans—if they haven’t already. The potential risks here are even greater, considering servers are the systems at risk.

    Available solutions and recommendations

    Users running unpatched systems are advised to enable Enhanced Mitigation Experience Toolkit (EMET) on their Windows systems. EMET is a free tool by Microsoft designed to protect Windows systems even before new and undiscovered threats.

    Additionally, users who cannot upgrade to newer Windows versions are still protected against threats with our security solutions. Trend Micro Deep Security and Vulnerability Protection are both able to detect threats before they reach user systems. Trend Micro Endpoint Application Control can also lock down systems by preventing unwanted and unknown applications and processes from running.

    Deep Security will support Windows 2000 until 2017 and Windows 2003 and XP until 2020. In addition, our endpoint products will continue to be supported for these older Windows versions until 2016.

     
    Posted in Vulnerabilities |



    Security researchers Luca Carettoni and Mauro Gentile recently found during their research that even though Adobe has fixed an old vulnerability found in 2011 (CVE-2011-2461), its side effects still linger around the Internet. Your favorite websites might still be affected by this bug.

    They have shared great details in their blog post. Let’s take a quick look at the issue and how the vulnerability impacts both site owner and end users.

    What’s the issue?

    The vulnerability was in the Adobe Flex SDK, which is used to create Internet applications based on Flash (it is now owned by the Apache Software Foundation). Users who don’t typically read the fine print or the gory details probably thought patching the Flex SDK put an end to the issue. However, that was just part of it. Other departments aside from IT had to act on it as well. Application/website developers also had to review the Flash files they were hosting. Let’s take a closer look at the Adobe advisory:

    An important vulnerability has been identified in the Adobe Flex SDK … This vulnerability could lead to cross-site scripting issues in Flex applications. Adobe recommends … update their software, verify whether any SWF files in their applications are vulnerable, and update any vulnerable SWF files using the instructions and tools provided as outlined in the tech note linked in the “Solutions” section below.

    Adobe clearly recommends that users update their Flex SDK, and check any SWF in their applications that may be vulnerable and fix them too. The issue is that an unpatched Flex SDK would produce Flash files that are vulnerable, and these vulnerable Flash files could be used to launch a Same-Origin Request Forgery attack on another site.

    In simpler terms, a user could be forced to visit a malicious site, which would eventually load the vulnerable Flash file from a good site and steal the user’s cookies and data for that good site.

    How can an attacker take advantage of this vulnerability?

    If an attacker can convince you to click on a link to his malicious site, they can force you to load a vulnerable Flash file from the victim site (the site you trust, but is hosting a vulnerable Flash file) after loading a Flash object from his malicious site. Due to a bad check for origin rule this (vulnerable) Flash allows for cross domain “interaction” with the malicious site.

    Carettoni and Gentile noted: “Practically speaking, it is possible to force the affected Flash movies to perform same-origin requests and return the responses back to the attacker. Since HTTP requests contain cookies and are issued from the victim’s domain, HTTP responses may contain private information including anti-CSRF tokens and user’s data.”

    How am I affected by this vulnerability?

    You can be affected either as a web site owner and an end user. As a website owner, your users can be exploited. Their session cookies and anti-CSRF tokens can be stolen, and as a site owner, you will be liable for the consequences. As an end user, you suffer from the same issues and someone can impersonate you and carry out transactions on your behalf.

    Note that the version of Flash Player you are using doesn’t matter. It’s all about the Flash file itself being vulnerable.

    What are the recommended actions?

    As a website administrator you may opt to scan your web servers for Flash files using the ParrotNG tool. If you do have vulnerable files, you have two options:

    • Recompile your Flash files using a patched version of Adobe Flex.
    • If you don’t wish to recompile these files, use the Adobe-provided tool to patch the vulnerable SWF files.

    Adobe’s tool can also be used as an alternative to the ParrotNG one.

    There is no action for end users that is specific to this problem. In general, they should use the same techniques used to avoid becoming a victim of malicious sites in general – be careful about what links you click. Be watchful of the links you receive via social media and chat, and consider disabling Flash altogether.

    Trend Micro Deep Security and Vulnerability Protection customers are protected by the following rule.

    • 1004866  – Flash Authoring Flex SWF Files XSS (UPDATE: As of  Apr 1, 2015, 5:40 AM PST, this has been updated to 1004866 – Adobe Flex SDK Cross Site Scripting Vulnerability (CVE-2011-2461))

     

     
    Posted in Vulnerabilities |



    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.

     



    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 | Comments Off on Remembering the Vulnerabilities of 2014



    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 on Skipping a Heartbeat: The Analysis of the Heartbleed OpenSSL Vulnerability


     

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