This work examines Android application interaction and identifies security risks in application components and provides a tool, ComDroid, that detects application communication vulnerabilities and found 34 exploitable vulnerabilities.
Abstract:
Modern smartphone operating systems support the development of third-party applications with open system APIs. In addition to an open API, the Android operating system also provides a rich inter-application message passing system. This encourages inter-application collaboration and reduces developer burden by facilitating component reuse. Unfortunately, message passing is also an application attack surface. The content of messages can be sniffed, modified, stolen, or replaced, which can compromise user privacy. Also, a malicious application can inject forged or otherwise malicious messages, which can lead to breaches of user data and violate application security policies.We examine Android application interaction and identify security risks in application components. We provide a tool, ComDroid, that detects application communication vulnerabilities. ComDroid can be used by developers to analyze their own applications before release, by application reviewers to analyze applications in the Android Market, and by end users. We analyzed 20 applications with the help of ComDroid and found 34 exploitable vulnerabilities; 12 of the 20 applications have at least one vulnerability.
TL;DR: Systematize or characterize existing Android malware from various aspects, including their installation methods, activation mechanisms as well as the nature of carried malicious payloads reveal that they are evolving rapidly to circumvent the detection from existing mobile anti-virus software.
TL;DR: Stowaway, a tool that detects overprivilege in compiled Android applications, is built and finds that about one-third of applications are overprivileged.
TL;DR: A permissionbased behavioral footprinting scheme to detect new samples of known Android malware families and a heuristics-based filtering scheme to identify certain inherent behaviors of unknown malicious families are proposed.
TL;DR: An analysis of the permission system of the Android smartphone OS is performed and it is found that a trade-off exists between enabling least-privilege security with fine-grained permissions and maintaining stability of the permissions specification as the Android OS evolves.
TL;DR: An automated system called RiskRanker is developed to scalably analyze whether a particular app exhibits dangerous behavior and is used to produce a prioritized list of reduced apps that merit further investigation, demonstrating the efficacy and scalability of riskRanker to police Android markets of all stripes.
TL;DR: The attack surface metric is used to measure the attack surfaces of two open source FTP daemons: ProFTPD 1.2.10 and Wu-FTPD 2.6.2 and it is demonstrated how software consumers can use the attack surface metrics in making a choice between the two FTPDaemons.
Q1. What contributions have the authors mentioned in the paper "Analyzing inter-application communication in android" ?
In addition to an open API, the Android operating system also provides a rich inter-application message passing system. The authors examine Android application interaction and identify security risks in application components. The authors provide a tool, ComDroid, that detects application communication vulnerabilities. The authors analyzed 20 applications with the help of ComDroid and found 34 exploitable vulnerabilities ; 12 of the 20 applications have at least one vulnerability.
Q2. What type of analysis does ComDroid perform?
ComDroid specifically performs flowsensitive, intraprocedural static analysis, augmented with limited interprocedural analysis that follows method invocations to a depth of one method call.
Q3. What is the way to limit a component’s exposure to a set of trusted?
Requiring Signature or SignatureOrSystem permissions is an effective way of limiting a component’s exposure to a set of trusted applications.
Q4. Why do the authors treat Activities and their aliases as separate components?
The authors treat Activities and their aliases as separate components for the purpose of their analysis because an alias’s fields can increase the exposure surface of the component.
Q5. How can a receiver be dynamically created and registered?
Receivers can also be dynamically created and registered by calling registerReceiver(BroadcastReceiver receiver, IntentFilter filter).
Q6. What is the role of the Broadcast Intent in application exposure?
Their results indicate that Broadcast- and Activity- related Intents (both sending to and receiving from) play a large role in application exposure.
Q7. How does Android determine which Intents should be delivered to an exported component?
Android determines which Intents should be delivered to an exported component by matching each Intent’s fields to the component’s declaration.
Q8. What is the reason why iOS developers are unlikely to accidentally expose functionality?
iOS developers are unlikely to accidentally expose functionality because schemes are only used for public interfaces; different types of messages are used for internal communication.
Q9. What are the common bugs that are not also vulnerabilities?
Of the 181 warnings, the authors discovered 20 definite vulnerabilities, 14 spoofing vulnerabilities, and 16 common, unintentional bugs (that are not also vulnerabilities).
Q10. What is the way to make a component more secure?
To make components more secure, developers should avoid exporting components unless the component is specifically designed to handle requests from other applications.
Q11. How does a developer send an explicit Intent?
A developer sends an explicit Intent by specifying a recipient component name; the Intent is then delivered to the component with that name.