Sunday, 29 January 2012

Do Androids Dream of Secure Apps?

I love the book “Do Androids Dream of Electric Sheep?” by Philip K Dick (Kindle link here), the book Ridley Scott based his science fiction movie Blade Runner on. The book tells a compelling tale pondering on the age-old question ‘What makes us human?’.

I am not a philosopher, so I leave it up to you to answer the above question, while I will make an attempt to keep this blog to the topic of application security and especially the question of today ‘how to write a secure Android app?’ or better, Astyran’s speciality: ‘how to test an app for security?’.

Hmm, now that I think about it, maybe I should just have made a reference to another Ridley Scott movie, “Alien”, since this is more about ripping apart an app.

Luckily many people tried to answer the question about secure apps, so here is my list of application security resources for Android apps with some - hopefully useful - comments. 


A lot of information is available on the Android security model, so here is only a quick rundown:

  • No app has by default permissions to perform anything that would adversely impact other apps, the Android OS or the user;
  • Applications, whether Java based, native or hybrid, are sandboxed, and at installation time, the user must explicitly give permissions to share resources or data with other apps;
  • The security model is based on Linux. Normally apps get a distinct user-id, but the developer can set a fixed one which allows (maximal two apps at the same time) to share data and resources.
  • Data is by default only accessible by the app’s user-id, but files can be made world-readable and/or world-writeable by setting a flag in the code at creation time.  

Note however that modifications by the phone vendors might have removed all these security features.


Google provides a nice overview of the security features build into Android. This is good reading before the start of development or security review. They also provide a security FAQ for developers, security practices (I still need to integrate most high-level practices in the checklist below), more general security information and a discussion group.

The above information (and especially the FAQ) can be used to make a high-level checklist for your Android app security review, such as the table below.

I stress that these are only Android-specific issues, generic application security vulnerabilities or weaknesses must be checked too! 

Item Check Notes


Verify the signature on the .apk file.

Make certain this is not the debug key generated by the Android SDK tools.

Not security related, but might be interesting for your client: make certain that the cert validity ends after 22/10/2033 or the app cannot be published in the Android market (a validity period of more than 25 years is recommended).
The certificate can be self-signed. It is just used to grant or deny apps access to signature level permissions and requests to share the same user-id.
This means anyone can publish an app, without being controlled. An amusing example of what might happen is given on Jon Oberheide’s blog.


Verify if a shared user-id is requested, which one is used, and assess the possible security impact. Check out the requested user-id, in the <manifest> element in the AndroidManifest.xml file.
This request only succeeds if the apps are signed by the same certificate.
Whether or not this sharing of user-ids is a security issue, can only be verified by looking at both apps. Talk to your customer, or make this remark in your report.


Verify all requested permissions and ensure that they are appropriate.
Install the app and/or look at the <uses-permission> element in the AndroidManifest.xml file.
’Appropriate’ depends on your customer’s business goals.


Verify all requested permissions and make note of the potential attack surface. Input (e.g. from logs, test messages, internet) might be malicious and might be a source of Cross-Site-Scripting vulnerabilities or other defects.


Verify all permission definitions and make certain they are correct and inform the user appropriately when needed. Permissions for app operations are configured in the <permission> element of the AndroidManifest.xml file.


Check the permissions given to other applications and verify that they are not overly broad or dangerous. This is done by verifying the android:permission attributes in the AndroidManifest.xml file.

Check the <activity>, <service>, <receiver> and <provider> tags. Note that services and activities are exported by default. If this is unwanted, they should have an android:permission attribute. Receivers are also by default exported. Check the <receiver> element.


Verify the URI permissions for a content provider and ensure the are correct and not overly broad or dangerous. Check out the permissions and intents in the <grant-uri-permission> element in the AndroidManifest.xml file and grantUriPermission(), revokeUriPermission() and checkUriPermission() in the source code.


Implement input validation within an  intent receiver to confirm that it is properly formatted for the invoked receiver, service, or activity. Note that intent filters are not security features; this is often misunderstood by developers. Verify this by looking at the source code for all receivers, activities and services that are exported (this is the default).


Check the fine-grained permissions granted to other apps. Verify the calls to CheckCallingPermission() in the source code. This is a more fine-grained method to check permissions.


Verify that file-permissions are not overly broad. Look at the permissions of files/databases created by the app, or verify the permissions in the source code, especially world readable or writeable settings (look for MODE_WORLD_READABLE or MODE_WORLD_WRITEABLE flags)


Verify the use the execSQL(). Look at the source-code. ExecSQL() is vulnerable to SQL Injection.


Review storage on external storage such as SD cards. These should never be used for confidential data. Encryption is only available since Gingerbread, but does not block apps from accessing each other’s data. Files stored on external storage are world-readable and writeable.


Review the loading of executable files from external storage. See above. The executable files should be signed and cryptographically verified before loading. Verify this by looking at the source code.


Review the possible information leakage using the back-up service. Android makes no guarantee about the security of your data while using back-up. Cloud storage and transport service might differ from device to device.
Applications using the device provided backup have the backup agent declared in the android:backupAgent attribute in the in the AndroidManifest.xml file.


Verify the use of Security Best Practices for in-app billing. Check out the list of Security Best Practices for in-app billing and verify that it is implemented.


Verify that logs do not contain confidential information. Logs are a shared resource on Android, and are available to an application with READ_LOGS permission.
Verify the logs manually or review the source code and searching for ‘Log’ (the relevant class-name is android.util.Log)


Verify that usernames and passwords are not stored on the device. Review files created by the application or the source code if available.
When an AccountManager is used, the CREATOR must be checked before passing the credentials. Other possibility is to use checkSignature() to verify that only your own applications can access the AccountManager or use the KeyStore if only one application will use the credential. 


Verify the use of a secure random number generator to initialize cryptographic keys. Not really Android specific.
Look for SecureRandom and correct seeding, and KeyGenerator in the source code. Do not create your own encryption protocol. Keys must be stored in a KeyStore.


Verify the security design and implementation. Check the implementation of Android best practices.

Note: I intend to make this into a more detailed checklist, if not already covered by the above checks.


Note that some JAVA tools might be relevant too. Of course, there are also commercial tools available, but I leave it to their marketing departments to spread that message.

Tool Comments
androguard Provides reverse engineering and malware analysis of Android applications.
androidAuditTools Toolset written in Ruby to visualize file system differences before and after running an app. This blog explains it all.
ApkInspector Visualizes compiled Android packages and their corresponding DEX code and tries to create a unified platform that combines several existing Android reverse engineering tools. A video with overview can be streamed on Tudou.
napktool Decodes binary Android apps to nearly original form and rebuild them after making some modifications.
ComDroid COMDROID is an online tool that detects application communication vulnerabilities. It emits warnings for both sending- and receiving-based Intent vulnerabilities and gives additional details on when the developer may be misusing Intents.
ded Decompiles Android Apps.
dex2jar This converts Android's .dex format to Java .class format. Afterwards one can use a Java de-compiler such as JAD or JD-GUI to look at the source code.
DroidBox Offers dynamic analysis of Android Applications in a sandbox.
pptpd Not really an Android tool, but can be used to set up a VPN server. Configure your device to connect to this VPN in order to sniff the network traffic between app and server.
smali Assembler/Disassembler for Android’s dex format.
smartphonesdumbapps Scripts to analyse Android and iPhone applications from Denim Group.
StowAway STOWAWAY is an online tool for identifying permission use in Android applications.
TaintDroid Tracks how apps use sensitive information. In order to use this, you must flash custom-build firmware in your device.

Deliberately Vulnerable Applications for training purposes

I just updated my generic list of deliberately vulnerable applications, here the Android applications:

  • ExploitMe Mobile Android Labs: This is an open source project by SecurityCompass demonstrating Android mobile hacking. The labs will teach you about:
    • Parameter manipulation of mobile traffic
    • Encryption of traffic
    • Password lock screens
    • File system access permissions
    • Insecure storage of files
    • Insecure logging
  • OWASP GoatDroid: This is the Android equivalent to the iGoat Project. This project will help educate Android developers on security issues they’ll encounter when writing applications.


Other Resources

Some links I found useful while doing the research for this blog.


Remember, the above items are not the only things that are important for Application Security on Android, they are just the Android specific items! Everything else (e.g. see OWASP testing guide) must still be verified too! Think SQL Injection, XSS, secure communications, …


29/01/2012 - first release.

1 comment:

  1. I truly enjoy looking through on this post, it holds good articles from you. If you keep making great posts I will come back every day to keep reading!

    Android Programmers