Given the granularity of the Android permission model, there is an opportunity for developers to request more permissions for their app than may be required.
This behavior may be due in part to inconsistencies in permission enforcement and documentation. Although the developer reference docs describe most of the permission requirements for given classes and methods, they’re not 100 percent complete or 100 percent accurate. Research teams have attempted to identify some of these inconsistencies in various ways. For example, in 2012, researchers Andrew Reiter and Zach Lanier attempted to map out the permission require-ments for the Android API available in Android Open Source Project (AOSP).
This led to some interesting conclusions about these gaps.
Among some of the fi ndings in this mapping effort, they discovered incon-sistencies between documentation and implementation for some methods in the WiFiManager class. For example, the developer documentation does not mention permission requirements for the startScan method. Figure 4-1 shows a screenshot of the Android development documentation of this method.
Figure 4-1: Documentation for startScan
This differs from the actual source code for this method (in Android 4.2), which indicates a call to enforceCallingOrSelfPermission, which checks to see if the caller bears the ACCESS_WIFI_STATE permission by way of enforceChangePermission:
public void startScan(boolean forceActive) { enforceChangePermission();
mWifiStateMachine.startScan(forceActive);
noteScanStart();
} ...
private void enforceChangePermission() {
mContext.enforceCallingOrSelfPermission(android.Manifest.
permission.CHANGE_WIFI_STATE,
"WifiService");
}
Another example is the g e t N e i g h b o r i n g C e l l I n f o method in the TelephonyManager class, whose documentation specifi es a required permis-sion of ACCESS_COARSE_UPDATES. Figure 4-2 shows a screenshot of the Android development documentation for this method.
Figure 4-2: Documentation for getNeighboringCellInfo
However, if you look through the source code of the PhoneInterfaceManager class (in Android 4.2), which implements the Telephony interface, you see the getNeighboringCellInfo method actually checks for the presence of the ACCESS_
FINE_LOCATION or ACCESS_COARSE_LOCATION permissions—neither of which are the nonexistent, invalid permission specifi ed in the documentation:
public List<NeighboringCellInfo> getNeighboringCellInfo() { try {
mApp.enforceCallingOrSelfPermission(
android.Manifest.permission.ACCESS_FINE_LOCATION, null);
} catch (SecurityException e) {
// If we have ACCESS_FINE_LOCATION permission, skip the check // for ACCESS_COARSE_LOCATION
// A failure should throw the SecurityException from
// ACCESS_COARSE_LOCATION since this is the weaker precondition mApp.enforceCallingOrSelfPermission(
android.Manifest.permission.ACCESS_COARSE_LOCATION, null);
}
These kinds of oversights, while perhaps seemingly innocuous, often lead to bad practices on the part of developers, namely undergranting or, worse, overgrant-ing of permissions. In the case of undergrantovergrant-ing, it’s often a reliability or func-tionality issue, as an unhandled SecurityException leads to the app crashing.
As for overgranting, it’s more a security issue; imagine a buggy, overprivileged app exploited by a malicious app, effectively leading to privilege escalation.
For more information on the permission mapping research, see www.slideshare.net/quineslideshare/mapping-and-evolution-of-android-permissions.
When analyzing Android applications for excessive permissions, it’s important to compare what permissions are requested to what the application’s purpose really is. Certain permissions, such as CAMERA and SEND_SMS, might be excessive for a third-party app. For these, the desired functionality can be achieved by deferring to the Camera or Messaging applications, and letting them handle
the task (with the added safety of user intervention). The “Mobile Security App” case study later in the chapter demonstrates how to identify where in the application’s components those permissions are actually exercised.
Insecure Transmission of Sensitive Data
Because it receives constant scrutiny, the overall idea of transport security (for example, SSL, TLS, and so on) is generally well understood. Unfortunately, this doesn’t always apply in the mobile application world. Perhaps due to a lack of understanding about how to properly implement SSL or TLS, or just the incorrect notion that “if it’s over the carrier’s network, it’s safe,” mobile app developers sometimes fail to protect sensitive data in transit.
This issue tends to manifest in one or more of the following ways:
■ Weak encryption or lack of encryption
■ Strong encryption, but lack of regard for security warnings or certifi cate validation errors
■ Use of plain text after failures
■ Inconsistent use of transport security per network type (for example, cell versus Wi-Fi)
Discovering insecure transmission issues can be as simple as capturing traffi c sent from the target device. Details on building a man-in-the-middle rig are out-side the scope of this book, but numerous tools and tutorials exist for facilitating this task. In a pinch, the Android emulator supports both proxying of traffi c as well as dumping traffi c to a PCAP-format packet trace. You can achieve this by passing the -http-proxy or -tcpdump options, respectively.
A prominent public example of insecure data transmission was in the imple-mentation of Google ClientLogin authentication protocol in certain components of Android 2.1 through 2.3.4. This protocol allows for applications to request an authentication token for the user’s Google account, which can then be reused for subsequent transactions against a given service’s API.
In 2011, University of Ulm researchers found that the Calendar and Contacts apps on Android 2.1 through 2.3.3 and the Picasa Sync service on Android 2.3.4 sent the Google ClientLogin authentication token over plaintext HTTP. After an attacker obtained this token, it could be reused to impersonate the user. As numerous tools and techniques exist for conducting man-in-the-middle attacks on Wi-Fi networks, interception of this token would be easy—and would spell bad news for a user on a hostile or untrusted Wi-Fi network.
For more information on the University of Ulm’s Google ClientLogin fi ndings, see www.uni-ulm.de/en/in/mi/staff/koenings/catching-authtokens.html.
Insecure Data Storage
Android offers multiple standard facilities for data storage—namely Shared Preferences, SQLite databases, and plain old fi les. Furthermore, each of these storage types can be created and accessed in various ways, including managed and native code, or through structured interfaces like Content Providers. The most common mistakes include plaintext storage of sensitive data, unprotected Content Providers (discussed later), and insecure fi le permissions.
One cohesive example of both plaintext storage and insecure fi le permissions is the Skype client for Android, which was found to have these problems in April 2011. Reported by Justin Case (jcase) via http://AndroidPolice.com, the Skype app created numerous fi les, such as SQLite databases and XML fi les, with world-readable and world-writable permissions. Furthermore, the content was unencrypted and included confi guration data and IM logs. The following out-put shows jcase’s own Skype app data directory, as well as partial fi le contents:
# ls -l /data/data/com.skype.merlin_mecha/files/jcaseap -rw-rw-rw- app_152 app_152 331776 2011-04-13 00:08 main.db
-rw-rw-rw- app_152 app_152 119528 2011-04-13 00:08 main.db-journal -rw-rw-rw- app_152 app_152 40960 2011-04-11 14:05 keyval.db -rw-rw-rw- app_152 app_152 3522 2011-04-12 23:39 config.xml drwxrwxrwx app_152 app_152 2011-04-11 14:05 voicemail -rw-rw-rw- app_152 app_152 0 2011-04-11 14:05 config.lck -rw-rw-rw- app_152 app_152 61440 2011-04-13 00:08 bistats.db drwxrwxrwx app_152 app_152 2011-04-12 21:49 chatsync
-rw-rw-rw- app_152 app_152 12824 2011-04-11 14:05 keyval.db-journal -rw-rw-rw- app_152 app_152 33344 2011-04-13 00:08 bistats.db-journal
# grep Default /data/data/com.skype.merlin_mecha/files/shared.xml <Default>jcaseap</Default>
The plaintext storage aspect aside, the insecure fi le permissions were the result of a previously less-well publicized issue with native fi le creation on Android.
SQLite databases, Shared Preferences fi les, and plain fi les created through Java interfaces all used a fi le mode of 0660. This rendered the fi le permissions read/
write for the owning user ID and group ID. However, when any fi les were cre-ated through native code or external commands, the app process inherited the umask of its parent process, Zygote—a umask of 000, which means world read/
write. The Skype client used native code for much of its functionality, including creating and interacting with these fi les.
N O T E As of Android 4.1, the umask for Zygote has been set to a more secure value of 077. More information about this change is presented in Chapter 12.
For more information on jcase’s discovery in Skype, see www.androidpolice .com/2011/04/14/exclusive-vulnerability-in-skype-for-android-is -exposing-your-name-phone-number-chat-logs-and-a-lot-more/.
Information Leakage Through Logs
Android’s log facility is a great source of information leaks. Through develop-ers’ gratuitous use of log methods, often for debugging purposes, applications may log anything from general diagnostic messages to login credentials or other sensitive data. Even system processes, such as the ActivityManager, log fairly verbose messages about Activity invocation. Applications bearing the READ_LOGS permission can obtain access to these log messages (by way of the logcat command).
N O T E The READ_LOGS permission is no longer available to third-party applications as of Android 4.1. However, for older versions, and rooted devices, third-party access to this permission and to the logcat command is still possible.
As an example of ActivityManager’s logging verbosity, consider the follow-ing log snippet:
I/ActivityManager(13738): START {act=android.intent.action.VIEW dat=http://www.wiley.com/
cmp=com.google.android.browser/com.android.browser.BrowserActivity (has extras) u=0} from pid 11352
I/ActivityManager(13738): Start proc com.google.android.browser for activity com.google.android.browser/com.android.browser.BrowserActivity:
pid=11433 uid=10017 gids={3003, 1015, 1028}
You see the stock browser being invoked, perhaps by way of the user tapping a link in an e-mail or SMS message. The details of the Intent being passed are clearly visible, and include the URL (http://www.wiley.com/) the user is visit-ing. Although this trivial example may not seem like a major issue, under these circumstances it presents an opportunity to garner some information about a user’s web-browsing activity.
A more cogent example of excessive logging was found in the Firefox browser for Android. Neil Bergman reported this issue on the Mozilla bug tracker in December 2012. Firefox on Android logged browsing activity, including URLs that were visited. In some cases, this included session identifi ers, as Neil pointed out in his bug entry and associated output from the logcat command:
I/GeckoBrowserApp(17773): Favicon successfully loaded for URL =
https://mobile.walmart.com/m/pharmacy;jsessionid=83CB330691854B071CD172D41DC2C3 AB
I/GeckoBrowserApp(17773): Favicon is for current URL =
https://mobile.walmart.com/m/pharmacy;jsessionid=83CB330691854B071CD172D41DC2C3
AB
E/GeckoConsole(17773): [JavaScript Warning: "Error in parsing value for 'background'. Declaration dropped." {file:
"https://mobile.walmart.com/m/pharmacy;jsessionid=83CB330691854B071CD172D41DC2C 3AB?wicket:bookmarkablePage=:com.wm.mobile.web.rx.privacy.PrivacyPractices"
line: 0}]
In this case, a malicious application (with log access) could potentially harvest these session identifi ers and hijack the victim’s session on the remote web appli-cation. For more details on this issue, see the Mozilla bug tracker at https://
bugzilla.mozilla.org/show_bug.cgi?id=825685.