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

  • Recent Posts

  • Calendar

    July 2014
    S M T W T F S
    « Jun    
     12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
  • About Us

    The permissions in Android devices are designed to guarantee that those Android apps without any declared permissions cannot do anything harmful to the mobile device. Or can they?

    How Android Permissions Work

    Before we get into the details, let’s see how Android permissions work.

    An Android app can access limited system resources. To access sensitive APIs, the app must declare permissions required in AndroidManiflest.XML file. These sensitive APIs include camera function, location data (GPS), Bluetooth and telephony functions, SMS/MMS functions and network/data connections.

    Once an app is installed, the App Installer shows the declared permissions to the user who either accepts or refuses them.

    If a user chooses to grant the permissions, these are applied to the app so long as it is installed. During runtime, the system will no longer notify the user when sensitive APIs are being accessed again. Declining these permissions, on the other hand, aborts the app installation.

    Once an app attempts to use a protected feature but failed to declare the required permission, the runtime system typically throws a security exception, which then terminates the app.

    Given these facts, it appears that the chances of bypassing permissions is slim. Unfortunately, some crafty developers may create apps that can circumvent permissions by abusing the following.

    Misusing the Default Browser to Upload Information

    In Android, an app can launch another app’s component using an intent, an abstract data structure that describes the operation to be executed. Each intent consists of action (the action to be performed) and data required to execute the action. When an app sends out an intent, the mobile OS chooses the appropriate app to handle it.

    An intent with action Intent.ACTION_VIEW, for example, paired with data Uri.parse(“http://www.google.com”) indicates that the app wants to view the Google webpage. If this intent is sent out, the mobile OS determines the best choice to launch the browser.

    With this in mind, a shady developer can develop an app with an intent to open a browser and upload any stolen data to the desired server. Should a malicious app want to upload the Device ID to server http://example.com, the developer can craft the intent this way:

    Since the browser opens the URL, the malicious app does not need to declare android.permission.INTERNET because this was already acquired by the browser app.

    Logcat: Far More Capable than You Think

    Another way to abuse permissions is through the misuse of Logcat. Logcat is a logging system provided by the Android framework and can be used to collect, view, and filter system and app debug output. A set of APIs are also provided for application writers to write debug log into the buffer.

    To read the logs, an app will only need to request android.permission.READ_LOG, which appears to be harmless for an ordinary user to be aware of.

    Developers may write any information into Logcat, which in most cases are debug information. While some of this information are sensitive in nature (e.g. login credentials, credit card numbers), careless developers may forget to remove these when releasing their products. This can be problematic, as malicious apps may read these information from the log message poll and may use these information in their next attack.

    Similarly, the OS also log certain information, which a potential attacker can use to his/her advantage.

    For example, in some versions of Android, when opening a website using the default browser, Logcat logs the URL being opened. Though this act may seem harmless, a malicious app can monitor the log to get URLs and determine user’s preference. This monitoring then enables an attacker to choose the phishing version of the users’ most-visited site. Should users browse the site again, the app may stop the loading site and instead ask the browser to load the phishing version instead.

    Another example is GPS. When using the GPS service provided by system, some apps will log the current GPS data. A malicious app may get updated location information just by auditing the log, to track user.

    Abusing Unprotected Components

    Android apps typically have four components: activity, service, content provider, and broadcast receiver. Because of this, an application may be invoked via multiple entry points. To protect these components from being invoked by arbitrary apps, Android implemented the permissions system.

    Contacts information is provided by system through the use of a content provider and to successfully query data from that content provider, the calling app should acquire android.permission.READ_CONTACTS. Similarly, to install another app, the app need to declare android.permission.INSTALL_PACKAGES. Apart from system pre-defined permissions, apps can also register their own permissions.Whichever permissions are declared by an app, the calling app should acquire those permissions to call the desired app.

    However, there are still too many apps that do not require permissions. This is typical of components designed to be used inside the app. Unwary developers may think that since these are private, no other app (or possible attackers) will know the existence of these components.

    Unfortunately, this gives malicious app writers an opportunity to make their move. A developer may intentionally look for all hidden and private components along with the intent to invoke them by decompiling the targeted app.

    This becomes a grave concern if the flawed app is a system app. Pre-installed system apps usually have powerful capabilities such as installing app, reading sensitive information and even wiping all data stored in the device. Users also cannot uninstall system apps, unless their devices are rooted.

    As found by security researcher Andre Moulu, many pre-installed apps in Samsung Galaxy S3 have serious capability leaks. Based from his research, one service has the ability to install (restore) APK files from a specific directory, but does not enforce permissions and check caller’s authority.

    Moulu also found another service that copies .APK files to a specific directory in the SD card, but failed to enforce permissions or check the caller. Using these two vulnerabilities, a malicious app can drop its payload and use these services to copy the .APK file to a specific directory and install it – all without user’s attention and certainly without the need to acquire permissions.

    To know more about permissions and how to secure your devices, you may read our Digital Life e-Guide When Android Apps Want More Than They Need.





    Share this article
    Get the latest on malware protection from TrendLabs
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon




    • Arie

      There is always a tradeoff between “trust” and “security”. Android needs to include a
      global permissions utility that controls each individual permission for all
      apps. The install also needs to include a Yes/No/Ask me for each permission. For
      example, “Google Search” or any other App, has no reason to “take pictures and
      videos without my confirmation at any time”.

    • Arie

      This is serious… a major weakness of Android. I am surprised Apple, Microsoft and other
      competitors are not capitalizing on this obvious security hole.

    • JCC

      So, in fact it’s not Android that’s the problem, it’s developers making shitty apps.



     

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