A static analysis tool for identifying application communication-based vulnerabilities.

Erika Chin, Adrienne Porter Felt, Kate Greenwood, David Wagner (UC Berkeley)

Contact: android at eecs.berkeley.edu

Overview
Android supports inter-application communication through the use of Intents. Unfortunately, Intents may also make your application vulnerable to other applications. The contents of Intents can be sniffed, modified, stolen, or replaced, which can compromise user privacy. Also, a malicious application can inject forged or otherwise malicious Intents, which can lead to breaches of user data and violate application security policies.

ComDroid is a 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.

You can read our research paper, Analyzing Inter-Application Communication in Android, for more information about how our static analysis tool works. This paper was presented at the 9th Annual International Conference on Mobile Systems, Applications, and Services (MobiSys 2011) and you can find our slides at [pdf, pptx].

ComDroid (ver. 1.02)
Through this site, you will be able to upload your .apk and ComDroid will return a list of security warnings. Specifically, ComDroid will tell you whether your application has any exposed Intent communication, exposed components, and other forms of developer misunderstanding.

Upload your app for analysis. Don't worry: the results will be displayed within a minute, and your app won't be saved on our server after the analysis is complete.

Key
For each warning of exposed communication you may see:


Unauthorized Intent Receipt

• Broadcast Theft
  This warning indicates that the application is sending an implicit Broadcast Intent without requiring potential receivers to have a Signature or SignatureOrSystem permission. A malicious receiver can eavesdrop on this broadcast Intent, and any data in this Intent can be leaked. If the broadcast is an ordered broadcast, a malicious receiver could steal the Intent (and stop it from propagating to other receivers) or inject false result data into the original sending component. If the broadcast is a sticky broadcast, an attacker can remove the Intent, preventing it from being sent to future receivers. Consider whether the information being sent is sensitive.
  
  Fix: This can be fixed by sending an explicit broadcast or requiring potential receivers to have a strong permission.
• Activity Hijacking
  This warning indicates that the application is starting an Activity implicitly. A malicious Activity could intercept the Intent and provide its own UI to the user. The data in this Intent can be leaked, and the attacker can also steal any data the user inputs in the UI (phishing attack). In most cases, when multiple Activities can handle an Intent, the user will be prompted to choose the appropriate Activity to launch. However, the user may select an application to be the default application to launch. Consider whether the information being sent in the Activity is sensitive and whether the information the user inputs into the receiving Activity is sensitive.
  
  Fix: This can be fixed by sending an explicit Intent to start the Activity.
• Service Hijacking
  This warning indicates that the application is starting a Service implicitly. A malicious Service can intercept the service request, steal data contained in the Intent, lie about completing the requested actions, and inject false responses back into the sending component. Consider whether the information being sent to the Service is sensitive and whether the component relies on the actions of the Service or the result of the Service.
  
  Fix: This can be fixed by sending an explicit Intent to start the Service.

Intent Spoofing

• Malicious Broadcast Injection
  This warning indicates that the Receiver is public and does not restrict senders to ones with a Signature or SignatureOrSystem permission. A malicious Intent can send an implicit or explicit Intent to this component. Consider whether this component blindly trusts data in this Intent, takes actions based on receiving this Intent, changes state of the application or performs other sensitive operations.
  
  Fix: This can be fixed by making the component private or protecting the component with a Signature or SignatureOrSystem permission.
• Malicious Activity Launch
  This warning indicates that the Activity is public and does not restrict senders to ones with a Signature or SignatureOrSystem permission. A malicious Intent can send an implicit or explicit Intent to this component. Consider whether this component trusts data in this Intent, takes actions based on receiving this Intent, or changes state of the application or performs other sensitive operations.
  
  Fix: This can be fixed by making the component private or protecting the component with a Signature or SignatureOrSystem permission.
• Malicious Service Launch
  This warning indicates that the Service is public and does not restrict senders to ones with a Signature or SignatureOrSystem permission. A malicious Intent can send an implicit or explicit Intent to this component. Depending on the duties of a particular Service, it may leak information or perform unauthorized task. Consider whether this component trusts data in this Intent or performs sensitive operations.
  
  Fix: This can be fixed by making the component private or protecting the component with a Signature or SignatureOrSystem permission.

Note: Each registration of a dynamic receiver is treated as a separate interface (because the Intent filters can be changed), so the name of the component is appended with an asterisk and the location of the registerReceiver() call.


Other Warnings

• Action Misuse
  This warning indicates the application is sending an implicit Intent with a unique action to an internal component that handles that action. Unless a component is purposely sending an broadcast Intent to be delivered to it's own receiver AND other applications' receivers (which we have never seen), this form of use is a mistake that unnecessarily exposes both the Intent and the receiving component.
  
  Fix: Make the Intent explicit and make the receiving component private.
• Protected System Broadcast w/o action check
  This is a special case of a Malicious Broadcast Injection attack. The warning indicates that a component receives only protected system broadcasts, and although only the system can send these types of actions, the component is still publically accessible to all other applications by explicit Intents.
  
  Fix: Keep the component public, but add a check to the component's entry point (onReceive, onStart) that checks that the action in the received Intent is the expected system action. (Only the system can send this action, so it will ensure that the Intent is from the system.)

This work is partially supported by National Science Foundation grant CCF-0424422 and a gift from Google. This material is also based upon work supported under a National Science Foundation Graduate Research Fellowship. Any opinions, findings, conclusions, or recommendations expressed here are those of the authors and do not necessarily reflect the views of the National Science Foundation.