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

  • Recent Posts

  • Calendar

    June 2013
    S M T W T F S
    « May   Jul »
     1
    2345678
    9101112131415
    16171819202122
    23242526272829
    30  
  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Archive for June, 2013




    Oracle has just released its security update for June 2013 — a release that comprises of 40 security updates, with 37 of them addressing vulnerabilities that lead to malware execution. Also among the updates is one that fixes a vulnerability found in Javadoc tool — a documentation generator and is commonly used in websites.

    The said vulnerability, also identified as CVE-2013-1571, can be used to steal important user data by injecting an attacker controlled frame in generated Javadoc HTML page. This vulnerability is also known as Frame Injection vulnerability.

    Javadoc is a tool that generates .HTML documentation from Javadoc comments in the code. The vulnerability is due to a defect in the JavaScript code that is included as part of the HTML pages generated by the Javadoc tool. Hence all the websites using such HTML pages can be used by an attacker to steal their user data or to install malware by redirecting an unsuspecting user to attacker-controlled website.

    Oracle released two fixes in their June 2013 Oracle Java SE Critical Patch Update to address this vulnerability. The first is an updated Javadoc tool, while the second is a fix-in-place tool that patches the vulnerability from pages generated by Javadoc without having to regenerate existing JavaDocs. Needless to say, we strongly advise customers to apply the fixes the soonest possible.

    Trend Micro Deep Security customers are advised to update to the latest update DSRU13-020. The following Deep Security rule 1005553 – Oracle JavaDoc Frame Injection Vulnerability addresses the said issue.

    Hat tip to CERT for sharing the necessary information with us.

     
    Posted in Vulnerabilities | Comments Off



    Last week, we talked about the OBAD Android malware, which installed itself as an administrator on the device and used a vulnerability in Android to hide this fact from the user.

    One effect of this particular behavior was to make removal of this threat very difficult. Apps that have set themselves up as administrators require user interaction to remove: but because the vulnerability hides the app, it can’t be removed.

    In response to this threat, we have created the Hidden Device Admin Detector app. This tool’s purpose is simple: it allows users to keep track of and disable apps that have device administrator privileges but are hidden from Android Device Administrator list.

    Most apps do not need to these device administrator privileges. One can think of them as being analogous to holding root access on a Linux/Unix machine, or having administrator access on Windows. It gives you complete control over the machine. Most apps do not need this level of access; this is why the user has to be prompted to enable these privileges. Apps that do require these privileges include security apps (like Trend Micro Mobile Security) and system administration apps that may be used in BYOD situations.

    When run, the app will display the apps with administrator privileges that exploit this vulnerability to hide themselves:

    Figure 1. Hidden Device Admin Detector app

    From here, users can disable the privileges. Malicious apps with disabled administrator privileges can be removed normally, either by security products or the user.

    Android does contain this feature as well, but because of the above vulnerability the list it provides may not be complete. Google may patch the vulnerability in the future, but the complicated Android update situation means many users will never get the patch. We recommend that all users download this app and periodically check for malicious apps on their Android devices.

    You can download the app by going to the Google Play app store.

     
    Posted in Malware, Mobile | 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


    Jun17
    12:56 am (UTC-7)   |    by

    At the end of May, two Google security engineers announced Mountain View’s new policy regarding zero-day bugs and disclosure. They strongly suggested that information about zero-day exploits currently in the wild should be released no more than seven days after the vendor has been notified. Ideally, the notification or patch should come from the vendor, but they also indicated that researchers should release the details themselves if the vendor was not forthcoming.

    This is a pretty aggressive goal. Microsoft, for example, does not set public deadlines for critical patches: a balance needs to be found between quality and speed. Balancing the two is not that easy. On one hand, an actively exploited vulnerability will be used by malware writers aware of the vendor’s vulnerability. On the other hand, a quick patch could have negative side effects and could cripple the application or the entire system.

    Almost every security vendor has false positives that result in negative side effects. We have lots of safeguards in place – such as checking against whitelists – but Murphy’s law applies. Our industry has crippled the computers of users. What more an operating system vendor – they need to be extra careful in patching. They need to conduct proper quality assurance, as the patch will affect millions of computers.

    In my opinion, disclosure after 7 days is reasonable and OK, but expecting a patch in this time frame is unreasonable. Let’s see how Google itself will manage. Currently, there’s a Google Android Trojan spreading which is able to hide itself from the “Device Administrator”, which renders it invisible from security programs and clean up attempts. This was possible because of a security flaw in Android. Will Google be able to fix this within 7 days? Let’s see…

    The bigger debate is not just about how long it should take to report and fix vulnerabilities. It’s about how vulnerabilities should be reported in the first place. If you believe a recent media report, the US government is now the biggest purchaser of malware. How do we ensure that the affected vendors are informed, that these are not used for offensive uses like Stuxnet? How do we ensure that these same vulnerabilities don’t end up in the hands of the underground, which will use these threats widely?

    What needs to take place is a bigger discussion around how discovered vulnerabilities are dealt with at all. These should be between all those involved in this field – developers, governments, and researchers – to determine how we can deal with security vulnerabilities in the future.

     



    Online banking threats have been prevalent for many years, but recently they seem to be determined to expand beyond their usual targets. In the past few weeks and months, we’ve seen various attacks target Korean banks using various techniques.

    The latest attack we’ve found uses a Trojan that redirects users of various Korean banks to malicious phishing sites. It does this by modifying the system’s HOSTS file and redirecting users to an IP address located in Japan. We detect the Trojan responsible for this attack as TSPY_QHOST.QFB, while the related batch file (which actually modifies the HOSTS file) is detected as BAT_QHOST.QFB. (This technique has been used for many years by other banking threats.)

    The malicious site looks like this:


    Figure 1. Page of malicious site

    The malicious site has an additional window in the middle.


    Figure 2. Additional window of malicious site

    The image roughly translates to:

    • Did you install the certificate of authentication in your PC (computer)?
    • Are you using the security card for identification?
    • You can safely use the Internet banking of WOORI-Bank if you obtain this security certificate.
    • You will move to the security verification page, if you click the following button.
    • Start Date: August – September Planned.

    Unsuspecting users might believe they do need to perform this verification and thus click the button. Initially, the user will be directed to the following page that will ask for their name and Korean resident registration number:


    Figure 3. Information is asked

    The following screen asks for more information such as their cell phone number, account number, account password, user ID, user password, and certificate password:


    Figure 4. Additional information is asked

    These phishing sites abuse the trust that users have in their banks to get financial and personal information from users. They are made to think that they are entering their information in the bank’s real online banking site, when in fact they are not. Instead, the information ends up in the hands of the attackers who created this malware. (The phishing site and associated malware are all detected by Trend Micro products.)

    While these may represent an evolution in terms of the chosen targets, the malware used is still not as sophisticated as what is typically used elsewhere. In addition, banking threats using various methods to steal information from Korean users have been seen multiple times recently.

    Banking threats in general were described in our crimeware paper last year. However, it is likely that we will see these more sophisticated threats hit these banks in the future.

     
    Posted in Bad Sites, Malware | Comments Off


     

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