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

  • Recent Posts

  • Calendar

    August 2012
    S M T W T F S
    « Jul   Sep »
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Archive for August 29th, 2012




    Back in October of 2010, Apple announced they would drop support for Java. This did not spur Oracle to directly support this Unix platform as it did for other Unix operating systems. The delay this caused in Java updates allowed OS X to play a role in clickfraud schemes among other nefarious activities. Apple finally responded by producing their own updates culminating in Java 6 update 33. Since then, another change to Java 6 affects time zone changes in two different regions. It seems unlikely OS X will receive further updates for Java 6 by Apple.

    On August 14th 2012, Oracle released Java 7 update 6 for Lion and Mountain Lion OS running on Apple’s Mac platform. Oracle’s direct support for OS X brings an end to blaming Apple for slow Java updates. The future of Java and its relative security is now clearly in the hands of Oracle. Within two weeks of Oracle releasing their version of Java 7 update 6 for OS X, an exploit was discovered that affected Windows, where OS X and Linux have the same vulnerability. This vulnerability affects Firefox, IE 9, and Safari 6. Oracle’s record is not sterling at offering timely Java exploit patches, and the clock is ticking.

    A Java in Mac Background

    Java was invented at Sun in the early 1990s. This programming environment helped bridge differences between operating systems from mainframes to embedded devices. Java was even seen as an alternative control method to that of Microsoft’s ActiveX, introduced in 1996, to extend Microsoft’s COM and OLE OS communications. In 2000. Windows replaced JavaScript with ActiveX as their API for their browser. This plugin API had been developed for Netscape. JavaScript is not Java, but Netscape considered Java to represent a client-server solution offering a distributed OS. Microsoft’s Internet Explorer 5.5 ActiveX exposed OS applications to the network, where Microsoft expected broad adoption of their applications would increase Windows’ influence over the Internet.

    Microsoft’s stated reason for making the change to ActiveX extending their browser was to improve security. This occurred as Microsoft dropped Windows Internet Name Service (WINS) in favor of DNS that offered name hierarchy, the basis for today’s certificate authority. ActiveX seemingly became a replacement strategy for WINS as their means to dominate the Internet. Instead, malefactors used ActiveX over the Internet to control Windows applications. ActiveX did not establish Windows as a dominant player on the Internet, nor did ActiveX improve security.

    Android adopted Java in 2005 to establish a Java Runtime Environment (JRE). Sun open-sourced Java under the GPLv2 in November 2006. Unhappy exceptions were not permitted for mobile applications, Google developed its own Java Virtual Machine (JVM) technology, called Dalvik that avoided programming interface constraints and transformed JRE’s stack approach into Java Virtual Machine’s (JVM) use of registers.

    Since then, Sun was acquired by Oracle in 2010. Apple has not offered an uninstaller for Java, and programs using Java may not heed disable checks in Apple’s Java control panel and attempt to use Java anyway. Many of these same programs also fail to notice Oracle’s control panel for Java 7 update 6, nor accept the location of the Java 7 environment as being valid. These Java issues will take some time to be resolved, but Apple has made their intentions clear by no longer automatically installing Java and not supporting Java 7.

    Apple App Rules

    The Mac App Store Review Guidelines rule number 2.24 states that:

    “Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected”

    By controlling how applications are updated, what meta-information and shortcuts are permitted, prohibiting auto-launching without user consent, and prohibiting the downloading of other applications or modifications – all these has the goal of improving security. Enforcing these security assurances would be less practical and more open to exploitation by malefactors if Java were permitted.

    In addition, Apple has a history of shunning cross-platform libraries that pass execution with data structures over the stack they consider inherently less optimal. Apple opted to use Objective-C, which exchanges messages and not execution. This language was developed in the early 1980s for the NeXT multi-media computer that became the platform for the first browsers then ported as Netscape and Internet Explorer.

    Will we eventually say goodbye to Java-based apps like Cyberduck and to Java itself on OS X versions that came before Lion?

    What does this mean for OS X users?

    First, back up your system before making any changes to Java. These changes may break non-Apple applications, particularly those that rely on Java to run. While Java is not used by OS X, be aware if something goes wrong with one of the non-Apple applications or a new vulnerability is actively being exploited. There is no install/uninstall utility friendly to both Apple and Oracle environments to properly install or remove existing Java virtual runtimes.

    Users may not have installed the Java provided by Apple. Not installing this will cause OS X to prompt the user to install Java when a application attempts to use Java. Once Apple’s Java is installed followed by the installation of Oracle’s, under System Preferences normally located on the Dock, the Java cache should be cleared by clicking on Java icon located under the Other section.

    This action opens the Java Control Panel. In the Java Control Panel, click on Settings under Temporary Internet Files and click on the Delete Files button in the Temporary Internet Files window. This will open the Delete Files and Applications window, click OK to confirm.

    You may find that Chrome, which is a 32-bit browser, does not support the 64-bit Java 7.

    If you want to remove Java 7, Oracle has provided removal instructions in this page. Their instructions describe restoring a symbolic link to regain the function of the /Library/Internet Plugins/JavaAppletPlugin.plugin after placing it in the trash as the method for removing Oracle’s version when restoring Apple’s.

    Uninstalling Java 6 provided by Apple without installing Oracle’s Java 7 can be done manually by removing “JavaVM.framework,” located at /System/Library/Frameworks/. Additionally, this will also require removing links at the following directories pointing to the runtimes in the framework:

    • /System/Library/Java/JavaVirtualMachines
    • /Library/Java/JavaVirtualMachines

    Deprecating Adobe Flash and Java by Apple is aimed at ridding OS X and iOS of problematic languages causing the majority of vulnerabilities and problems. A question comes to mind: will HTML5 prove to be safer when everyone still wants to see the dancing fruit?


    Coming Soon: The TrendLabs Security Intelligence Blog will be the new Malware Blog

     
    Posted in Exploits, Vulnerabilities | Comments Off



    During one of our brainstorming sessions looking for interesting research projects, our group thought about how most mobile applications are, in essence, “browsers-in-a-box”.

    Let me explain. When you open your favorite app, chances are it tries to access certain web pages and display the results in a certain way. Not all mobile apps do this, just most of them. I’m not only talking about those Amazon or eBay apps (which obviously do behave like browsers that limit their queries to their specific servers) but also apps like Flipboard. I love Flipboard, but at the very core of it, it’s just accessing Facebook and Twitter and displaying it in a pretty way (okay, very pretty).

    Can this make apps more vulnerable to something that regular browsers are expecting users to do i.e. behaving unexpectedly? For instance, if an app is performing canned requests to a single specific site, can someone take advantage of this behavior to subvert the app or the site?

    I set out to work on this and created an environment to sniff all traffic coming to and from mobile applications both in Android and iPhone/iPad environments. I tested lots of apps, checking their traffic and looking for something that might be exploitable and I did find things.

    There is one particular resource management game a friend recommended that apparently is very popular. It turns out this game rewards players with a prize every weekend. They don’t do that anymore and it might be my fault, although I never contacted them directly. The way this worked is as follows: if you liked the game’s manufacturer on Facebook, they would share with you a certain password that would unlock resources only during a particular weekend. They’d change the password every weekend and it would only work during those two days.

    The way this was implemented was by means of a plain HTTP request ‘here is the password’ and response ‘here is 10 gold and 10 food for you, thank you’. In other words, you could alter the state of the game from the outside by means of a simple, unencrypted HTTP request. Spoofing the server to point to a local server in the lab setup and getting a fake response of ‘here is 10000 gold and 1000 food’ was, of course, trivial. If ever I’ll see my friend again and show him my progress, he’s going to be quite amazed.

    The bottom line of this mini-attack was clear: unprotected canned HTTP is not trustworthy.

    There were other problems in different applications, like a fitness application that sells exercise routines to be displayed in your Android device. The routines consist of exercise descriptions, images, trainer explanations with instructions, timings and order of each routine. All these materials are contained in an XML file with links to each image and sound file. Yes, you guessed it, the XML was downloaded in plain-text, unencrypted HTTP traffic. I could have tried to access the paid content by guessing the XML file names but I didn’t try.

    I saw some others but my problem with the whole project came when I had to put my findings in writing. The problems I found were so heterogeneous that it was difficult to differentiate this project from any web application pentest. So the clients are mobile applications but I was really looking at somebody’s unsecure web code. At the end of the day, my starting axiom was too true: all mobile apps are essentially web clients therefore they are as unsecure as a browser and that’s how you should treat them.

    A failed project, I hear you say? Perhaps, but it opened my eyes with respect to how we – and app developers – need to treat mobile applications as untrusted browsers-in-a-box.


    Coming Soon: The TrendLabs Security Intelligence Blog will be the new Malware Blog

     
    Posted in Mobile | Comments Off


     

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