Each software application installed on a mobile smartphone, whether a new app or an update, can introduce new, unintentional vulnerabilities or malicious code. These problems can lead to security challenges for organizations whose staff uses mobile phones for work. In April 2014, we published a blog post highlighting DidFail (Droid Intent Data Flow Analysis for Information Leakage), which is a static analysis tool for Android app sets that addresses data privacy and security issues faced by both individual smartphone users and organizations. This post highlights enhancements made to DidFail in late 2014 and an enterprise-level approach for using the tool.

Analyzing Dataflows in Android Application Sets

The SEI's CERT Secure Coding Team has assisted numerous government and nongovernment organizations vet software developed for the Android operating system (OS), which has dominated the mobile device market, but continues to struggle with security problems. The Android OS has become the platform of choice for the Department of Defense (DoD), which recently purchased 7,000 Samsung Galaxy Note II mobile smartphones for the Army's Nett Warrior System, which aims to arm soldiers with the technology they need to make faster, more accurate decisions during combat.

In early 2014, we designed and implemented a novel taint flow analyzer (DidFail) that combines and augments the existing Android dataflow analyses of FlowDroid (which identifies intra-component taint flows) and Epicc (which identifies properties of intents such as the action string) to track both inter-component and intra-component dataflow in a set of Android applications.

DidFail enables an organization (e.g., enterprise, app store, or security system provider) to pre-analyze apps, so that the analysis for potential dataflow problems (within the set of apps on the phone) is fast when a user requests to install a new app. Phase 1 of DidFail can be performed on one application at a time and, once completed, does not need to be run again. Phase 2 of DidFail (app set analysis) typically takes only seconds.

DidFail addresses a problem often seen in dataflow analysis: the leakage of sensitive information from a sensitive source to a restricted sink. Both "source" and "sink" are commonly used terms in flow analysis. We define source as an external resource (external to the app, not necessarily external to the phone) from which data is read. We define sink as an external resource to which data is written.

By analyzing information flow, we can find issues that could affect data integrity and/or privacy. A privacy violation occurs when information flows from a sensitive source to a sink that is not authorized to receive the data. An integrity violation occurs when untrusted data is sent to a sink that is supposed to store only trusted data.

The DidFail analysis of a given set of apps takes place in two phases:

1. In the first phase, we determine the dataflows enabled individually by each app and the conditions under which these flows are possible.
2. In the second phase, we build on the results of the first phase to enumerate the potentially dangerous dataflows enabled by the whole set of applications.

DidFail differs from pure FlowDroid, which also analyzes flows of tainted information. FlowDroid taintflow analysis is limited to a single component of a single app; DidFail analyzes potentially tainted flows between apps and, within a single app, between multiple components.

Recent Enhancements to DidFail

In 2014, we worked to improve DidFail in collaboration with graduate students from Carnegie Mellon University's Information Networking Institute (INI) and Department of Electrical and Computer Engineering (ECE). The graduate students are Will Snavely (INI), Jonathan Burket (ECE), Jonathan Lim (INI), and Wei Shen (INI). Together, we made improvements to DidFail to help it succeed with more applications and detect more flows.

First, we developed a new framework for testing the DidFail analyzer, which includes a setup for cloud-based testing and instrumentation to measure the performance of the analyzer. The new setup for cloud-based testing enables us to take advantage of commercially-available powerful virtual machines and to use multiple virtual machines in parallel for faster test completion. Additionally

• We modified DidFail to use the most current version of FlowDroid and Soot (which includes a better module for converting between Android .dex representation and Soot's Jimple intermediate representation), increasing its success rate from 18 percent to 68 percent on our test suite of real-world apps.
• We made enhancements to enable analysis of some dataflows through static fields, BroadcastReceiver components, and Service components.
• We developed new apps to test the analytical features added to DidFail.
• Using the improved DidFail analyzer and the cloud-based testing framework, we tested the system on the new test apps and apps from the Google Play store.

The SEI technical report Making DidFail Succeed: Enhancing the CERT Static Taint Analyzer for Android App Sets details the new testing framework, enhancements to DidFail, newly developed test apps, and test results. Also, the latest enhancements are available for free download, with instructions for building DidFail from the source code.

DidFail Practicality at an Enterprise Level

Our initial prototype yielded too many false positives. In particular, DidFail gave too many warnings about potential flows that turned out not be realizable. We are currently improving the precision of DidFail, while also developing a realistic and feasible plan for deploying it at the enterprise level.

Deploying DidFail at an Enterprise Level

Enterprises could use DidFail to protect their (and their personnel's) data on Android smartphones. DidFail identifies dataflows from sources to sinks for a set of apps. When implemented in an enterprise, there will be multiple apps, numerous flows, and users unfamiliar with the concept of a dangerous flow. As recommended in the NIST report, Vetting the Security of Mobile Applications, organizations need to create policies concerning permitted and forbidden dataflows. An enterprise could use DidFail in conjunction with a commercial security system to help set and enforce dataflow policies. The enterprise's subdivisions (e.g., IT, security, and administration) and Android end-users could also provide input useful for protecting the organization's particular types of sensitive data in its particular use scenarios. Policies could be expressed as white lists or black lists:

• White list example: A policy might specify that data from the microphone cannot flow to any sink except the public switched telephone network (PSTN).
• Black list example: A policy might be set to alert the user if an app set could allow data to flow from on-device storage to the internet.

As future work, DidFail can be extended to report what user interaction, if any, is required for a flow to occur. For example, consider an app that records audio from the microphone and sends this audio data over the internet. This flow might be considered unacceptable if the app launches when the phone starts up and doesn't require any user interaction. On the other hand, the flow might be considered acceptable if the app requires the user to press a "record" button before reading from the microphone.

When flows are identified that don't comply with one or more policies, there are a variety of mitigations or steps that can be taken:

• For personal use, the system can alert the user to the existence of the flow and confirm whether the user still wants to install the app.
• For use in an enterprise, the system might refuse installation of the app. Alternatively, if the non-compliant flow relies on the existence of multiple installed apps, the system could give the option to remove previously-installed apps to prevent the non-compliant flow.
• Another option would involve dynamically blocking non-compliant flows, which can be accomplished through a variety of approaches:

-The app could be blocked from reading particular sources.
-The app could be blocked from writing to particular sinks.
-When an app sends an implicit intent, (i.e., an intent that does not expressly designate its recipient), the system could block that intent from being sent to certain other apps.

These dynamic changes would require modifications to the Android OS. Some systems that work within or replace the Android OS, such as CyanogenMod and TaintDroid, can perform those operations.

Our DidFail taint flow analysis tool could be incorporated in many application security-checking systems. We hope DidFail will eventually be used widely, including in:

• public app stores and their integrated security systems such as Google Play Store;
• corporate enterprise Android security systems;
• mobile computing security systems; and
• government app stores and processes, including NIST's AppVet mobile app vetting system, DHS's Carwash system for inspecting app security, DARPA Trans Apps secure app store, and the DoD's planned enterprise Mobile Application Stores (MAS) and conjunct Mobile Device Management (MDM) systems.

Enterprises wishing to use smartphones in a safe and effective manner need to institute policies governing their use. Studies such as Android Permissions: User Attention, Comprehension, and Behavior have shown that end users, if presented with a request for permissions, generally approve the permission. The research results discussed in Android Permissions Demystified indicate that often developers request unnecessary permissions and do not understand the true implications of permissions. The Android platform requires users to accept all requested permissions or the app does not install. In contrast, CyanogenMod, which is an open-source Android-based OS, allows the user to grant or deny individual permissions to the app.

Similar policies could be used for an enterprise's iPhone and Android devices at a more abstract level, to prevent dataflows from a specified source to a specified sink (e.g., an organization that prohibits data from the corporate email to be sent out as a text message).

Our work focuses on the mechanism rather than the policy, but our analytical mechanism would enable the enterprise to enforce policies it needs or wants. Prior to DidFail, no tool existed that would allow organizations to statically trace tainted dataflows through multiple apps.

Beyond using DidFail as a component in a system for setting, analyzing, and enforcing dataflow policies for Android smartphones, enterprises may use DidFail analyses for additional purposes. Security researchers can use DidFail to check for dataflows that can be exploited in ways end users would not expect. Developers can also use DidFail to check if the app being developed might accidentally enable dangerous dataflows.

Other Tool Improvements and Looking Ahead

"New technologies may offer the promise of productivity gains and new capabilities, but if these new technologies present new risks, the organizations' IT professionals, users, and business owners should be fully aware of these new risks and develop plans to mitigate them or be fully informed before accepting the consequences of them," Quirolgico et al. wrote in NIST Special Publication (SP) 800-163 Vetting the Security of Mobile Applications. In addition to developing approaches for implementing DidFail at the enterprise level, our team continues to work to improve the precision and soundness of the tool, so that it enables organizations and individuals to have greater awareness of risks associated with adopting Android smartphones and developing plans for mitigating these risks.

We are interested in collaborating with organizations to pilot future prototypes. Organizations interested in collaborating with us are invited to contact us.

Additional Resources

Read the SEI technical report, Making DidFail Succeed: Enhancing the CERT Static Taint Analyzer for Android App Sets, for more detailed information about the work described in this post.

To download the DidFail tool, please visit https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=508078

Read the SEI technical report, Mobile SCALe: Rules and Analysis for Secure Java and Android Coding, for more information about the work described in this blog post.

To view the Android wiki on the CERT Secure Coding site, please visit https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87150614.