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

  • Recent Posts

  • Calendar

    August 2013
    S M T W T F S
    « Jul   Sep »
     123
    45678910
    11121314151617
    18192021222324
    25262728293031
  • Email Subscription

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

    Archive for August 28th, 2013




    The recent attacks on New York Times, Twitter and others while DNS-related, were not the result of a weakness in the DNS at all. They resulted from weaknesses in domain registrar infrastructure. The DNS components related to this event performed exactly as they were designed and instructed to do.

    While it is true that the malicious instructions were unauthorized, they followed proper channels. Evidence points to The Syria Electronic Army, but investigation is still ongoing.

    The breakdown came when the credentials of a Melbourne IT (a domain registrar) re-seller were compromised. (Please tell me passwords weren’t stored in un-salted MD5 hashes, please?). From there the attacker changed the name-server configuration for the victim domains to their own malicious infrastructure. The DNS took it from there. When the caches started expiring, the new “bogus” data began replacing the good data in DNS replies.

    So what could the victims have done differently to prevent or reduce the impact of this attack? Let’s look at the basics:

    • DNSSEC. DNSSEC could have been helpful IF the stolen credentials were not sufficient to allow the attacker to change the DNSSEC configuration of the subject domain. Otherwise the attacker could have replaced or removed the DNSSEC configuration and carried on with the attack.
    • Domain-locking. Again this would have prevented the change IF the stolen credentials were not capable of disabling the lock feature. The fact that twitter.com was un-touched while some utility domains at Twitter were, indicates that this might be the case. Also it should be noted that depending on the registrar the domain-locking service may come at an additional fee.
    • Domain monitoring. Always a good practice for high-profile domain-names. Configuration elements like name-servers tend to change slowly so any changes can be used to trigger an alert. There are a number of commercial monitoring services to choose from or you could consider using a small shell-script. Note I have no information one way or the other as to whether any of the involved companies had monitoring like this in place. It could not have prevented this scenario, but would have shortened the time to repair.
    • Carefully selecting vendors based on their security posture. This one is HARD to implement right now. Vendors with a weak posture will not advertise that fact. Vendors with a strong posture will likely practice good operational security and be reluctant to share the details of their infrastructure, lest attackers get a roadmap of these defenses.

    One thing we can all learn from these attacks is that dedicated attackers have no problems searching our contacts, connections, vendors and clients for the weakest link in order to gain entry.

     
    Posted in Social | Comments Off



    Recently, security researchers disclosed two Java native layer exploits (CVE-2013-2465 and CVE-2013-2471). This caused us to look into native layer exploits more closely, as they have been becoming more common this year. At this year’s Pwn2Own competition at CanSecWest, Joshua Drake showed CVE-2013-1491, which was exploitable on Java 7 running on Windows 8. CVE-2013-1493 has become a popular vulnerability to target in exploits kits such as Blackhole.

    To understand why these exploits are becoming more common, some understanding of Java’s architecture is helpful. Java exploits can be divided into two types: Java layer exploits and Java native layer exploits.

    Figure 1. Java security model

    The above graph shows the Java security model. Java layer exploits target vulnerabilities in the Java layer runtime, which lets applications bypass the Security Manager and call high privilege functions. These exploits have the following characteristics:

    • Can be created with less effort, because attackers need not bypass operating system-level protections.
    • Are cross-platform (i.e., work with multiple operating systems)

    Similarly, Java native layer exploits target the Java native layer runtime. These exploits are harder to create, as they need to bypass OS-level protections like ASLR and DEP. In addition, the skills needed to create native layer exploits are more difficult to acquire.

    Figure 2. Timeline of common Java vulnerabilities

    In the past, Java layer vulnerabilities were more common, but that is no longer the case. Before 2013, there was a 3:1 ratio of Java layer vulnerabilities to Java native layer vulnerabilities. Starting this year, however, we are now seeing more native layer flaws. Why is this the case?

    • A large amount of the vulnerabilities of are present in the Java native layer code. In the June 2013 Java SE Critical Patch Update Advisory, approximately half of all the vulnerabilities fixed were in the Java native layer code.
    • Attackers are becoming more skillful in creating exploits. In the past, while there were many native layer vulnerabilities, less exploits were present because attackers did not always have the skill to create the necessary exploits.

    This year, however, attackers clearly have the capability to take advantage of native layer vulnerabilities. Two methods of exploitation are becoming more common,

    One is to make use of a Java array length overflow to tamper with the java.beans. Statement object’s AccessControlContext member. To do this, the following steps are necessary:

    1. Prepare a Java Array object on a heap.

      Figure 3. Step #1

    2. Trigger a Java native layer vulnerability. The array object’s length is overflowed to a very large value.

      Figure 4. Step #2

    3. An attacker can then use the array object to get or set the following buffer precisely. They can tamper with the following java.beans.Statement object’s acc field, which points to a AccessControlContext object. In general, the acc field will be tampered to point to a full permission AccessControlContext object. This will let arbitrary code be run on the affected system.

      Figure 5. Step #3

    This exploit method requires that both the buffer which can be used to trigger vulnerability and the buffer which needs to be overwritten are in the same heap. It requires some knowledge and skill to ensure that this is the case. In addition to this, information leaks and ROP shell code attacks were demonstrated at Pwn2Own 2013. It gets the module base address by targeting a Java native layer vulnerability and constructing ROP shell code to hijack the execution context. We believe that 2013 will see more similar exploits along these lines.

    We urge users to carefully evaluate their usage of Java is necessary and ensure that copies of Java that are used are updated, to reduce exposure to present and future Java flaws.

    Update as of 9:28 AM PDT, Sept. 2, 2013

    Trend Micro Deep Security provides protection for threats targeting CVE-2013-2465, CVE-2012-4681, CVE-2012-1723 via the following rules:

    • 1005598 – Identified Malicious Java JAR Files – 3
    • 1004870 – Identified Suspicious Jar File
    • 1005093 – Java Applet Field Bytecode Verifier Cache Remote Code Execution Vulnerability
    • 1005640 – Oracle Java storeImageArray() Invalid Array Indexing Vulnerability
     


     

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