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. 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.