Tools

Android Security Modules (ASM)

Android, iOS, and Windows 8 are changing the application architecture of consumer operating systems. These new architectures required OS designers to rethink security and access control. While the new security architectures improve on traditional desktop and server OS designs, they lack sufficient protection semantics for different classes of OS customers (e.g., consumer, enterprise, and government). The Android OS in particular has seen over a dozen research proposals for security enhancements.

We seek to promote OS security extensibility in the Android OS. We propose the Android Security Modules (ASM) framework, which provides a programmable interface for defining new reference monitors for Android. We drive the ASM design by studying the authorization hook requirements of recent security enhancement proposals and identify that new OSes such as Android require new types of authorization hooks (e.g., replacing data). We describe the design and implementation of ASM and demonstrate its utility by developing reference monitors called ASM apps. Finally, ASM is not only beneficial for security researchers. If adopted by Google, we envision ASM enabling in-thefield security enhancement of Android devices without requiring root access, a significant limitation of existing bring-your-own-device solutions.

For more information on ASM, including source code, please visit androidsecuritymodules.org.

NativeWrap

NativeWrap is an application wrapper for Android that configures native Android applications from URLs supplied by the user, which are then installed on the device. The whole process takes little or no effort from the user, as NativeWrap's WebView wrapper comes preconfigured with security best practices (for e.g. SSL Pinning, Force HTTPS, etc.).

For more information on NativeWrap, including source code and link to Google Play Store version, please visit wspr.csc.ncsu.edu/nativewrap/.

Aquifer

Modern OSes such as Android, iOS, and Windows 8 have changed the way consumers interact with computing devices. Tasks are often completed by stringing together a collection of purpose-specific user applications, as shown in the figure above (e.g., a barcode reader, a social networking app, a document viewer). As users direct this workflow between applications, it is difficult to predict the consequence of each step. Poor selection may result in accidental information disclosure when the target application unknowingly uses cloud services. Aquifer is a policy framework and system for preventing accidental information disclosure in modern operating systems. In Aquifer, application developers define secrecy restrictions that protect the entire user interface workflow defining the user task. In doing so, Aquifer provides protection beyond simple permission checks and allows applications to retain control of data even after it is shared.

For more information on Aquifer, including source code, please visit wspr.csc.ncsu.edu/aquifer/.

iOS Access Control

We have open sourced a number of our tools from SandScout and iOracle papers.

UiRef

Mobile applications frequently request sensitive data. While prior work has focused on analyzing sensitive-data uses originating from well-defined API calls in the system. In contrast, sensitive data entered into text boxes is hard to semantically classify. UiRef (User Input REsolution Framework) provides an automated approach for resolving the semantics of user inputs requested by mobile applications. UiRef’s design includes a number of novel techniques for extracting and resolving user interface labels and addressing ambiguity in semantics, resulting in signicant improvements over prior work. We used UiRef to 50,162 Android applications from Google Play and used outlier analysis to triage applications with questionable input requests. We idenitified concerning developer practices, including insecure exposure of account passwords and non-consensual input disclosures to third parties.

For more information on UiRef, please visit wspr.csc.ncsu.edu/uiref/.

Whyper

Application markets such as Apple’s App Store and Google’s Play Store have played an important role in the popularity of smartphones and mobile devices. However, keeping malware out of application markets is an ongoing challenge. While recent work has developed various techniques to determine what applications do, no work has provided a technical approach to answer, what do users expect? In this paper, we present the first step in addressing this challenge. Specifically, we focus on permissions for a given application and examine whether the application description provides any indication for why the application needs a permission. We present WHYPER, a framework using Natural Language Processing (NLP) techniques to identify sentences that describe the need for a given permission in an application description. WHYPER achieves an average precision of 82.8%, and an average recall of 81.5% for three permissions (address book, calendar, and record audio) that protect frequently used security and privacy sensitive resources. These results demonstrate great promise in using NLP techniques to bridge the semantic gap between user expectations and application functionality, further aiding the risk assessment of mobile applications.

For more information on WHYPER, including source code and data sets, please visit sites.google.com/site/whypermission/.

ded

Smartphone applications are frequently incompletely vetted, poorly isolated, and installed by users without restraint. Smartphone research frequently needs to understand how these applications behave. ded is a project which aims at decompiling Android applications. The ded tool retargets Android applications in .dex format to traditional .class files. These .class files can then be processed by existing Java tools, including decompilers. Thus, Android applications can be analyzed using a vast range of techniques developed for traditional Java applications.

For information regarding obtaining and using ded, please visit siis.cse.psu.edu/ded.

Fortify SCA

As part of theh ded project, we developed custom static analysis rules for the (now HP) Fortify Static Code Analyzer (SCA) tool. These rules test for a breadth of security vulnerabilities and dangerous functionality, as described in our USENIX Security paper. The specific rules are explained in more detail in our Technical Report. The final Fortify SCA ruleset used for this paper is available at the below link.

TaintDroid

The TaintDroid project provides realtime analysis to watch how applications use different types of privacy sensitive information. TaintDroid uses dynamic taint analysis to track taint markings assigned to data when it is accessed from application programming interfaces. When information leaves the phone's network interface, TaintDroid records any present taint markings. To provide realtime analysis on smartphones, TaintDroid has a carefully designed architecture, trading tracking granularity for performance.

For information regarding obtaining and building TaintDroid, please visit appanalysis.org.

XATTR Support for YAFFS2

During my research with the Android smartphone platform, I've needed to store security information in XATTRs. Unfortunately, Android uses the YAFFS2 NAND file system on many of its devices, and YAFFS2 doesn't support XATTRs out of the box. The following patch is my implementation of XATTR support for YAFFS2.

split_bootimg.pl

The Android boot.img file contains a kernel and a ramdisk. While researching Android, I've needed to manipulate the ramdisk of a phone. I created the split_bootimg.pl script to parse the boot.img file format and extract the parts.

The following example uses the boot.img from the full TC4-RC28 update: 

% ./split_bootimg.pl boot.img 
Page size: 2048 (0x00000800)
Kernel size: 1388548 (0x00153004)
Ramdisk size: 141518 (0x000228ce)
Second size: 0 (0x00000000)
Board name: 
Command line: no_console_suspend=1
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.

Extract the ramdisk. 

% mkdir ramdisk
% cd ramdisk
% gzip -dc ../boot.img-ramdisk.gz | cpio -i
% cd ..

Make any changes necessary (e.g., set ro.secure=0 in default.prop).

Recreate the cpio archive using the mkbootfs binary produced from building the Android source code (The cpio utility in OS X does not recognize the newc format, therefore mkbootfs is the best option for OS X users). 

% mkbootfs ./ramdisk | gzip > ramdisk-new.gz

Recreate the image file using the mkbootimg binary produced from building the Android source code. 

% mkbootimg --cmdline 'no_console_suspend=1 console=null' \
  	    --kernel boot.img-kernel \
	    --ramdisk ramdisk-new.gz \
            -o boot-new.img

Additional Notes: