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, 2013




    We have released a research paper titled Email Correlation and Phishing. This paper describes, in some detail, how we use data correlation techniques to identify the “correct” senders of messages, which allows us to help identify spammers and spam/phishing messages and block them accordingly.

    These techniques are very useful in detecting phishing messages that try to pose as legitimate messages by organizations. In this regard, not only is it useful in targeting “conventional” phishing attempts, it may also be able to detect and block more targeted threats aimed at organizations that use the same tactic.

    These steps and techniques are necessary as spam and phishing techniques continue to improve. In particular, these phishing messages are very difficult to detect using techniques based on content, and both IP blacklists and email authentication, while useful have certain limitations. The techniques described in the paper are a useful addition to our existing tools, and demonstrate our expertise both in big data and today’s threats.

    The full details of these techniques can be found in the paper Email Correlation and Phishing.

     
    Posted in Spam | Comments Off



    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
     



    Reports of an active exploit targeting an unpatched vulnerability in Java 6 recently surfaced. Upgrading to the latest version of Java is the prescribed solution, though for some users, this is easier said than done.

    The said exploit, detected by Trend Micro as JAVA_EXPLOIT.ABC, targets CVE-2013-2463 which Oracle addressed last June. Java 6 is also affected by this vulnerability, but Oracle no longer supports the version since April this year. What is more alarming is that the said exploit has been confirmed integrated into the Neutrino exploit kit threat. Previously, the said exploit kit was found to serve users with ransomware variants, which are known to lock important files and often the system itself until affected users pay a fee or “ransom”.

    Since Oracle no longer supports the said version, they have not stated any intention to patch the said flaw. With more than 50% of users still using Java 6, this can lead to serious implications. Because no patch is (or will be) available, the exploit provides cybercriminals and other attackers an effective vehicle to launch attacks targeting users and organizations using Java 6. This may include the aforementioned Neutrino exploit kit and ransomware variants, which may cause serious business disruption and in some cases, actual money loss (due to users paying the ransom).

    The impact of this threat may be less for usual Internet users than for organizations/entities, who may not be quick to migrate to the latest software version due to business and/or operational continuity issues.

    This incident can also be a sneak peak at what might happen once Microsoft halts its support for Windows XP. Last April, the company reiterated their intention of ending its support for the said OS and Office 2003 by April 2014 and encourage its users to migrate to the more modern Windows 7 and 8.

    For users, the best way is to migrate to the latest version of Java. If not yet started, organizations are strongly encouraged to start migrating to the latest software version, to avoid this and other attacks that might take advantage of the unpatched vulnerability. Trend Micro detects and deletes the exploit and blocks access to sites hosting the malware.

    Update as of 8:00 PM, PDT

    Existing Trend Micro solutions – including our Web Reputation Service and the browser exploit prevention integrated into Trend Micro™ Titanium™ 2013 already provide protection to users out-of-the-box, without requiring any updates to be downloaded.

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

    Trend Micro Deep Security protects users from the exploits targeting vulnerability cited in this blog via rule 1005652 – Oracle Java SE Remote Code Execution Vulnerability (CVE-2013-2463).

     
    Posted in Exploits, Malware, Vulnerabilities | Comments Off



    By now, most users can easily detect spammed messages, particularly those that attempt (and fail) at looking like legitimate notifications. But some can look convincing, which is why a good social engineering education can be beneficial in the long run.

    We recently found an email sample pretending to be from the courier service UPS. The email poses as a package delivery notification, containing links to the tracking site and .PDF copy of the shipping invoice. This is definitely not the first time we received such an email. However, what makes this spam stand out is the way it hides its malicious intent.

    ups_spamrun_825

    As seen in the email screenshot above, the malware-hosting site is linked to a supposed legitimate UPS URL where the PDF version of the shipping invoice can be downloaded. For users, this URL may seem safe; however when clicked, the URL leads to a malicious ZIP file. To further convince users it is legitimate, the sender’s email address was forged to closely resemble an actual UPS email address.

    The ZIP file contains a malicious file which Trend Micro detects as BKDR_VAWTRAK.A. This backdoor steals stored information from several FTP clients or file managers. In addition, BKDR_VAWTRAK.A also steals credentials from mail clients including Outlook, PocoMail, IncrediMail, Windows Live Mail, and The Bat. In order to avoid detection on the system, this backdoor deletes certain registry keys related to software restriction policies.

    According to Trend Micro Software Architecture Director Jon Oliver, this attack was moderate in number, constituting approximately 1 in every 300-400 thousand email messages on the day of the outbreak based on the estimate. To give this a baseline of comparison, the recent royal baby spam outbreak consisted of 1 in every 200 email messages on the days of that outbreak.

    This email campaign also appears to be targeting specific organizations, which stresses the importance of social engineering training and how to make it effective in a workplace setting. This includes trainings like “social” penetration training, which is basically having someone play an attacker and attempt to lure employees via social engineering.

    Trend Micro Smart Protection Network protects users from this threat by blocking the related email message, malware and access to the site.

     
    Posted in Malware, Spam | Comments Off


     

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