This document describes a study that analyzes the permission models of eight popular Android smartphones. The researchers developed a tool called Woodpecker to systematically detect "capability leaks", where an app can access privileged permissions without explicitly requesting them. Woodpecker analyzes pre-loaded apps to identify explicit leaks through public interfaces and implicit leaks through shared user IDs. The results showed 11 of 13 privileged permissions were leaked across the phones, allowing unrequested access to user data and device functions.
Mediating Applications on the Android SystemNizar Maan
This document discusses mediating applications on the Android system to improve user privacy and security. It explores flaws in existing "AppLocker" access control applications and proposes modifying the Android operating system and improving existing solutions. The document provides background on the Android architecture, including its software stack, security model using permissions, and inter-process communication methods like Binder and Intents. It aims to present an alternative solution to better protect users' sensitive data from unauthorized access by applications.
To protect sensitive resources from unauthorized use, modern mobile systems, such a Android and iOS,
design a permission-based access control model. However, current model could not enforce fine-grained control
over the dynamic permission use contexts, causing two severe security problems. First, any code package in an
application could use the granted permissions, inducing attackers to embed malicious payloads into benign apps.
Second, the permissions granted to a benign application may be utilized by an attacker through vulnerable
application interactions. Although ad hoc solutions have been proposed, none could systematically solve these
two issues within a unified framework. The first such framework to provide context-sensitive permission
enforcement that regular’s permission use policies according to system-wide application contexts, which cover
both intra-application context and inter-application context. We build a prototype system on Android , named
FineDroid, to track such context during the applicaton execution. To flexibly regulate the context-sensitive
permission rules, FineDroid features a policy framework that could express generic application contexts. We
demonstrate the benefits of FineDroid by instantiating several security extensions based on the policy
framework, for three potential users: end users, administrators and developers. Furthermore, FineDroid is
showed to introduce a minor overhead
Android open-source operating System for mobile devicesIOSR Journals
This document provides an overview of the Android operating system and its security features. It discusses Android's architecture, including its use of the Linux kernel and Dalvik virtual machine. Key security aspects are summarized, such as the permission model and limitations of running apps within a sandbox. The document also introduces an exploit execution framework that can test Android devices for vulnerabilities. It concludes by discussing how malware may propagate on Android devices and potential future threats.
Review on mobile threats and detection techniquesijdpsjournal
Since last-decade, smart-phones have gained widespread usage. Mobile devices store personal details
such as contacts and text messages. Due to this extensive growth, smart-phones are attracted towards
cyber-criminals. In this research work, we have done a systematic review of the terms related to malware
detection algorithms and have also summarized behavioral description of some known mobile malwares
in tabular form. After careful solicitation of all the possible methods and algorithms for detection of
mobile-based malwares, we give some recommendations for designing future malware detection algorithm
by considering computational complexity and detection ration of mobile malwares.
SYSTEM CALL DEPENDENCE GRAPH BASED BEHAVIOR DECOMPOSITION OF ANDROID APPLICAT...IJNSA Journal
This document discusses a proposed approach to map system-level behaviors of Android applications to Android APIs. The approach involves three steps: 1) obtaining an application's behavior through system-level tracking and symbolic execution, represented as System Call Dependence Graphs, 2) concurrently obtaining all Android APIs called by the application, and 3) mapping the System Call Dependence Graphs to the Android APIs based on system call entries and timestamps. This mapping could help identify potentially malicious applications trying to evade detection by avoiding direct use of Android APIs. The study shows this approach can effectively identify potential permission abuse with negligible performance impact.
The document provides an overview of security testing techniques for mobile applications on various platforms including Android, BlackBerry, and iOS. It discusses topics such as application threat models, traffic analysis and manipulation, insecure data storage, reverse engineering application binaries, analyzing application components and runtime behavior. The goal is to identify vulnerabilities that could impact the confidentiality, integrity or availability of the mobile application or user data.
The document contains summaries of several security news articles. The articles discuss issues like vulnerabilities in iPhone fingerprint authentication and signed Mac malware, flaws in Verizon femtocells allowing eavesdropping, a remote access tool targeting Android devices, and vulnerabilities in a Ukrainian bank's mobile app allowing account theft. The document also mentions several upcoming security events in India.
Mediating Applications on the Android SystemNizar Maan
This document discusses mediating applications on the Android system to improve user privacy and security. It explores flaws in existing "AppLocker" access control applications and proposes modifying the Android operating system and improving existing solutions. The document provides background on the Android architecture, including its software stack, security model using permissions, and inter-process communication methods like Binder and Intents. It aims to present an alternative solution to better protect users' sensitive data from unauthorized access by applications.
To protect sensitive resources from unauthorized use, modern mobile systems, such a Android and iOS,
design a permission-based access control model. However, current model could not enforce fine-grained control
over the dynamic permission use contexts, causing two severe security problems. First, any code package in an
application could use the granted permissions, inducing attackers to embed malicious payloads into benign apps.
Second, the permissions granted to a benign application may be utilized by an attacker through vulnerable
application interactions. Although ad hoc solutions have been proposed, none could systematically solve these
two issues within a unified framework. The first such framework to provide context-sensitive permission
enforcement that regular’s permission use policies according to system-wide application contexts, which cover
both intra-application context and inter-application context. We build a prototype system on Android , named
FineDroid, to track such context during the applicaton execution. To flexibly regulate the context-sensitive
permission rules, FineDroid features a policy framework that could express generic application contexts. We
demonstrate the benefits of FineDroid by instantiating several security extensions based on the policy
framework, for three potential users: end users, administrators and developers. Furthermore, FineDroid is
showed to introduce a minor overhead
Android open-source operating System for mobile devicesIOSR Journals
This document provides an overview of the Android operating system and its security features. It discusses Android's architecture, including its use of the Linux kernel and Dalvik virtual machine. Key security aspects are summarized, such as the permission model and limitations of running apps within a sandbox. The document also introduces an exploit execution framework that can test Android devices for vulnerabilities. It concludes by discussing how malware may propagate on Android devices and potential future threats.
Review on mobile threats and detection techniquesijdpsjournal
Since last-decade, smart-phones have gained widespread usage. Mobile devices store personal details
such as contacts and text messages. Due to this extensive growth, smart-phones are attracted towards
cyber-criminals. In this research work, we have done a systematic review of the terms related to malware
detection algorithms and have also summarized behavioral description of some known mobile malwares
in tabular form. After careful solicitation of all the possible methods and algorithms for detection of
mobile-based malwares, we give some recommendations for designing future malware detection algorithm
by considering computational complexity and detection ration of mobile malwares.
SYSTEM CALL DEPENDENCE GRAPH BASED BEHAVIOR DECOMPOSITION OF ANDROID APPLICAT...IJNSA Journal
This document discusses a proposed approach to map system-level behaviors of Android applications to Android APIs. The approach involves three steps: 1) obtaining an application's behavior through system-level tracking and symbolic execution, represented as System Call Dependence Graphs, 2) concurrently obtaining all Android APIs called by the application, and 3) mapping the System Call Dependence Graphs to the Android APIs based on system call entries and timestamps. This mapping could help identify potentially malicious applications trying to evade detection by avoiding direct use of Android APIs. The study shows this approach can effectively identify potential permission abuse with negligible performance impact.
The document provides an overview of security testing techniques for mobile applications on various platforms including Android, BlackBerry, and iOS. It discusses topics such as application threat models, traffic analysis and manipulation, insecure data storage, reverse engineering application binaries, analyzing application components and runtime behavior. The goal is to identify vulnerabilities that could impact the confidentiality, integrity or availability of the mobile application or user data.
The document contains summaries of several security news articles. The articles discuss issues like vulnerabilities in iPhone fingerprint authentication and signed Mac malware, flaws in Verizon femtocells allowing eavesdropping, a remote access tool targeting Android devices, and vulnerabilities in a Ukrainian bank's mobile app allowing account theft. The document also mentions several upcoming security events in India.
The dependence of users on smartphones to accomplish their daily works is growing increasingly. Every day many mobile applications are downloaded and installed by the users to perform different desirable tasks for them. Before it can be installed in the smartphone, the mobile application requests from the user granting some sort of permissions, which may include the access right to users’ sensitive resources. In absence of a security mechanism that can enforce fine-grained permission control, the application may abuse the granted permissions and thus violates the security of sensitive resources. This paper proposes an attribute-based permission model ABP for Android smartphones to control how the mobile application can exercise the granted permissions. The finer granularity of the permission language used by ABP model ensures that the mobile application cannot violate the user’s security. By using ABP model, the users can enjoy the useful tasks the mobile applications provide while protecting sensitive resources from unauthorized use.
Detection of Android Third Party Libraries based attacksAmina WADDIZ
This document discusses the detection of attacks based on third-party libraries (3PLs) in Android applications. It begins with an introduction to the increasing popularity and sophistication of smartphones, and the corresponding rise in Android malware. It then provides background on Android architecture and security models. The document aims to analyze and classify existing 3PLs, report novel malware techniques using 3PLs, and propose countermeasures. It surveys popular 3PLs and their usage, and characterizes potential attacks originating from 3PLs, discussing how they threaten user privacy, the Android OS, and device utilities.
This document discusses the evolution of hidden mobile threats and why organizations need multi-level security solutions. It outlines six common mobile threats: vulnerable legitimate apps, jailbreaking, outdated operating systems, malware/malicious apps, compromised Wi-Fi hotspots, and phishing. The document recommends a predictive, multi-level approach to mobile security to address threats, protect corporate data on devices, and educate users on risks.
Mobile application security testing is important to identify vulnerabilities and protect sensitive user data. The key concepts of mobile app security testing include authentication, authorization, availability, confidentiality, integrity and non-repudiation. Common mobile security threats include malware, spyware, privacy threats and vulnerable applications. Effective security testing employs strategies like strong authentication, encryption, access control and session management. The testing methodology involves profiling the app, analyzing threats, planning tests, executing tests, and providing daily status reports. Deliverables include management reports, technical vulnerability reports, and best practices documents.
ABSTRACT
Shoreline monitoring is important to overcome the problems in the measurement of the shoreline. Recently,
many researchers have directed attention to methods of predicting shoreline changes by the use of
multispectral images. However, the images being captured tend to have several problems due to the weather.
Therefore, identification of multi class features which includes vegetation and shoreline using multispectral
satellite image is one of the challenges encountered in the detection of shoreline. An efficient framework
using the near infrared–histogram equalisation and improved filtering method is proposed to enhance the
detection of the shoreline in Tanjung Piai, Malaysia, by using SPOT-5 images. Sub-pixel edge detection and
the Wallis filter are used to compute the edge location with the subpixel accuracy and reduce the noise. Then,
the image undergoes image classification process by using Support Vector Machine. The proposed method
performed more effectively and reliable in preserving the missing line of the shoreline edge in the SPOT-5
images.
Penetration Testing for Android SmartphonesIOSR Journals
This document discusses penetration testing of three versions of the Android operating system (2.3, 3.2, and 4.2) using an application program and Kali Linux tools. Port scanning and exploits were used to test the security of each version. The results showed that while all versions had improved security over time, version 4.2 was the most secure with the fewest vulnerabilities found during testing. The document concludes that users should take steps to secure their Android devices like using passwords, reviewing permissions, and using antivirus software.
Mobile apps have become integral to work and personal life, but securing them is challenging due to device and OS fragmentation, lack of standardized security tools, and shortage of experienced professionals. A comprehensive three-pronged strategy is needed to secure wireless connections, protect against threats across OS versions, and safeguard data and devices through encryption and remote access features. Outsourcing to an expert partner can help enterprises overcome these security challenges and accelerate app development.
A Framework for Providing Selective Permissions to Android ApplicationsIOSR Journals
This document proposes a framework for providing selective permissions in the Android operating system. It begins with an introduction to the Android application model and permissions system. It then describes related work on more fine-grained permission systems. The proposed framework would collect the permissions an app requests at installation, map them to runtime permission requests, and notify the user if extra permissions are requested. It provides class and mathematical models of the framework's components and functions. The framework aims to detect potentially malicious apps requesting unexpected permissions and delay their access to resources until the user is notified and approves.
The document discusses ACCESS's Security Policy Framework (SPF) for mobile devices. The SPF allows for flexible sandboxing, where different applications can be granted different privilege levels based on who developed and signed the application. This provides flexibility so network operators and manufacturers can customize the security policy to their needs, granting trusted applications more access while restricting untrusted ones. The SPF defines multiple privilege levels and allows multiple stakeholders like manufacturers, operators, and developers to each define a security policy domain for applications.
Taxonomy mobile malware threats and detection techniquescsandit
Since last-decade, smart-phones have gained widespr
ead usage. Mobile devices store personal
details such as contacts and text messages. Due to
this extensive growth, smart-phones are
attracted towards cyber-criminals. In this research
work, we have done a systematic review of
the terms related to malware detection algorithms
and have also summarized behavioral
description of some known mobile malwares in tabula
r form. After careful solicitation of all the
possible methods and algorithms for detection of m
obile-based malwares, we give some
recommendations for designing future malware detect
ion algorithm by considering
computational complexity and detection ration of m
obile malwares.
This document provides an overview of mobile device management (MDM) and mobile security across different mobile operating systems. It analyzes the native security features and permissions models of BlackBerry and iOS, identifying both controlled and uncontrolled activities. For both platforms, it shows the number of main and derived activities, and calculates the efficiency of each platform's permissions and controls. The analysis finds that the set of permitted activities is typically less than the set of all activities, indicating opportunities for improvement in granularity and unknown attacks.
The document provides an overview of securing Android applications according to the OWASP (Open Web Application Security Project) approach. It discusses the OWASP Mobile Security Project, performs a crash course on Android architecture and essentials, demonstrates threat modeling for Android apps, reviews the top 10 mobile risks and associated controls from OWASP, and provides resources for further information.
Botnets are evolving in their usage and tactics. Botnet controllers build large profiles on infected users and sell the data. Advanced persistent adversaries query botnet operators to identify already compromised machines belonging to their target organizations. Bad actors borrow techniques from black hat SEO to evade defenses like reputation systems. Research finds targeted attacks may have roots in common botnets, with adversaries paying top dollar for information from botnet operators.
The document discusses various threats facing iOS and Android mobile devices and point-of-sale systems. It describes attacks such as jailbreaking iOS devices to install surveillance apps, using stolen certificates to sideload malicious apps, exploiting Android vulnerabilities, and using WiFi man-in-the-middle attacks. It promotes BETTER Mobile Security's solution which continuously monitors devices for unauthorized activity and configuration changes to detect and prevent these advanced threats in real-time.
Thorsignia - Custom software development services in indiacharan Teja
Thorsignia is a leading IT and Multimedia company that provides an integrated range of services. We render finest quality outputs to our clients through our domain expertise.
The document summarizes a collection of poems by D vinod kumar. It includes poems about nature, childhood memories, and staying hopeful. The author has written over 200 poems that have been published in magazines and on their blog and Facebook page. Some of the most famous poems mentioned are "The Appointment," "Walking Along the Path," and "The Teddy Bear."
ARstudio - How do your learners want to engage?Dan Munnerley
This document describes the AR Studio, which creates opportunities for multimodal layered learning through augmented reality. The AR Studio has developed mobile apps for augmented reality and supports a distributed studio model located at the University of Canberra. Through workshops, industry partnerships, and clustered research projects, the AR Studio explores using augmented reality and new technologies in educational practice and higher education.
The dependence of users on smartphones to accomplish their daily works is growing increasingly. Every day many mobile applications are downloaded and installed by the users to perform different desirable tasks for them. Before it can be installed in the smartphone, the mobile application requests from the user granting some sort of permissions, which may include the access right to users’ sensitive resources. In absence of a security mechanism that can enforce fine-grained permission control, the application may abuse the granted permissions and thus violates the security of sensitive resources. This paper proposes an attribute-based permission model ABP for Android smartphones to control how the mobile application can exercise the granted permissions. The finer granularity of the permission language used by ABP model ensures that the mobile application cannot violate the user’s security. By using ABP model, the users can enjoy the useful tasks the mobile applications provide while protecting sensitive resources from unauthorized use.
Detection of Android Third Party Libraries based attacksAmina WADDIZ
This document discusses the detection of attacks based on third-party libraries (3PLs) in Android applications. It begins with an introduction to the increasing popularity and sophistication of smartphones, and the corresponding rise in Android malware. It then provides background on Android architecture and security models. The document aims to analyze and classify existing 3PLs, report novel malware techniques using 3PLs, and propose countermeasures. It surveys popular 3PLs and their usage, and characterizes potential attacks originating from 3PLs, discussing how they threaten user privacy, the Android OS, and device utilities.
This document discusses the evolution of hidden mobile threats and why organizations need multi-level security solutions. It outlines six common mobile threats: vulnerable legitimate apps, jailbreaking, outdated operating systems, malware/malicious apps, compromised Wi-Fi hotspots, and phishing. The document recommends a predictive, multi-level approach to mobile security to address threats, protect corporate data on devices, and educate users on risks.
Mobile application security testing is important to identify vulnerabilities and protect sensitive user data. The key concepts of mobile app security testing include authentication, authorization, availability, confidentiality, integrity and non-repudiation. Common mobile security threats include malware, spyware, privacy threats and vulnerable applications. Effective security testing employs strategies like strong authentication, encryption, access control and session management. The testing methodology involves profiling the app, analyzing threats, planning tests, executing tests, and providing daily status reports. Deliverables include management reports, technical vulnerability reports, and best practices documents.
ABSTRACT
Shoreline monitoring is important to overcome the problems in the measurement of the shoreline. Recently,
many researchers have directed attention to methods of predicting shoreline changes by the use of
multispectral images. However, the images being captured tend to have several problems due to the weather.
Therefore, identification of multi class features which includes vegetation and shoreline using multispectral
satellite image is one of the challenges encountered in the detection of shoreline. An efficient framework
using the near infrared–histogram equalisation and improved filtering method is proposed to enhance the
detection of the shoreline in Tanjung Piai, Malaysia, by using SPOT-5 images. Sub-pixel edge detection and
the Wallis filter are used to compute the edge location with the subpixel accuracy and reduce the noise. Then,
the image undergoes image classification process by using Support Vector Machine. The proposed method
performed more effectively and reliable in preserving the missing line of the shoreline edge in the SPOT-5
images.
Penetration Testing for Android SmartphonesIOSR Journals
This document discusses penetration testing of three versions of the Android operating system (2.3, 3.2, and 4.2) using an application program and Kali Linux tools. Port scanning and exploits were used to test the security of each version. The results showed that while all versions had improved security over time, version 4.2 was the most secure with the fewest vulnerabilities found during testing. The document concludes that users should take steps to secure their Android devices like using passwords, reviewing permissions, and using antivirus software.
Mobile apps have become integral to work and personal life, but securing them is challenging due to device and OS fragmentation, lack of standardized security tools, and shortage of experienced professionals. A comprehensive three-pronged strategy is needed to secure wireless connections, protect against threats across OS versions, and safeguard data and devices through encryption and remote access features. Outsourcing to an expert partner can help enterprises overcome these security challenges and accelerate app development.
A Framework for Providing Selective Permissions to Android ApplicationsIOSR Journals
This document proposes a framework for providing selective permissions in the Android operating system. It begins with an introduction to the Android application model and permissions system. It then describes related work on more fine-grained permission systems. The proposed framework would collect the permissions an app requests at installation, map them to runtime permission requests, and notify the user if extra permissions are requested. It provides class and mathematical models of the framework's components and functions. The framework aims to detect potentially malicious apps requesting unexpected permissions and delay their access to resources until the user is notified and approves.
The document discusses ACCESS's Security Policy Framework (SPF) for mobile devices. The SPF allows for flexible sandboxing, where different applications can be granted different privilege levels based on who developed and signed the application. This provides flexibility so network operators and manufacturers can customize the security policy to their needs, granting trusted applications more access while restricting untrusted ones. The SPF defines multiple privilege levels and allows multiple stakeholders like manufacturers, operators, and developers to each define a security policy domain for applications.
Taxonomy mobile malware threats and detection techniquescsandit
Since last-decade, smart-phones have gained widespr
ead usage. Mobile devices store personal
details such as contacts and text messages. Due to
this extensive growth, smart-phones are
attracted towards cyber-criminals. In this research
work, we have done a systematic review of
the terms related to malware detection algorithms
and have also summarized behavioral
description of some known mobile malwares in tabula
r form. After careful solicitation of all the
possible methods and algorithms for detection of m
obile-based malwares, we give some
recommendations for designing future malware detect
ion algorithm by considering
computational complexity and detection ration of m
obile malwares.
This document provides an overview of mobile device management (MDM) and mobile security across different mobile operating systems. It analyzes the native security features and permissions models of BlackBerry and iOS, identifying both controlled and uncontrolled activities. For both platforms, it shows the number of main and derived activities, and calculates the efficiency of each platform's permissions and controls. The analysis finds that the set of permitted activities is typically less than the set of all activities, indicating opportunities for improvement in granularity and unknown attacks.
The document provides an overview of securing Android applications according to the OWASP (Open Web Application Security Project) approach. It discusses the OWASP Mobile Security Project, performs a crash course on Android architecture and essentials, demonstrates threat modeling for Android apps, reviews the top 10 mobile risks and associated controls from OWASP, and provides resources for further information.
Botnets are evolving in their usage and tactics. Botnet controllers build large profiles on infected users and sell the data. Advanced persistent adversaries query botnet operators to identify already compromised machines belonging to their target organizations. Bad actors borrow techniques from black hat SEO to evade defenses like reputation systems. Research finds targeted attacks may have roots in common botnets, with adversaries paying top dollar for information from botnet operators.
The document discusses various threats facing iOS and Android mobile devices and point-of-sale systems. It describes attacks such as jailbreaking iOS devices to install surveillance apps, using stolen certificates to sideload malicious apps, exploiting Android vulnerabilities, and using WiFi man-in-the-middle attacks. It promotes BETTER Mobile Security's solution which continuously monitors devices for unauthorized activity and configuration changes to detect and prevent these advanced threats in real-time.
Thorsignia - Custom software development services in indiacharan Teja
Thorsignia is a leading IT and Multimedia company that provides an integrated range of services. We render finest quality outputs to our clients through our domain expertise.
The document summarizes a collection of poems by D vinod kumar. It includes poems about nature, childhood memories, and staying hopeful. The author has written over 200 poems that have been published in magazines and on their blog and Facebook page. Some of the most famous poems mentioned are "The Appointment," "Walking Along the Path," and "The Teddy Bear."
ARstudio - How do your learners want to engage?Dan Munnerley
This document describes the AR Studio, which creates opportunities for multimodal layered learning through augmented reality. The AR Studio has developed mobile apps for augmented reality and supports a distributed studio model located at the University of Canberra. Through workshops, industry partnerships, and clustered research projects, the AR Studio explores using augmented reality and new technologies in educational practice and higher education.
1) O documento discute o conceito e operação de self storage (armazenamento self-service) nos EUA e em outros países. 2) Self storage oferece armazenamento seguro de curto prazo para pessoas e empresas. 3) A indústria cresceu significativamente nos EUA, com taxas de ocupação acima de 80%, e agora está começando a se desenvolver no Brasil.
The document provides step-by-step instructions for activating a LAUSD student email account managed by Google. It instructs the student to open Safari on their iPad, go to a specific URL to activate their account, enter their name, user ID, and email address, write down their password in multiple places, and then access their email through the Gmail app. Once completed, the student will have set up their LAUSD student email account.
Richiesta intervento ispettorato del lavoro vs phonemediaGiovanna Mercurio
Dopo l'incontro del 30 Marzo presso la sede Provinciale dell'Inps in cui è stata indicata la strada da percorrere per cercare di ottenere il riconoscimento dei contributi mancanti,continua l'azione della Fistel finalizzata a questo obiettivo,e qui di seguito vi riporto il testo della richiesta inoltrata,con cui si sollecita l'intervento dell'Ispettorato del lavoro per quanto riguarda l'attività di sua competenza,ossia l'attività di accertamento presso l'azienda (leggi curatore).Ringrazio barby per averla condivisa con me in modo che potessi a mia volta condividerla con voi e attendo gli aggiornamenti sulla vicenda..Buona serata a tutti
Android mobile operating system, Google developed, Linux Kernel based with basic motive to serve for
devices with touchscreen like tablets and smartphones. Due
to weak OS security it is vulnerable to various security attacks therefor to restrict access of third-party applications
off critical resources the security has been built upon a permission based mechanism. Permissions are declarations by
developers and user is demanded to accept. This paper
highlights Share User ID permission misuse following two factor authentication failure etc
When developer's api simplify user mode rootkits developing.Yury Chemerkin
This is a series of articles about shell extensions that enhance high-level features of any operation system. However, such possibilities not only enrich platform but simplify developing trojans, exploits that leads to the new security holes. Mostly this kind of extensions are known as usermode rootkits.
http://hakin9.org/theultimat/
This document proposes and evaluates a context-based access control (CBAC) mechanism for Android systems. The CBAC mechanism allows users to set configuration policies over applications' usage of device resources and services based on the user's context. The proposed system uses context sensing and machine learning to classify contexts and then dynamically grants or revokes application privileges. Experiments show the CBAC mechanism incurs negligible energy overhead compared to the stock Android system. The CBAC framework provides improved privacy and security over existing location-based policy systems.
Android Malware: Study and analysis of malware for privacy leak in ad-hoc net...IOSR Journals
This document discusses analyzing Android malware that can leak privacy information in ad-hoc networks. It proposes using static and dynamic analysis methods to detect malware. In static analysis, reverse engineering is used to detect malicious code by decompiling Android app install files. In dynamic analysis, apps are run in an emulator to monitor their network behavior using tools like Snort. Destinations are then white-listed or blacklisted based on safety. The approach is compared to third party apps and is shown to also be effective at detecting malware that uses internet permissions to leak privacy data in small datasets.
The document discusses malware detection and prevention techniques for smart devices. It begins with an introduction to the growing threat of malware targeting smart devices, especially Android devices. It then provides an overview of security models for various mobile operating systems. The document also covers malware analysis techniques, including static analysis of code and dynamic analysis of behaviors. It discusses signature-based and anomaly-based malware detection methods. Finally, it proposes combining static and dynamic analysis techniques into a hybrid analysis approach to improve malware detection.
This document proposes Earp, a new mobile platform that uses the relational model as the unified OS-level abstraction for app data storage and inter-app data sharing. Earp provides apps with structure-aware, OS-enforced access control to address the inadequate protection of user data in existing mobile platforms. The key contributions of Earp include using the relational model to specify access rights as part of the data model, a uniform data access abstraction enforced by a reference monitor with visibility into app data structures, and a prototype implementation on Firefox OS that adds these protections while maintaining support for legacy APIs.
Pileup Flaws: Vulnerabilities in Android Update Make All Android Devices Vuln...MOBIQUANT TECHNOLOGIES
The document discusses vulnerabilities in Android's package management service (PMS) that can allow privilege escalation through OS updates, called "Pileup flaws". Researchers analyzed PMS source code and found flaws that allow malicious apps on older Android versions to claim privileges intended for newer versions, automatically acquiring those privileges after an update. This could allow access to private data, ability to control permissions, and substitution of system apps. The researchers developed the SecUP app to detect apps exploiting these vulnerabilities prior to users updating their devices.
Mitigating Privilege-Escalation Attacks on Android ReportVinoth Kanna
This document summarizes previous work on mitigating privilege-escalation attacks on Android. It discusses how Android's open framework allows applications to potentially gain unauthorized access to data. It reviews common privilege-escalation attacks like confused deputy attacks and inter-app collusion. The document also summarizes existing security extensions that aim to prevent these attacks, but notes limitations in addressing confused deputy and collusion attacks specifically. It proposes extending reference monitoring at the kernel level in addition to the middleware to better prevent these types of attacks.
COVERT is a tool that analyzes Android applications in a compositional manner to detect security vulnerabilities that occur due to the interaction of apps. It extracts models of individual apps and the Android framework and uses the Alloy analyzer to check the models for vulnerabilities. An evaluation on over 500 real-world apps found that COVERT can effectively detect inter-app vulnerabilities in minutes and does not require source code. It was implemented with desktop, mobile, and web-based front-ends to facilitate end-user analysis of apps.
ANDROID UNTRUSTED DETECTION WITH PERMISSION BASED SCORING ANALYSISijitcs
Android smart phone is one of the fast growing mobile phones and because of these it the one of the most preferred target of malware developer. Malware apps can penetrate the device and gain privileges in which it can perform malicious activities such reading user contact, misusing of private information such as sending SMS and can harm user by exploiting the users private data which is stored in the device. The study is about implementation of detecting untrusted on android applications, which would be the basis of all future development regarding malware detection.
The smartphone users worldwide are not aware of the permissions as the basis of all malicious activities that could possibly operate in an android system and may steal personal and private information. Android operating system is an open system in which users are allowed to install application from any unsafe sites. However permission mechanism of and android system is not enough to guarantee the invulnerability of the application that can harm the user. In this paper, the permission scoring-based analysis that will scrutinized the installed permission and allows user to increase the efficiency of Android permission to inform user about the risk of the installed Android application, in this paper, the framework that would classify the level of sensitivity of the permission access by the application. The framework uses a formula that will calculate the sensitivity level of the permission and determine if the installed application is untrusted or not. Our result show that, in a collection of 26 untrusted application, the framework is able to correct and determine the application's behavior consistently and efficiently.
This document discusses a tool called ALTERDROID that analyzes Android applications to detect malware. ALTERDROID uses static and dynamic analysis techniques to detect obfuscated malware hidden in applications. It analyzes applications that are installed on a device to identify any malicious components. If malware is found, it asks the user for permission to uninstall the application. For unauthorized users attempting to access the device, it captures their image and sends it by email. The document compares this approach to existing static-only malware analysis techniques, which can miss hidden malicious components.
This document discusses the importance of mobile application security and penetration testing. It describes penetration testing as discovering vulnerabilities before attackers through vulnerability detection, comprehensive penetration attempts, and analysis/reporting. The document outlines static and dynamic analysis methods used for Android application security assessments. These include code review, function hooking, runtime debugging, and analyzing data at rest and in transit. It promotes understanding how applications work through reverse engineering, decompilation, and deobfuscation. The methodology uses tools like MARA, MobSF, Xposed, Frida, and BurpSuite.
The document discusses architectural issues for pervasive computing applications. It proposes an application model where applications are composed of modular components that can interact through a middleware infrastructure. The key aspects of the model are:
1) Applications are distributed across devices, device proxies, user proxies, and network services. This allows applications to span multiple devices and users.
2) Components communicate by exchanging messages through capabilities-based security that limits what components can access. This protects applications and the system from misbehaving components.
3) The model is flexible enough to allow customizing applications through adding, removing, or modifying components after deployment.
ABSTRACT
Smartphones are used by billions of people that means the applications of the smartphone is increasing, it is out of control for applications marketplaces to completely validate if an application is malicious or legitimate. Therefore, it is up to users to choose for themselves whether an application is safe to use or not. It is important to say that there are differences between mobile devices and PC machines in resource management mechanism, the security solutions for computer malware are not compatible with mobile devices. Consequently, the anti-malware organizations and academic researchers have produced and proposed many security methods and mechanisms in order to recognize and classify the security threat of the Android operating system. By means of the proposed methods are different from one to another, they can be arranged into various classifications. In this review paper, the present Android security threats is discussed and present security proposed solutions and attempt to classify the proposed solutions and evaluate them.
Permission based malware detection by using k means algorithm in Android OSBRNSSPublicationHubI
The document discusses a permission-based method for detecting malware in Android apps using k-means clustering. It extracts permission data from app manifest files, compares it to a database of malicious permissions, and uses k-means to classify apps as benign or malicious based on their permission ratios. The method was able to accurately detect malware in popular apps like WhatsApp and Facebook by identifying suspicious high levels of permissions for activities like SMS/call access.
This document provides an overview of mobile application security testing. It discusses the mobile security stack including the infrastructure, hardware, operating system and application layers. It then covers topics like mobile threat modeling, mobile application auditing techniques including dynamic and static analysis. The document also discusses the OWASP top 10 mobile risks and provides case studies and demonstrations on pentesting real mobile applications and reverse engineering Android malware.
This document provides an overview of mobile application security testing. It discusses the mobile security stack including the infrastructure, hardware, operating system and application layers. It then covers topics like mobile threat modeling, mobile application auditing techniques including dynamic and static analysis. The document also discusses the OWASP top 10 mobile risks and provides case studies and demonstrations on pentesting real mobile applications and reverse engineering Android malware.
This document discusses how modern Android features like password managers and Instant Apps can enable new phishing attacks:
- Password managers are now available on mobile devices and can suggest credentials for apps, but they rely on app package names which can be spoofed. The researchers found password managers that will suggest credentials for attacker-controlled apps.
- Instant Apps allow running app code directly from a URL without installing the full app. The researchers show how an attacker could use this to gain full UI control of a device and phish credentials by abusing password managers.
- The researchers propose a new secure API for password managers to avoid these issues, and note that securely implementing autofill will require community-wide efforts.
This document provides an overview of Android security. It discusses Android's architecture including activities, services, content providers and broadcast receivers. It then covers Android security features like application sandboxing, application signing, and Android's permission model. It provides examples of how these components and security features work together in a sample Android application for tracking friends' locations. It also discusses how applications can programmatically enforce permissions and how application components interact through intents.
Comparative Study on Intrusion Detection Systems for Smartphonesiosrjce
IOSR Journal of Computer Engineering (IOSR-JCE) is a double blind peer reviewed International Journal that provides rapid publication (within a month) of articles in all areas of computer engineering and its applications. The journal welcomes publications of high quality papers on theoretical developments and practical applications in computer technology. Original research papers, state-of-the-art reviews, and high quality technical notes are invited for publications.
The document summarizes McAfee's Threats Report for the third quarter of 2013. Some key points:
- Mobile malware increased 33% while overall new malware exceeded 20 million. New ransomware and rootkits also rose.
- Digital currencies like Bitcoin are increasingly used by cybercriminals for money laundering and anonymous transactions on dark web markets. The shutdown of Silk Road prompted new illegal sites.
- The "Deep Web" contains unregulated online markets selling illegal drugs, weapons, credit cards, and even murder-for-hire services accessible through Tor and paid with Bitcoin.
- Hacktivism and political hacking increased, while spam volume reached its highest level since 2010. Browser
Rp data breach-investigations-report-2013-en_xgКомсс Файквэе
This document is the table of contents for the 2013 Data Breach Investigations Report, which analyzes data breaches from various organizations. The report includes sections on methodology, results and analysis, demographics of breached organizations, threat actors like external and internal parties, threat actions like hacking and malware, compromised assets and data, attack targeting and difficulty, breach timelines, and discovery methods.
The document summarizes phishing activity trends from the 2nd quarter of 2013 based on data reported to the Anti-Phishing Working Group (APWG). Some key findings include:
- The number of unique brands targeted by phishing attacks set a new record high in April of 441 brands.
- During Q2 2013, a total of 639 unique brands were targeted, topping the previous high of 614 brands in Q4 2012.
- Phishing hosted in Russia almost disappeared in June, replaced by phishing hosted in Kazakhstan, highlighting the mobility of criminal infrastructure across countries.
- The number of unique phishing reports submitted to APWG saw a steady decrease during the quarter, dropping
The document summarizes a mobile threat report for Q3 2013. It finds that 252 of the 259 new mobile threat families and variants discovered were for Android, with trojans making up the largest percentage at 88%. It also notes an increasing trend of profit-motivated mobile malware, with 81.1% of new threats aiming to generate money through unauthorized SMS messages. The report discusses recent developments like the identification of the creator of the Pincer Android banking trojan and the emergence of tools that simplify inserting malware into legitimate apps.
The document provides a specification for the Silent Circle Instant Messaging Protocol (SCIMP). SCIMP enables private conversations over instant messaging and draws from related protocols like ZRTP, OTR, and Cryptocat. It provides strong encryption, authentication, and perfect forward secrecy using algorithms approved by NIST like ECCDH, AES, and SHA. The protocol establishes an encrypted session in 3 messages using key continuity and optional voice verification to prevent man-in-the-middle attacks. It then encrypts messages with CCM authenticated encryption.
The document discusses improvements organizations have made to address cyber threats, but also areas that still need work. It finds that many organizations now recognize the extent of cyber threats, with 76% owning information security policies at the highest level. 70% conduct security assessments of third parties accessing their data. However, the document notes that while improvements have been made, organizations need to do more quickly to address increasing cyber risks. Leading practices and innovation are needed to better protect against known and unknown future threats.
The document discusses HTTP request hijacking attacks against native mobile apps. It describes how an attacker can intercept an app's HTTP requests and redirect them to a malicious server using 301 redirects, allowing the attacker to control the app's traffic. The presentation demonstrates this attack and discusses how it can be extended through techniques like malicious profiles and captive networks. It provides recommendations for developers to prevent request hijacking through secure communication and cache policies, and advises end users and organizations on security best practices.
B istr main-report_v18_2012_21291018.en-usКомсс Файквэе
The document summarizes key internet security trends from 2012, as analyzed by Symantec Corporation in their Internet Security Threat Report. Some of the top trends include:
1) Small businesses were increasingly targeted by attackers, with 50% of attacks aimed at businesses with less than 2,500 employees. Small businesses are seen as having weaker security defenses.
2) Malware authors sought to steal users' private information through spying on computers, mobile devices, and social networks, in order to profit through identity theft and banking fraud. Targeted attacks involved extensive profiling of victims.
3) The rise of mobile malware continued significantly, with a 58% increase in mobile malware families compared to 2011. However, mobile
The document provides an overview of cybersecurity threats in the first half of 2013. Key points include:
- Exploit attacks targeting known Java vulnerabilities accounted for about half of all detections, focusing on CVE-2013-1493 and CVE-2011-3544.
- The ZeroAccess botnet was active spreading via exploit kits and Java exploits, with potential monthly profits from Bitcoin mining estimated at over $50,000.
- Ransomware called "Anti Child Porn Spam Protection" circulated in March and April.
- APT attacks often use specially crafted documents as bait targeting people in specific organizations or fields.
- The first Android malware spread through spam emails was
In August 2013, Symantec reported the following key findings:
1. Social media scams involving fake discount offers dominated social attacks in 2013, comprising 82% of incidents. Fake plug-ins were the second most common attack at 8.2%.
2. There were 7 reported data breaches in August, with an additional 9 from earlier in the year, bringing the 2013 total to 125 breaches exposing 91 million identities. The top 3 exposed data types were real names, birth dates, and government IDs.
3. 213 new mobile malware variants were discovered in August, a modest increase from July. Cumulative Android malware reached 6,852 variants in 2013.
The document summarizes the results of a test of the effectiveness of various home anti-virus programs. It found that the most accurate programs, which blocked threats without falsely flagging legitimate software, were BitDefender Internet Security 2013, Kaspersky Internet Security 2013, and Norton Internet Security 2013. However, some free programs like Avast! Free Antivirus 8 were also effective. The tests exposed the programs to real internet threats to evaluate their ability to protect users from malware infections.
The document provides an overview of threats in the first quarter of 2012 according to McAfee Labs. It saw significant increases in many areas of malware and threats after declines in late 2011. Mobile malware targeting Android devices increased dramatically, reaching nearly 7,000 samples. Established rootkits like Koutodoor rebounded and the new ZeroAccess rootkit emerged. Signed malware and password-stealing Trojans also increased substantially. Spam volume grew early in the quarter but resumed its downward trend. The US continued to host the most malicious web content.
The document summarizes the results of a test of Kaspersky's Whitelisting Database conducted by AV-Test GmbH from November 2012 to January 2013. The test assessed the database's coverage, quality, speed, false positive rate, and default deny mode. It found that Kaspersky had very good coverage of over 91% for files previously known, and 50% coverage of new daily files at the time of testing. Response times for database queries and additions were generally fast. The database was found to provide useful qualification and metadata for known files while maintaining a low false positive rate in default deny mode.
This document summarizes the key findings from an analysis of over 26,000 malware samples collected over 3 months from over 1,000 enterprise networks. The analysis found that 90% of unknown malware was delivered via web browsing, with an average of 20 days to detection compared to 5 days for email-delivered malware. The document provides recommendations to address unknown malware such as bringing anti-malware technologies into networks, enabling real-time detection and blocking, and enforcing user and application controls on files transfers.
This document compares application control software from four vendors: Kaspersky Endpoint Security for Windows, McAfee Application Control, Sophos Endpoint Protection - Advanced, and Symantec Endpoint Protection. It evaluates their abilities to regularly control applications, audit installed software, protect against advanced persistent threats, and manage users. The testing found that Kaspersky provided the most fully-featured application control and was most effective against threats. While no product was perfect, default deny policies that whitelist approved applications were deemed the strongest approach to application control.
The PandaLabs annual report for 2012 summarizes key security events of the year. Mobile malware increased, targeting Android devices especially through third-party app stores. Ransomware like the "Police Virus" spread through social engineering. Cyber attacks targeted corporations and governments. Macs saw their largest infection to date, showing they are also vulnerable. Trends in social media threats and cyber espionage were analyzed. The report concludes with a forecast of security trends for 2013.
This document provides information about a graduate-level course on medical device security taught by Professor Kevin Fu at the University of Michigan. The key points are:
1. The course covers topics in computer engineering, human factors, and regulatory policy to teach students how to create more secure medical devices.
2. Students will complete a group project analyzing the security of a real-world medical device and apply the concepts learned in class.
3. Grades are based on the group project, individual homework, exams, and class participation. The group project makes up 40% of the final grade.
This document is the table of contents for the course "EECS 598-008: Medical Device Security" taught at the University of Michigan. It lists 17 readings on topics related to medical device and software security, safety, and regulation. The readings are from books and cover subjects like software design principles, identifying and preventing software defects, system dependability requirements, design of implantable cardiac devices, embedded debugging methods, system safety principles, managing safety culture, medication errors in healthcare, privacy and security economics, and FDA regulation of medical devices. The instructor is listed as Prof. Kevin Fu and additional reading material is noted to be available on the course website.
Taking AI to the Next Level in Manufacturing.pdfssuserfac0301
Read Taking AI to the Next Level in Manufacturing to gain insights on AI adoption in the manufacturing industry, such as:
1. How quickly AI is being implemented in manufacturing.
2. Which barriers stand in the way of AI adoption.
3. How data quality and governance form the backbone of AI.
4. Organizational processes and structures that may inhibit effective AI adoption.
6. Ideas and approaches to help build your organization's AI strategy.
Generating privacy-protected synthetic data using Secludy and MilvusZilliz
During this demo, the founders of Secludy will demonstrate how their system utilizes Milvus to store and manipulate embeddings for generating privacy-protected synthetic data. Their approach not only maintains the confidentiality of the original data but also enhances the utility and scalability of LLMs under privacy constraints. Attendees, including machine learning engineers, data scientists, and data managers, will witness first-hand how Secludy's integration with Milvus empowers organizations to harness the power of LLMs securely and efficiently.
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdfChart Kalyan
A Mix Chart displays historical data of numbers in a graphical or tabular form. The Kalyan Rajdhani Mix Chart specifically shows the results of a sequence of numbers over different periods.
leewayhertz.com-AI in predictive maintenance Use cases technologies benefits ...alexjohnson7307
Predictive maintenance is a proactive approach that anticipates equipment failures before they happen. At the forefront of this innovative strategy is Artificial Intelligence (AI), which brings unprecedented precision and efficiency. AI in predictive maintenance is transforming industries by reducing downtime, minimizing costs, and enhancing productivity.
Trusted Execution Environment for Decentralized Process MiningLucaBarbaro3
Presentation of the paper "Trusted Execution Environment for Decentralized Process Mining" given during the CAiSE 2024 Conference in Cyprus on June 7, 2024.
Digital Marketing Trends in 2024 | Guide for Staying AheadWask
https://www.wask.co/ebooks/digital-marketing-trends-in-2024
Feeling lost in the digital marketing whirlwind of 2024? Technology is changing, consumer habits are evolving, and staying ahead of the curve feels like a never-ending pursuit. This e-book is your compass. Dive into actionable insights to handle the complexities of modern marketing. From hyper-personalization to the power of user-generated content, learn how to build long-term relationships with your audience and unlock the secrets to success in the ever-shifting digital landscape.
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...Tatiana Kojar
Skybuffer AI, built on the robust SAP Business Technology Platform (SAP BTP), is the latest and most advanced version of our AI development, reaffirming our commitment to delivering top-tier AI solutions. Skybuffer AI harnesses all the innovative capabilities of the SAP BTP in the AI domain, from Conversational AI to cutting-edge Generative AI and Retrieval-Augmented Generation (RAG). It also helps SAP customers safeguard their investments into SAP Conversational AI and ensure a seamless, one-click transition to SAP Business AI.
With Skybuffer AI, various AI models can be integrated into a single communication channel such as Microsoft Teams. This integration empowers business users with insights drawn from SAP backend systems, enterprise documents, and the expansive knowledge of Generative AI. And the best part of it is that it is all managed through our intuitive no-code Action Server interface, requiring no extensive coding knowledge and making the advanced AI accessible to more users.
Your One-Stop Shop for Python Success: Top 10 US Python Development Providersakankshawande
Simplify your search for a reliable Python development partner! This list presents the top 10 trusted US providers offering comprehensive Python development services, ensuring your project's success from conception to completion.
Main news related to the CCS TSI 2023 (2023/1695)Jakub Marek
An English 🇬🇧 translation of a presentation to the speech I gave about the main changes brought by CCS TSI 2023 at the biggest Czech conference on Communications and signalling systems on Railways, which was held in Clarion Hotel Olomouc from 7th to 9th November 2023 (konferenceszt.cz). Attended by around 500 participants and 200 on-line followers.
The original Czech 🇨🇿 version of the presentation can be found here: https://www.slideshare.net/slideshow/hlavni-novinky-souvisejici-s-ccs-tsi-2023-2023-1695/269688092 .
The videorecording (in Czech) from the presentation is available here: https://youtu.be/WzjJWm4IyPk?si=SImb06tuXGb30BEH .
Have you ever been confused by the myriad of choices offered by AWS for hosting a website or an API?
Lambda, Elastic Beanstalk, Lightsail, Amplify, S3 (and more!) can each host websites + APIs. But which one should we choose?
Which one is cheapest? Which one is fastest? Which one will scale to meet our needs?
Join me in this session as we dive into each AWS hosting service to determine which one is best for your scenario and explain why!
Let's Integrate MuleSoft RPA, COMPOSER, APM with AWS IDP along with Slackshyamraj55
Discover the seamless integration of RPA (Robotic Process Automation), COMPOSER, and APM with AWS IDP enhanced with Slack notifications. Explore how these technologies converge to streamline workflows, optimize performance, and ensure secure access, all while leveraging the power of AWS IDP and real-time communication via Slack notifications.
Best 20 SEO Techniques To Improve Website Visibility In SERPPixlogix Infotech
Boost your website's visibility with proven SEO techniques! Our latest blog dives into essential strategies to enhance your online presence, increase traffic, and rank higher on search engines. From keyword optimization to quality content creation, learn how to make your site stand out in the crowded digital landscape. Discover actionable tips and expert insights to elevate your SEO game.
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAUpanagenda
Webinar Recording: https://www.panagenda.com/webinars/hcl-notes-und-domino-lizenzkostenreduzierung-in-der-welt-von-dlau/
DLAU und die Lizenzen nach dem CCB- und CCX-Modell sind für viele in der HCL-Community seit letztem Jahr ein heißes Thema. Als Notes- oder Domino-Kunde haben Sie vielleicht mit unerwartet hohen Benutzerzahlen und Lizenzgebühren zu kämpfen. Sie fragen sich vielleicht, wie diese neue Art der Lizenzierung funktioniert und welchen Nutzen sie Ihnen bringt. Vor allem wollen Sie sicherlich Ihr Budget einhalten und Kosten sparen, wo immer möglich. Das verstehen wir und wir möchten Ihnen dabei helfen!
Wir erklären Ihnen, wie Sie häufige Konfigurationsprobleme lösen können, die dazu führen können, dass mehr Benutzer gezählt werden als nötig, und wie Sie überflüssige oder ungenutzte Konten identifizieren und entfernen können, um Geld zu sparen. Es gibt auch einige Ansätze, die zu unnötigen Ausgaben führen können, z. B. wenn ein Personendokument anstelle eines Mail-Ins für geteilte Mailboxen verwendet wird. Wir zeigen Ihnen solche Fälle und deren Lösungen. Und natürlich erklären wir Ihnen das neue Lizenzmodell.
Nehmen Sie an diesem Webinar teil, bei dem HCL-Ambassador Marc Thomas und Gastredner Franz Walder Ihnen diese neue Welt näherbringen. Es vermittelt Ihnen die Tools und das Know-how, um den Überblick zu bewahren. Sie werden in der Lage sein, Ihre Kosten durch eine optimierte Domino-Konfiguration zu reduzieren und auch in Zukunft gering zu halten.
Diese Themen werden behandelt
- Reduzierung der Lizenzkosten durch Auffinden und Beheben von Fehlkonfigurationen und überflüssigen Konten
- Wie funktionieren CCB- und CCX-Lizenzen wirklich?
- Verstehen des DLAU-Tools und wie man es am besten nutzt
- Tipps für häufige Problembereiche, wie z. B. Team-Postfächer, Funktions-/Testbenutzer usw.
- Praxisbeispiele und Best Practices zum sofortigen Umsetzen
FREE A4 Cyber Security Awareness Posters-Social Engineering part 3Data Hops
Free A4 downloadable and printable Cyber Security, Social Engineering Safety and security Training Posters . Promote security awareness in the home or workplace. Lock them Out From training providers datahops.com
FREE A4 Cyber Security Awareness Posters-Social Engineering part 3
Ndss12 woodpecker
1. Systematic Detection of Capability Leaks in Stock Android Smartphones
Michael Grace, Yajin Zhou, Zhi Wang, Xuxian Jiang
North Carolina State University
890 Oval Drive, Raleigh, NC 27695
{mcgrace, yajin zhou, zhi wang}@ncsu.edu jiang@cs.ncsu.edu
Abstract mobile apps can be readily accessed and downloaded to run
on smartphones from various app stores [2]. For exam-
Recent years have witnessed a meteoric increase in the ple, it has been reported [22] that Google’s Android Mar-
adoption of smartphones. To manage information and fea- ket already hosts 150,000 apps as of February, 2011 and the
tures on such phones, Android provides a permission-based number of available apps has tripled in less than 9 months.
security model that requires each application to explicitly Moreover, it is not only official smartphone platform ven-
request permissions before it can be installed to run. In dors (e.g., Apple and Google) that are providing app stores
this paper, we analyze eight popular Android smartphones that host hundreds of thousands of apps; third-party vendors
and discover that the stock phone images do not properly (e.g., Amazon) are also competing in this market by provid-
enforce the permission model. Several privileged permis- ing separate channels for mobile users to browse and install
sions are unsafely exposed to other applications which do apps.
not need to request them for the actual use. To identify Not surprisingly, mobile users are increasingly relying
these leaked permissions or capabilities, we have developed on smartphones to store and handle personal data. Inside
a tool called Woodpecker. Our results with eight phone im- the phone, we can find current (or past) geo-location infor-
ages show that among 13 privileged permissions examined mation about the user [3], phone call logs of placed and
so far, 11 were leaked, with individual phones leaking up received calls, an address book with various contact infor-
to eight permissions. By exploiting them, an untrusted ap- mation, as well as cached emails and photos taken with
plication can manage to wipe out the user data, send out the built-in camera. The type and the volume of infor-
SMS messages, or record user conversation on the affected mation kept in the phone naturally lead to various con-
phones – all without asking for any permission. cerns [13, 14, 27, 42] about the safety of this private in-
formation, including the way it is managed and accessed.
To mediate access to various personal information and
1 Introduction certain advanced phone functions, smartphone platform
vendors have explored a number of approaches. For ex-
Recent years have witnessed a meteoric increase in the ample, Apple uses a vetting process through which each
adoption of smartphones. According to data from IDC [24], third-party app must be scrutinized before it will be made
smartphone manufacturers shipped 100.9 million units in available in the app store. After installing an app, Apple’s
the fourth quarter of 2010, compared to 92.1 million units iOS platform will prompt the user to approve the use of
of PCs shipped worldwide. For the first time in history, some functions at run-time, upon their first access. From
smartphones are outselling personal computers. Their pop- another perspective, Google defines a permission-based se-
ularity can be partially attributed to the incredible function- curity model in Android by requiring each app to explicitly
ality and convenience smartphones offered to end users. In request permissions up-front to access personal information
fact, existing mobile phones are not simply devices for mak- and phone features. The requested permissions essentially
ing phone calls and receiving SMS messages, but powerful define the capability the user may grant to an Android app.
communication and entertainment platforms for web surf- In other words, they allow a user to gauge the app’s capa-
ing, social networking, GPS navigation, and online bank- bility and determine whether or not to install the app in the
ing. The popularity of smartphones is also spurred by the first place. Due to the central role of the permission-based
proliferation of feature-rich devices as well as compelling model in running Android apps, it is critical that this model
mobile applications (or simply apps). In particular, these is properly enforced in existing Android smartphones.
2. In this paper, we systematically study eight popular An- The rest of this paper is organized as follows: Section 2
droid smartphones from leading manufacturers, including and Section 3 describe our system design and implementa-
HTC, Motorola, and Samsung and are surprised to find tion, respectively. Section 4 presents the detailed evaluation
out these stock phone images do not properly enforce the results from our study of eight Android smartphones. Sec-
permission-based security model. Specifically, several priv- tion 5 discusses the limitations of our approach and suggests
ileged (or dangerous) permissions that protect access to sen- possible improvement. Finally, Section 6 describes related
sitive user data or phone features are unsafely exposed to work and Section 7 summarizes our conclusions.
other apps which do not need to request these permissions
for the actual use. For simplicity, we use the term capability 2 System Design
leak to represent the situation where an app can gain access
to a permission without actually requesting it. Each such
situation essentially leads to a violation of the permission- We aim to identify capability leaks, i.e., situations where
based security model in Android. an app can gain access to a permission without actually re-
questing it. Each such situation essentially sidesteps An-
To facilitate exposing capability leaks, we have devel-
droid’s permission-based security model. In this work, we
oped a system called Woodpecker. By employing data flow
choose to focus on those permissions used by the pre-loaded
analysis on pre-loaded apps, Woodpecker systematically
apps as a part of an Android phone’s firmware, since the
analyzes each app on the phone to explore the reachability
firmware has access to some permissions that are too priv-
of a dangerous permission from a public, unguarded inter-
ileged to be granted to third-party apps. For simplicity, we
face. To better examine possible capability leaks, our sys-
use the terms “permissions” and “capabilities” interchange-
tem distinguishes two different categories. Explicit capa-
ably.
bility leaks allow an app to successfully access certain per-
Figure 1 provides a high-level overview of our system.
missions by exploiting some publicly-accessible interfaces
To detect the two different kinds of capability leaks (i.e.,
or services without actually requesting these permissions by
explicit and implicit), our system performs two complemen-
itself. Implicit capability leaks allow the same, but instead
tary sets of analysis. Specifically, to expose explicit leaks of
of exploiting some public interfaces or services, permit an
a capability, our system first locates those (pre-loaded) apps
app to acquire or “inherit” permissions from another app
in the phone that have the capability. For each such app,
with the same signing key (presumably by the same author).
our system then identifies whether a public interface is ex-
Consequently, explicit leaks represent serious security er-
posed that can be used to gain access to it. (This public
rors as they subvert the permission-based security model in
interface is essentially an entry point defined in the app’s
Android while implicit leaks could misrepresent the capa-
manifest file, i.e., an activity, service, receiver, or content
bilities available to an app.
provider.) In other words, starting from some public inter-
We have implemented a Woodpecker prototype to un-
face, there exists an execution path that can reach some use
cover both types of capability leaks in Android-based smart-
of the capability. If this public interface is not guarded by
phones. Our current prototype focuses on 13 representa-
a permission requirement, and the execution path does not
tive privileged permissions that protect sensitive user data
have sanity checking in place to prevent it from being in-
(e.g., geo-location) or phone features (e.g., the ability to
voked by another unrelated app, we consider the capability
send SMS messages). We have used our prototype to ex-
leaked. Our system then reports such leaks and further pro-
amine eight popular Android phones: HTC Legend/EVO
vides evidence that can be used to fashion input to exercise
4G/Wildfire S, Motorola Droid/Droid X, Samsung Epic 4G,
the leaked capability.
and Google Nexus One/Nexus S. Our results show that
On the other hand, implicit capability leaks arise from
among these 13 privileged permissions, 11 were explicitly
the abuse of an optional attribute in the manifest file, i.e.,
leaked, with individual phones leaking up to eight permis-
“sharedUserId.” This attribute, if defined, causes mul-
sions.1 In particular, by exploiting these leaked capabilities,
tiple apps signed by the same developer certificate to share
an untrusted app on these affected phones can manage to
a user identifier. As permissions are granted to user iden-
wipe out the user data on the phones, send out SMS mes-
tifiers, this causes all the apps sharing the same identifier
sages (e.g., to premium numbers), record user conversation,
to be granted the union of all the permissions requested by
or obtain user geo-locations – all without asking for any per-
each app. To detect such leaks in an app that shares a user
mission.
identifier, our system reports the exercise of an unrequested
1 Since April, 2011, we have been reporting the discovered capability capability, which suspiciously has been requested by an-
leaks to the corresponding vendors. So far, Motorola and Google have other app by the same author. We stress that an implicit
confirmed the discovered vulnerabilities related to their phones. However,
leak requires a certain combination of apps to be installed:
we experienced major difficulties with HTC and Samsung. Our experience
is similar to others [6], echoing “the seven deadly sins of security vulnera- an app seeking to gain unauthorized capabilities can only do
bility reporting.” [32] so if another app, with the same shared user identifier and
3. Pre−loaded Apps
Possible Path Identification Infeasible Path Pruning Capability Leak Report
Other System Images
(e.g., framework.dex)
Android Framework APIs
Figure 1. An overview of Woodpecker
signing key, is installed to grant the additional permission. 2.1.1 Possible Path Identification
In the context of the pre-loaded apps on the phone, we can
identify whether such a colluding app exists. However, due Given a pre-loaded app under inspection, our system first
to the fact that we cannot rule out the possibility of a col- extracts its Dalvik bytecode, and then builds a control-flow
luding app being installed at a later time, its mere absence graph (CFG) to locate possible execution paths. Since con-
does not indicate such an implicit leak is “safe” and may structing a CFG is a well-studied topic, we in the following
not occur later. focus on those Android-specific aspects that make our task
In this work, we consider the scenario where a smart- complicated.
phone user has installed a third-party app on the phone. The first issue stems from indirect control-flow trans-
The author of the third-party app has the necessary knowl- fer instructions in Dalvik bytecode. Dalvik targets a hypo-
edge of the phone’s system image, and aims to maliciously thetical machine architecture, which does not support most
perform some high-privilege activities (e.g., recording the forms of indirect control-flow transfer. In fact, the only indi-
user’s phone conversations) through Android APIs that are rect transfer in Dalvik’s machine language is due to the Java
protected by permission checks. To do that, the attacker equivalent of pointers: object references. However, object
chooses to not request the required permissions to elude references are rather commonly passed as arguments within
detection or these permissions cannot be granted to third- an app method, and due to inheritance it is often not possible
party apps. (Examples include those permissions defined to unambiguously determine what concrete class a reference
as signature or signatureOrSystem [17]). Mean- represents. During our analysis, object references will also
while, we limit the attacker’s scope by assuming the An- naturally require type resolution of related objects. In our
droid framework (including the OS kernel) is trusted. Also, current prototype, we take a conservative approach. Specifi-
we assume that the signing key to the system image has cally, when analyzing an app’s Dalvik bytecode, our system
not been leaked to the attacker. Given these constraints, a maintains a comprehensive class hierarchy. When an am-
malicious app will not be able to directly access the high- biguous reference is encountered, we consider all possible
privilege APIs. However, since many pre-loaded apps have assignable classes. This is a straightforward approach, but
the corresponding permissions, the malicious app will have one that will not introduce any false negatives (Section 5).
gained access to a high-privilege capability if it can cause Another problem arises from Android’s event-driven na-
one of these apps to invoke the desired API on its behalf. ture. In particular, due to the large number of callbacks
used by the Android framework, app execution often passes
through the framework to emerge elsewhere in the app. For
2.1 Explicit Capability Leak Detection
a concrete example, consider the java.lang.Thread
class. This class is used to implement native threads, which
Explicit capability leaks may occur in any pre-loaded Android uses in abundance to achieve better UI respon-
app that has requested a capability of interest in its manifest siveness. A developer can simply extend this class, im-
file. To detect these leaks, our system analyzes each such plement the run() method, and then call the start()
app in two steps. The first step, possible-path identification method to schedule the thread. However, if we analyze
builds a control-flow graph to identify possible paths from a only the code contained within the app, the run() method
well-defined entry point (in the manifest file) to some use of does not appear to be reachable (from start()), despite
the capability. After that, the second step, feasible path re- the fact that after the start() method is called, con-
finement employs field- and path-sensitive inter-procedural trol flow goes through the Dalvik VM to the underlying
data flow analysis to determine which of these paths are fea- thread scheduler and eventually to the run() method. In
sible. other words, Android’s event-driven nature will unavoid-
4. Entry Point
Capability- Input: entry points, known method summaries
Exercising Method
Output: a set of capability leaks
foreach entry point ∈ entry points do
worklist = initial state: start of the entry point
Thread.start() Thread.run() states = initial state
summaries = known method summaries
foreach state ∈ worklist do
OS Scheduler
remove state from worklist
if state’s instruction is a method call then
if a summary does not exist for the target
then
Figure 2. A discontinuity in the control flow summarize(target, summaries);
introduced by the Android framework. end
end
worklist+ = δ(state) − states
states+ = δ(state)
ably cause some discontinuity in the CFG construction if end
we only focus on analyzing the app code (Figure 2). For- if a dangerous-call state is flagged then
tunately, beyond CFG construction, this intervening frame- report the state as a capability leak
work code is of no particular value to our analysis, and its end
behavior is well-defined in the Android framework APIs. end
Therefore, we leverage these well-defined semantics to link Algorithm 1: Capability leak detection
these two methods directly in the control flow graph, re-
solving the discontinuity in the process. We have applied
this strategy to a number of other callbacks, such as those struction) must follow from the preceding ones. Similar to
for message queues, timers, and GPS position updates. other data flow analysis techniques, symbolic path simula-
Android’s use of events is so core to the platform that tion implements an iterative algorithm that converges on a
it is even reflected in the structure of Android apps. This fix-point. At each program point, the set of input states are
leads to a final complication, because an Android app does fed through a transfer function (representing the operation
not necessarily have only one entry point. Instead, rather performed by that instruction) to produce a set of output
than a traditional “main method” of some kind, an Android states. However, before these output states are used as in-
app contains one or more components defined in its man- put states for that program point’s successors, we verify that
ifest file. Each component can potentially define multiple their constraints are consistent. In this way, infeasible paths
entry points accessible through the Binder IPC mechanism. are not fed forward through the analysis.
To take these factors into account, our prototype iterates As a field- and path-sensitive symbolic simulation al-
through each entry point defined in the manifest file to build gorithm (summarized by Algorithm 1), our approach con-
the CFG. Within each CFG, we then locate possible paths, siders multiple similar concrete paths through a program
each indicating the reachability from a known entry point to at once, and condenses methods into parameterized sum-
a point that exercises a specific permission of interest. maries that relate their inputs to their outputs. Each state
in the analysis encodes the value of data fields with con-
2.1.2 Feasible Path Refinement straints, allowing some similar states to be joined with one
another. Particularly, the algorithm operates in the stan-
The previous step produces control-flow graphs which may dard fashion for data flow analysis: a worklist is maintained
represent a tremendous number of potential paths. Among of actively-considered states, and a transfer function (δ) is
these possible paths, not all of them lead to a dangerous call used to generate new states from a given state. Only new
that exercises a permission of interest, and of those that do, states are added to the worklist, so eventually the algorithm
not all are feasible. Therefore, we employ inter-procedural converges on a solution that represents all the feasible states
data flow analysis to find paths that are both feasible and reachable from a given entry point.
result in a dangerous call. By considering certain properties of the Android plat-
Specifically, we use symbolic path simulation, a path- form, we can optimize our algorithm in a number of as-
sensitive data flow analysis technique. The underlying in- pects. For example, we accelerate the process by us-
tuition is that a path of program execution can be modeled ing method summaries to avoid recursively considering the
as a set of program states, each dependent on the last. For same method-call chains multiple times. To save space,
this set of states to be feasible, each program point (or in- joining (rather than simply adding) new states to the work-
5. list and visited-state list make the algorithm scale better During this infeasible path pruning step, we also need
both in terms of time and memory. Our implementation rec- to account for explicit permission checks within the identi-
ognizes the value constraints placed on each memory item, fied path. An app might allow any caller to invoke its en-
and will aggressively merge similar states where possible. try points, yet deny unprivileged callers access to danger-
As an example, if two states are joined that only differ by ous functionality by explicitly checking the caller’s creden-
whether a boolean value is true or false, the resulting state tials before any dangerous invocations. Such an arrange-
will simply remove any constraint on the boolean value. In ment would not constitute a capability leak, and so should
this way, fewer states need to be remembered, and fewer not be reported. A na¨ve solution would be to mark any
ı
successors calculated using the transfer function δ. path encountering an interesting permission check as infea-
Moreover, since an Android app can define multiple en- sible. However, our approach does not know what kind of
try points, there is a need to produce a separate set of poten- dangerous call lies at the end of the path beforehand. Al-
tial paths for each. These paths do not include any executed lowing unrelated permission checks to mark whole paths
instructions in the app prior to the entry point, which ex- as infeasible would therefore introduce false negatives. In-
cludes such code as any constructors that set the initial state stead, we model the permission system within our artificial
of the app. Due to the fact that the entry points in an app method summaries. Explicit permission checks set a flag
can be invoked in any sequence, we opt to take a conser- along their “true” branch; if that path of execution later en-
vative approach by assuming that a field might contain any counters a corresponding dangerous call, it is not reported
assignable value. As that field is used along a path of execu- as a capability leak.
tion, the list of possible values shrinks each time it is used in A side benefit of performing this kind of analysis is that
a way that renders some candidate values impossible. When it models all data flow assignments, not just those relating to
reducing infeasible paths, we also face the same type in- branch conditions. As a result, we can trace the provenance
ference problem experienced in the first step. Fortunately, of any arguments to the dangerous method. With such in-
the set of inferences built up by symbolic path simulation formation, we can characterize the severity of the capability
naturally mitigates the path explosion caused by our first leak. A capability leak that directly passes through argu-
step. Specifically, object instances can be tracked during ments from the external caller is obviously worse than one
the path simulation, and some paths will become infeasible that only allows invocation with constant values, and this
after the system infers the object’s type somewhere along a design can distinguish between the two. Given that path
path. Certain Dalvik bytecode operations, especially type- feasibility is undecidable, our design errs on the side of cau-
carrying instructions, can also greatly help. For instance, tion: it will not claim a feasible path is infeasible, but might
the check-cast opcode establishes that its operand can claim the reverse is true. As a result, this argument infor-
be assigned to the supplied type, or an exception is thrown. mation is valuable, as it can be used to generate a concrete
test case that verifies the detected capability leak.
In addition, the execution of our algorithm also involves
handling Android framework APIs or methods that do not
belong to the app. Specifically, the app under inspection 2.2 Implicit Capability Leak Detection
may invoke certain APIs that are exported by the Android
framework. In our algorithm, the transfer function for a When detecting explicit capability leaks, we focus on
method invocation opcode is a method summary, which es- those apps that request permissions of interest in their man-
sentially phrases the method’s outputs in terms of its inputs. ifest files. If an app has a sharedUserId in its manifest
Without statically analyzing the code for an external method but does not request a certain (dangerous) permission, we
– and all of its dependencies – we cannot build such a sum- also need to investigate the possibility of an implicit capa-
mary. Yet analyzing the entire Android framework would bility leak.
easily lead to state explosion and scalability issue. To ad- To detect implicit capability leaks, we employ a simi-
dress that, we again leverage the well-defined API seman- lar algorithm as for explicit leaks with necessary changes
tics of the Android framework. Specifically, it contains a to reflect a fundamental difference in focus. Specifically,
remarkably robust set of predefined libraries, which reduces explicit capability leak detection assumes the caller of an
the need for developers to pull in third-party libraries to app’s exposed API is malicious, while implicit capability
support their code. By summarizing these built-in classes leak detection assumes the app itself might be malicious.
ahead of time, we can avoid paying the time, space, and Accordingly, instead of only starting from the well-defined
complexity costs associated with doing so each time during entry points in the explicit leak detection, there is a need to
application analysis. In our prototype, we find that this ap- broaden our search to include the app’s initialization.
proach allows us to phrase some functions more succinctly Unfortunately, modeling the initialization process in an
than the algorithm would, as we can trim out unimportant Android app is somewhat complicated. Specifically, there
details from the summaries. are two kinds of constructors to handle: (1) Instance con-
6. structors that are explicitly invoked in the Dalvik byte- variant). A standalone script has been developed to extract
code with the new-instance bytecode operation and (2) all the pre-installed apps and disassemble them to extract
Class constructors or static initialization blocks that are their bytecode for subsequent analysis. Depending on the
implicitly invoked the first time a class is used. Accord- number of apps installed on the device and the complex-
ingly, instance constructors are relatively straightforward to ity or functionality implemented in these apps, this process
handle as they need to be explicitly invoked. However, class typically takes on the order of ten minutes per smartphone
constructors are more complicated. In particular, a class image.
constructor may be invoked in a number of scenarios: it After extracting the app manifest files, we further comb
is instantiated with the new keyword, a static member through them for two things: requests for any permis-
of the class is referenced, or one of its subclasses is like- sions of interest and the optional sharedUserId at-
wise initialized. This means that this type of initialization tribute. Apps that are granted related permissions are
can occur in a variety of orders. In our prototype, we treat checked for explicit capability leaks, while those with the
all of the relevant instructions as branches, and take into sharedUserId attribute set are checked for implicit ca-
account the class loading order to determine the path fea- pability leaks. Naturally, we also compute the actual set
sibility. Also, in our system, we consider a capability to of permissions granted to each pre-loaded app by com-
have been implicitly leaked if there is any way to exercise bining all the permission requests made with the same
it, which is different from explicit capability leak detection. sharedUserId.
(This has implications in changing method summaries used
for pruning infeasible paths – Section 2.1.2.) 3.1 Control-Flow Graph Construction
Finally, once we have identified that an implicit capabil-
ity leak exists, we can perform an additional step to deter-
We iterate through each selected pre-loaded app to detect
mine whether that leak may actually be exercised. In the
possible capability leaks. As there are tens of dangerous
context of a phone’s system image, we can determine the
permissions defined in the Android framework, instead of
runtime permissions granted to each shared user identifier
building a specific control-flow graph (CFG) for each per-
by crawling the manifest files of all the packages in the im-
mission, we choose to first build a generic CFG to assist our
age. We union the permissions granted to each application
static analysis.
with a given shared user identifier, which yields the set of
In particular, we start from each entry point and build
permissions given to each of them. We report any implicitly
the respective CFG. The generic whole-program CFG will
leaked permissions contained within that set.
be the union of these CFGs. There is some subtlety in
Android involved in mapping the components defined in
3 Implementation the manifest file to their actual entry points. Some en-
try points are standard and can be readily determined by
We have implemented a Woodpecker prototype that con- the type of components contained within the app. Specif-
sists of a mixture of Java code, shell scripts and Python ically, there are in total four types, and each has a pre-
scripts. Specifically, our static analysis code was developed defined interface to the rest of the system. For instance,
from the open-source baksmali disassembler tool (1.2.6). any “receiver” defined in the manifest file must subclass
We could have developed Woodpecker as a set of extensions android.content.BroadcastReceiver. In such
to an existing Java bytecode analysis tool (e.g., Soot [4] or cases, inspecting the class hierarchy allows to determine
WALA [5]). Given concerns over the accuracy of existing that the “onReceive(Context, Intent)” method is
Dalvik-to-Java bytecode translators, we opted to operate di- an entry point (as per the specification).
rectly on baksmali’s intermediate representation. To de- Moreover, among these four types, three of them solely
tect possible capability leaks in an Android phone, our sys- take data objects as inputs through their entry points, but
tem first leverages the Android Debug Bridge (adb) tool services can be different. In particular, Android defines
[1] to obtain access the phone’s system image, mainly those a CORBA-like binding language, the Android Interface
files in the /system/app and /system/framework Definition Language (AIDL), which allows services to ex-
directories. These directories contain all of the pre-installed pose arbitrary methods to other apps. aidl files are used
apps on the device, as well as any dependencies they need at compile-time to manufacture Binder stubs and skele-
to run. tons that encapsulate the necessary IPC functionality. At
After obtaining the phone image, we then enumerate run-time, the component’s onBind(Intent) method is
all pre-installed apps. For each app, our system decom- called by the system, which returns an android.os.-
presses the related Android package (apk) file to extract its Binder object. The methods contained within this object
manifest file (AndroidManifest.xml) and then pairs it are then exported to callers that have a compatible skele-
with the app’s bytecode (either classes.dex or its odex ton class. Since we only analyze the bytecode and do not
7. Table 1. The list of 13 representative permissions in our study († : we omit android.permission. prefix in
each permission)
Permission† Capability
ACCESS COARSE LOCATION Access coarse location (e.g., WiFi)
ACCESS FINE LOCATION Access fine location (e.g., GPS)
CALL PHONE Initiate a phone call (without popping up an UI for confirmation.)
CALL PRIVILEGED Similar to CALL PHONE, but can dial emergency phone numbers (e.g., 911)
CAMERA Access the camera device
DELETE PACKAGES Delete existing apps
INSTALL PACKAGES Install new apps
MASTER CLEAR Remove user data with a factory reset
READ PHONE STATE Read phone-identifying info. (e.g., IMEI)
REBOOT Reboot the device
RECORD AUDIO Access microphones
SEND SMS Send SMS messages
SHUTDOWN Power off the device
have access to the original aidl files used to define the publicly accessible, an explicit capability leak is detected.
interface, there is a need to further parse and infer the in- Due to the large number of sensitive permissions defined in
ternal structure of the Binder object. Each such object the Android framework, our study chooses thirteen repre-
contains an onTransact() method that is passed a par- sentative permissions marked dangerous, signature
cel of data that encodes which method to call. We can then or signatureOrSystem. These permissions are sum-
treat this method as an entry point in order to build our marized in Table 1 and were chosen based on their potential
CFG. However, once the graph has been built, it is more for abuse or damage. For example, the SEND SMS permis-
semantically accurate to treat the embedded method calls sion is a favorite of malware authors [18]: it can be used to
in onTransact() as entry points for the purposes of our send messages to costly premium numbers, which pay the
feasible path refinement stage. culprit for each such text.
From another perspective, Android apps essentially ex- For each chosen permission, our first step is to iden-
pose a set of callbacks to the system instead of a single tify the list of related Android APIs that might exercise the
“main method.” Our system leverages the knowledge of permission. However, such a list is not easy to come by.
how these callbacks are defined in Android to identify them. In fact, we found out that though Android’s permission-
In addition, the Android framework defines many other call- based security model might be comprehensive enough in
backs at run-time, which will similarly cause discontinu- specifying the permissions required to access sensitive data
ities in the CFG generation. One example is the previous or features, the available API documentation is incomplete
Thread.start()→run() scenario. In our prototype, about which APIs a permission grants access to. Specif-
instead of statically analyzing the entire Android frame- ically, when dealing with various apps in the system im-
work, we opt to use knowledge of the framework’s seman- age, we encountered numerous permissions not meant for
tics to connect the registration of a callback to the callback general consumption – and that therefore do not even have
itself. To automate this process, we provide a boilerplate file formally specified APIs. One example is “android.-
that represents knowledge about the framework. This file permission.MASTER CLEAR,” which allows an app to
contains simplified definitions for any explicitly-modelled perform a factory reset of the smartphone. This permis-
method in the framework, written in the dex format; it is sion is marked as signatureOrSystem, so only apps
fed into our system alongside the app’s code to facilitate included in the system image can request it; it is intended to
CFG construction. be implemented by the vendor and only used by the vendor,
so none of the APIs listed in the API documentation check
3.2 Capability Leak Detection this permission.
For each related permission and the associated Android
With the constructed CFG and the set of entry points, we APIs, our next step then reduces the generic CFG to a
then aim to identify possible execution paths from one of permission-specific CFG. Within the reduced CFG, we can
the entry points to some use of an Android API that exer- then apply the Algorithm 1 to locate possible execution
cises a permission of interest. If the path is not protected paths from an entry point to the associated Android APIs.
by the appropriate permission checks and its entry point is For each identified path, we further look for the presence
8. of certain permission checks. Our experience indicates
that some permission checks are already defined in the Table 2. Eight studied Android smartphones
Vendor Model Android Version # Apps
manifest file (and thus automatically enforced by the
Legend 2.1-update1 125
Android framework). However, many others will explicitly HTC EVO 4G 2.2.2 160
check their caller’s permissions. In our prototype, we Wildfire S 2.3.2 144
resort to the Android Open Source Project (AOSP) to find Droid 2.2.2 76
explicit permission checks in the framework. There are also Motorola
Droid X 2.2.1 161
some cases that do not fall under the AOSP. For them we Samsung Epic 4G 2.1-update1 138
have to apply baksmali to representative phone images Nexus One 2.3.3 76
Google
and then manually examine each explicit permission Nexus S 2.3.3 72
check. Using the previous example of “android.-
permission.MASTER CLEAR,” Android provides an
interface, android.os.ICheckinService that de- a case study for each type of capability leak, explicit and
clares the masterClear() method. The Samsung Epic implicit. Lastly, Section 4.3 consists of a performance mea-
4G’s factory reset implementation contains a class com.- surement of our system, both in terms of the accuracy of its
android.server.FallbackCheckinService. path-pruning algorithm and its speed.
This class implements this Android interface, whose
masterClear() method explicitly checks the 4.1 Results Overview
“android.permission.MASTER CLEAR” per-
In order to assess capability leaks posed in the wild, we
mission.
selected phones representing a variety of manufacturers and
To facilitate our static analysis, our prototype also in-
feature sets. Table 2 shows the phone images and their ver-
cludes a fictitious dangerous class that has many static
sions we analyzed using Woodpecker. These phones span
permission-associated member fields. Each identified An-
most of the 2.x version space, and as shown by the app
droid API call, if present in an execution path being an-
count for each phone image, some are considerably more
alyzed, will update the member field related to the asso-
complex than others.
ciated permission. As a result, we can detect dangerous
Running Woodpecker on each phone image produces a
calls by simply listing the related member fields in this
set of reported capability leak paths. For each reported path,
class. Similarly, to model the impact a caller’s permissions
we then manually verify the leak by tracing the path through
have on whether a dangerous call can succeed, we use an-
the disassembled Dalvik bytecode. For explicit capability
other fictitious permission class. This class contains
leaks whose paths seem plausible, we then craft a test ap-
a number of member fields and an artificial method defi-
plication and run it on the actual device, where possible.
nition for Context.checkCallingPermission().
The results are summarized in Table 3.
This method sets these member fields dependent upon the
After identifying these capability leaks, we spent a con-
permission it is called with. In other words, each member
siderable amount of time on reporting them to the corre-
field flags whether a path of execution has checked a partic-
sponding vendors. As of this writing, Motorola and Google
ular permission. During an explicit capability leak analysis
have confirmed the reported vulnerabilities in the affected
run, we only consider a capability to have been leaked if a
phones. HTC and Samsung have been really slow in re-
state exists that contains a dangerous-call field modification
sponding to, if not ignoring, our reports/inquiries. Though
(maintained in dangerous class) and does not have the
the uncovered capabilities leaks on the HTC and Samsung
corresponding permission-check flag set (in permission
phones have not been confirmed by their respective ven-
class). Implicit capability leak analysis does not need to
dors, we have developed a test app to exercise and confirm
be concerned about the value of the permission-check flags.
all the discovered (explicit) capability leaks on the affected
Instead, it is sufficient to have a dangerous call field modi-
phones.
fication (in dangerous class).
We believe these results demonstrate that capability
leaks constitute a tangible security weakness for many An-
4 Evaluation droid smartphones in the market today. Particularly, smart-
phones with more pre-loaded apps tend to be more likely
In this section, we present the evaluation results of apply- to have explicit capability leaks. The reference implemen-
ing Woodpecker to eight smartphones from four vendors, tations from Google (i.e., the Nexus One and Nexus S)
including several flagship phones billed as having signifi- are rather clean and free from capability leaks, with only
cant additional bundled functionality on top of the standard a single minor explicit leak (marked as 2 in Table 3) due
Android platform. We describe our methodology and tab- to an app com.svox.pico. This app defines a receiver,
ulate our results in Section 4.1. In Section 4.2, we present which can be tricked to remove another app, com.svox.-
9. Table 3. Capability leak results of eight Android-based smartphones (E: explicit leaks; I: implicit leaks)
HTC Motorola Samsung Google
Permission Legend EVO 4G Wildfire S Droid Droid X Epic 4G Nexus One Nexus S
E I E I E I E I E I E I E I E I
ACCESS COARSE LOCATION · · · · · · · · · ·
ACCESS FINE LOCATION · · · · · · · · · · · ·
CALL PHONE · · · · · · · · · · · · · ·
CALL PRIVILEGED · · · · · 1 · · · · · · · · · ·
CAMERA · · · · · · · · · · · · ·
DELETE PACKAGES 2 · 2 · 2 · 2 · 2 · 2 · 2 · 2 ·
INSTALL PACKAGES · · · · · · · · · · · · · · · ·
MASTER CLEAR · · · · · · · · · · · · · · ·
READ PHONE STATE · · · · · · · · · · ·
REBOOT · · · · · · · · · · · · · · ·
RECORD AUDIO · · · · · · · · · · · · ·
SEND SMS · · · · · · · · · · · · ·
SHUTDOWN · · · · · · · · · · · · · · ·
Total 6 2 8 2 4 4 1 0 4 0 3 2 1 0 1 0
langpack.installer by any other third-party app.2 explicit capability leak is of this type, which once exploited,
Our data also show that these capability leaks are not evenly allows for unauthorized wiping of user data on the phone.
distributed among smartphones – at least for the 13 permis- To understand how Woodpecker detects this explicit
sions we modelled. For example, those smartphones with capability leak, we first explain the normal sequences
system images (i.e., the Motorola Droid) close to the ref- when the MASTER CLEAR capability is invoked. Specif-
erence Android design (i.e., the Nexus One and Nexus S) ically, the Samsung Epic 4G’s phone image has a pre-
seem to be largely free of capability leaks, while some of loaded app, com.sec.android.app.Selective-
the other flagship devices have several. Despite this general Reset, whose purpose is to display a confirmation screen
trend, we caution against drawing any overly broad conclu- that asks the user whether to reset the phone. The normal
sions, as some devices (e.g., the Motorola Droid X) with chain of events has another system app broadcast the cus-
higher app counts nevertheless contained fewer capability tom android.intent.action.SELECTIVE RESET
leaks than substantially simpler smartphones (e.g., the HTC Intent, which the SelectiveResetReceiver class
Legend). (defined in the pre-loaded app) listens for. When this
class receives such an intent, it opens the user inter-
4.2 Case Studies face screen (SelectiveResetApp) and waits for the
user to confirm their intentions. Once this is done, the
SelectiveResetService is started, which eventu-
To understand the nature of capability leaks and demon-
ally broadcasts an intent android.intent.action.-
strate the effectiveness of our system, we examine three sce-
SELECTIVE RESET DONE. The original Selective-
narios in depth. These scenarios were selected to illustrate
ResetReceiver class listens for this Intent and then
some of the patterns we encountered in practice, as well as
calls CheckinService.masterClear().
how our system was able to handle them.
Our system detects the last part of the above chain start-
ing after the broadcasted intent android.intent.-
4.2.1 Explicit Capability Leaks (Without Arguments) action.SELECTIVE RESET DONE is received in the
same pre-loaded app. In particular, the intent arrives
The simplest scenario, from Woodpecker’s perspective, in-
at one entry point defined in the app’s manifest file
volves an entry point calling a dangerous capability that is
(i.e., the onReceive(Context, Intent) method
not influenced by any arguments. These capabilities tend
within SelectiveResetReceiver), which then
to have simpler control flows, as there are no arguments to
executes a rather straightforward Intent-handling code
validate or parse. The Samsung Epic 4G’s MASTER CLEAR
sequence: (1) determines that the received Intent is an
2 This com.svox.pico app implements a text-to-speech engine android.intent.action.SELECTIVE RESET DONE
that the accessibility APIs use to talk. However, it exports a pub- operation; (2) gets the CheckinService that contains
lic receiver interface, com.svox.pico.LangPackUninstaller the master clear functionality; (3) checks whether it
for android.speech.tts.engine.TTS DATA INSTALLED in-
was retrieved successfully; and (4) calls Checkin-
tents. If such an intent is received, this app will blindly remove another
app, com.svox.langpack.installer, whose name is hard-coded Service.masterClear() in a worker thread. Since
in the implementation. CheckinService.masterClear() takes no argu-
10. ments, no additional dataflow analysis needs be performed SmsSenderService.onStart(Intent, int)
to characterize the capability leak.
SmsSenderService$ServiceHandler.sendMessage(Message)
In our experiments, we also found other capability leaks
of the same nature, including the REBOOT and SHUTDOWN resolves to
leaks on the HTC EVO 4G. On the same phone, we also android.os.Handler.sendMessage(Message)
found a new vendor-defined capability FREEZE exposed by
android.os.Handler.handleMessage(Message)
a system app, which disables the phone’s touchscreen and
buttons until the battery is removed. In those cases, there is resolves to
literally no control flow involved, making these capability SmsSenderService$ServiceHandler.handleMessage(Message)
leaks trivial to exploit. We point out that analyzing explicit
SmsSenderService.sendSms(Intent)
capability leaks that involve arguments works in much the
same fashion. Regardless, another explicit capability leak com.android.mms.transaction.SmsMessageSender.sendMessage(long)
case study is included (Section 4.2.2) that accounts for the
presence of arguments. android.telephony.SmsManager.sendMultipartTextMessage(...)
4.2.2 Explicit Capability Leaks (With Arguments)
Figure 3. The SEND SMS capability leak as a
Looking beyond simple imperative capability leaks, we call graph.
consider more complicated cases that involve argument-
taking capabilities. For example, Android’s SMS API con-
sists of three methods, each of which takes five or six ar- tial SmsSenderService$ServiceHandler.-
guments. The HTC phones have an explicit leak of this sendMessage(Message) call fully specifies the class
capability that entails significant preprocessing of these ar- that sendMessage(Message) will be called upon, but
guments, which we examine as an additional case study to SmsSenderService$ServiceHandler does not
illustrate how our system works. contain a definition for that method. Looking to its super-
On these phones, the general com.android.mms class, android.os.Handler, Woodpecker finds an ar-
messaging app has been extended to include a non- tificial method definition of the appropriate signature. This
standard service, com.htc.messaging.service.- definition in turn calls the android.os.Handler.-
SmsSenderService, which is used by other vendor handleMessage(Message) method, which is
apps to simplify sending SMS messages. This service can extended by the SmsSenderService$Service-
be started with an Intent that contains a number of ad- Handler class. In this case, our design has no difficulty
ditional data key-value pairs, known as Extras. Each resolving these relationships, because the first call fully
Extra contains some data about the SMS to be sent, such specifies the SmsSenderService$ServiceHandler
as the message’s text, its call-back phone number, the desti- class. This type information is then carried forward through
nation phone number, and so on. the call chain as a constraint on the arguments to each
The SmsSenderService service (Figure 4.2.2) pro- call, as a class’ methods are associated with an object
cesses these fields in its onStart(Intent, int) entry instantiating that class via an implicit argument (the this
point, ensuring that the mandatory key-value pairs exist, in- keyword).
cluding the message body and destination phone number. Ultimately, the app execution flow will reach Sms-
If they do, the Intent is bundled into a Message and Manager.sendMultipartTextMessage(), a
sent to the SmsSenderService$ServiceHandler method that exercises the dangerous SEND SMS permis-
class via the Android message-handling interface. This sion. The arguments by this point have been transformed:
interface is designed to allow different threads of ex- the destination address remains the same, but the call-back
ecution to communicate using a queue of Messages. number may not have been provided by the Intent’s
The typical paradigm uses a subclass of android.- data, and the message body might have been chunked into
os.Handler to poll for new Message objects, us- SMS-sized pieces if it is too long. When processing this
ing a handleMessage(Message) method. Such execution path, Woodpecker reports this path as feasible
android.os.Handler objects also expose meth- and thus exposing the exercised permission SEND SMS.
ods to insert Messages into their queue, such as Since the exercised capability took a number of arguments,
sendMessage(Message). our system also reports the provenance of each related
When building possible paths and pruning in- argument to the Android API, which allows for straight-
feasible paths, our system will diligently resolve forwardly linking the API arguments back to the original
the super- and sub-class relationships that bracket Intent passed to the entry point at the very beginning. In
the message-passing code. In this case, the ini- other words, by simply including a premium number in the
11. intent, the built-in app will start sending SMS messages to Intent to send to dial a contact. This helper method
this premium number! builds the actual android.intent.action.-
Our experience indicates most capability leaks we de- CALL PRIVILEGED Intent, which will be broadcasted
tected are of this form. For example, the explicit leak when the user clicks on the contact. From the disassem-
of CALL PHONE capability in Samsung Epic 4G involves bled code, the addCallAndContactMenuItems()
passing a component a “technical assistance” phone num- method also registers an ContactDetailMessage-
ber, which it calls after considerable processing. Simi- Activity2$MsgListMenuClickListener object
larly, all the tested HTC phones export the RECORD AUDIO as a callback for the click-able contact. This object’s
permission, which allows any untrusted app to specify onMenuItemClick(MenuItem) method is then
which file to write recorded audio to without asking for the called, which takes the Intent associated with the contact
RECORD AUDIO permission. and calls com.android.internal.telephony-
ITelephony.dialWithoutDelay(Intent) with
4.2.3 Implicit Capability Leaks it, which immediately dials a phone number.
Note that this implicit capability leak traversed a num-
Explicit leaks seriously undermine the permission-based
ber of callbacks that either require user intervention or are
security model of Android. Implicit leaks from an-
very visible to the user. These callbacks would normally not
other perspective misrepresent the capability requested by
be considered useful for an explicit capability leak, which
an app. In the following, we choose one representa-
assumes a malicious caller. However, as implicit capabil-
tive implicit leak and explain in more detail. Specif-
ity leaks assume that the app itself may be malicious, our
ically, the HTC Wildfire S has a built-in MessageTab
algorithm simply reports them by not making such value
app, com.android.MessageTab, which uses the
judgments when considering possible execution paths.
CALL PRIVILEGED capability (marked as 1 in Table 3)
without declaring it in its manifest. This MessageTab app 4.3 Performance Measurement
is intended to manage the phone’s SMS messages, allow-
ing the user to review sent messages and send new ones. Next, we evaluate the performance of our prototype, in
For the sake of convenience, this app links messages sent terms of both the effectiveness of its path pruning algorithm
to contacts with the appropriate contact information, al- and the amount of time it takes to process a smartphone’s
lowing the user to dial contacts directly through a “con- system image.
tact details” screen. However, this app does not declare the To measure how well Woodpecker’s path pruning
correct permissions to call phone numbers, as it only re- algorithm eliminates infeasible paths, we consider its
quests SMS-related permissions: neither the CALL PHONE output from the experiments with a single permission,
nor CALL PRIVILEGED permission occur in its mani- android.permission.SEND SMS. In particular, we
fest. On the other hand, MessageTab does declare a run only the possible-paths portion of the algorithm (i.e.,
sharedUserId attribute: “android.uid.shared.” with no pruning) and identify how many paths may possi-
This user identifier is used by a number of core Android bly leak a dangerous capability. Our results show that for
apps, including com.android.htcdialer – which has each phone, Woodpecker will report more than 8K possible
both phone-dialing permissions. paths. This surprisingly large number is due to the conser-
When analyzing this app, Woodpecker reports an vative approach we have taken in resolving an ambiguous
implicit leak in the com.android.MessageTab.- reference to assignable classes. Fortunately, our re-run of
ContactDetailMessageActivity2 activity com- the full system by pruning the infeasible paths immediately
ponent. Specifically, this component has a onResume() brings the number to the single digits. Specifically, our sys-
method – an entry point called when the activity is dis- tem only reports capability leaks in the HTC phones, espe-
played on the screen. In this case, it is used to instruct on cially 2, 3, 2 for the HTC Legend, EVO 4G, and Wildfire
how to build a list of contacts to display on the screen, by S respectively. Among the reported leaks, we then manu-
calling com.htc.widget.HtcListView.setOn- ally verify the correctness of the pruned paths. The results
CreateContextMenuListener() with a callback show they are all valid with no false positives. Note that the
object (ContactDetailMessageActivity2$3). presence of one single path is sufficient to leak the related
When the user long-presses one of these contacts, that capability. We do not measure false negatives due to the
callback object’s onCreateContextMenu() method lack of ground truth in the tested phone images. However,
is called. This method then calls ContactDetail- because of the conservative approach we have been taking
MessageActivity2.addCallAndContactMenu- in our prototype, we are confident in its low false negatives.
Items() to make the contacts’ context menus. A call to a For the processing time, we measure them directly by
helper method, android.mms.ui.MessageUtils.- running our system multiple times over the tested smart-
getMakeCallDirectlyIntent(), builds the phone images. We analyze each image ten times on an
12. can be encoded in either the app’s manifest or code, which
Table 4. Processing time of examined smart- indicates that the permission model cannot be considered
phone images type-safe. Accordingly, conventional Java source code anal-
ysis tools are not aware of the impact permissions have on
Vendor Model Processing Time # Apps program execution.
Legend 3366.63s 125
Woodpecker represents our first step towards such a val-
HTC EVO 4G 4175.03s 160
idator tool for capability leak detection. Though it has iden-
Wildfire S 3894.37s 144
tified serious capability leaks in current Android phones, it
Droid 2138.38s 76
Motorola still has a number of limitations that need to be addressed.
Droid X 3311.94s 161
For example, other than tightening the underlying imple-
Samsung Epic 4G 3732.56s 138
mentation and incorporating latest development of accurate,
Nexus One 2059.47s 76 scalable points-to analysis [8, 34, 35], our current proto-
Google
Nexus S 1815.71s 72 type now handles only Dalvik bytecode and needs to be
extended to accommodate native code. In doing so, the
issue of dynamically loaded code would be raised, which
AMD Athlon 64 X2 5200+ machine with 2GB of memory
is a limitation for purely static approaches. Also, our cur-
and a Hitachi HDP72502 7200 rpm hard drive. The mean of
rent prototype only handles 13 permissions that are defined
these results are summarized in Table 4. Each phone image
by the framework itself. However, many more exist, and
took at most a little over an hour to process. We believe the
apps are free to define new ones. Extending the system to
average time (∼ 51.0 minutes) per image to be reasonable
handle more predefined permissions is expected to produce
given the offline nature of our tool, which has not yet been
much the same results, but adding support for app-defined
optimized for speed.
permissions would lead to another class of capability leaks:
chained capability leaks. To illustrate, consider three apps:
5 Discussion A, B, and C. C has the CALL PHONE capability, which it
Our system has so far uncovered a number of serious safely exposes to B by defining a new MY CALL PHONE
capability leaks in current smartphones from leading man- permission. This new permission is acquired by B. For a
ufacturers. Given this, it is important to examine possible chained leak to occur, B opens up the new permission un-
root causes and explore future defenses. safely to A. As a result, there is a call chain A→B→C, which
First of all, capability leaks essentially reflect the classic could leak the CALL PHONE capability. Since the new per-
confused deputy attack [21] where one app is tricked by an- mission MY CALL PHONE can be arbitrary and specific to
other into improperly exercising its privileges. Though one a particular implementation, we need to explore innovative
may easily blame the manufacturers for developing and/or ways to extend our prototype to accommodate such chained
including these vulnerable apps on the phone firmware, capability leaks.
there is no need to exaggerate their negligence. Specifi- Finally, our study only examines capability leaks among
cally, the permission-based security model in Android is a pre-loaded apps in the phone firmware. We also expect the
capability model that can be enhanced to mitigate these ca- leaks could occur among third-party user apps. Note that
pability leaks. One challenge however is to maintain the phone images are relatively homogeneous and static with
integrity of those capabilities when they are being shared usually a somewhat infrequent update schedule. Capability
or opened to other unrelated apps. In other words, ei- leaks, especially explicit ones, on phone images are of great
ther the capability-leaking app needs to ensure that it will interest to malicious third parties. Implicit leaks, on the
not accidently expose its capability without checking the other hand, appear to be relatively rare, which we assume
calling app’s permission, or the underlying Android frame- are more software engineering defects than a real security
work needs to diligently mediate app interactions so that threat. However, for third-party apps, implicit leaks could
they do not inappropriately violate the integrity of a ca- constitute collusion attacks that directly undermine the app
pability. However, such inter-app interactions are usually market model. Specifically, app markets do not report the
application-specific, so it is hard for the Android framework actual permissions granted to an app. Instead they report
to infer the associated semantics. only the permissions an app requests or embodied in the
Second, to avoid unsafely exposing capabilities, we can manifest file. As a result, a cohort of seemingly innocuous
also develop a validator tool and release it together with the apps could conspire together to perform malicious activities
Android SDK. Note that such a validator tool needs to han- and the user may not be informed of the true scope of their
dle the various ways an app can interact with the Android permissions within the system. Meanwhile, we hypothesize
permission model. Specifically, Android uses string identi- that explicit leaks in user-installed apps may be less com-
fiers to represent permissions, and permission information mon and useful, as an app must have both a sizable installed
13. base and unwittingly expose some interesting functionality source code for the analysis, which is not available in our
in order for an attacker to derive much benefit from exploit- case for capability leak detection.
ing the leaked capabilities. In future work, we plan to apply Felt et al. [19] propose the notion of permission re-
Woodpecker to assess the threat posed by capability leaks delegation in the generalized contexts applicable for both
in user apps. web and smartphone apps. Our work is different from it
in three key aspects. First, permission re-delegation is re-
6 Related Work lated to the explicit capability leak, but not implicit capa-
Smartphones have recently attracted considerable at- bility leak (that does not make use of any public interface
tention, especially in the context of privacy. Accord- for permission inheritance). Second, in order to identify ca-
ingly, much work has been devoted to analyzing smart- pability leaks, our system needs to address both object in-
phone apps, either statically or dynamically. For exam- heritance and control-flow discontinuity through callbacks,
ple, TaintDroid [14] applies dynamic taint analysis to mon- which are not being handled in [19]. Third, we apply our
itor information-stealing Android apps. Specifically, by ex- system in stock smartphone images rather than third-party
plicitly modeling the flow of sensitive information through apps, which reflect the difference of focus on Android per-
Android, TaintDroid raises alerts when any private data missions (such as systemOrSignature permissions) as
is going to be transmitted from the device. A follow-up well as the evaluation results (Table 3). Another related
work [15] developed a Dalvik decompiler ded to statically work, Stowaway [17], is designed to detect overprivilege
uncover Java code from the Dalvik bytecode of popular free in Android apps, where an app requests more permissions
Android apps. The uncovered Java code is then fed into ex- than it needs to function. The implicit capability leak de-
isting static analysis tools to understand or profile the app’s tection in Woodpecker instead focuses on underprivilege in
behavior. DroidRanger [41] uses both static and dynamic Android apps, which pose a more direct threat to security
analysis techniques to develop behavior profiles for scalable and privacy.
malware detection, with a focus on scanning large numbers On the defensive side, TISSA [42] argues for a pri-
of third-party apps (i.e., a whole market) for malicious be- vacy mode in Android to tame information-stealing apps.
havior. DroidMOSS [40] detects repackages apps in third- AppFence [23] couples such a privacy mode with taint
party Android marketplaces. Woodpecker is different from tracking to allow for expressive policies. Kirin [16] at-
these efforts with its unique focus on statically analyzing tempts to block the installation of apps that request certain
pre-loaded apps in smartphone firmware to uncover possi- combinations of permissions with deleterious emergent ef-
ble capability leaks. fects. A development of that system, Saint [30], empow-
From another perspective, researchers have also devel- ers the app developer to specify additional constraints on
oped static analysis tools for privacy leak detection. For the assignment of permissions at install-time and their use
example, PiOS [13] is a representative example, which at runtime. Apex [28] modifies the permission framework
constructs a control-flow graph for an iOS app and then to allow for selectively granting permissions and revoking
looks for the presence of information-leaking execution permissions at runtime. MockDroid [7] allows privacy-
through that graph. Specifically, PiOS tries to link sources sensitive calls to be rewritten to return “failure” results. In
of private information to network interfaces. In compari- the .NET framework, Security by Contract [11] allows an
son, Woodpecker was developed for the Android platform application’s behavior to be constrained at runtime by a con-
and thus needs to overcome platform-level peculiarities for tract. Such contract-based systems might represent a de-
the control-flow construction and data flow analysis (e.g., fense against implicit capability leaks, though none of these
control-flow discontinuities in Section 2). Most impor- share the same goal of exposing capability leaks in smart-
tantly, Woodpecker has a different goal in uncovering un- phone firmware.
safe exposure of dangerous capability uses, including both As discussed earlier, capability leaks essentially reflect
explicit and implicit ones. In particular, implicit leaks do the confused deputy attack [21]. Other researchers also
not make use of any public interfaces to “inherit” the per- warn of similar attacks in Android [10, 12, 29]. For exam-
missions. In the same vein, work by Chaudhuri et al. [9, 20] ple, Davi et al. [10] show a manually-constructed confused
formalizes data flow on Android so that a data flow pol- deputy attack against the Android Scripting Environment.
icy can be formally specified for an Android app, which QUIRE [12] allows apps to reason about the call-chain and
can then be checked against the app code to ensure compli- data provenance of requests, which could be potentially
ance. A SCanDroid system [20] has been accordingly de- helpful in mitigating this attack. Nils [29] manually ana-
veloped to extract such specifications from the app’s mani- lyzed the HTC Legend’s system image looking for possible
fests that accompany such applications, and check whether permission abuses. The problem is certainly not unique to
data flows through the app are consistent with the specifica- the Android platform; for example, in 1999, Smith found
tion. Note that SCanDroid requires accessing the app’s Java that PC manufacturers bundled vulnerable ActiveX controls
14. in their custom Windows installations [33]. In comparison was supported in part by the US Army Research Office
to these previous efforts, our work aims to systematically (ARO) under grant W911NF-08-1-0105 managed by NCSU
detect such capability leaks. More importantly, by address- Secure Open Systems Initiative (SOSI) and the US Na-
ing the challenges for possible path identification (Section tional Science Foundation (NSF) under Grants 0855297,
2.1.1) and feasible path refinement (Section 2.1.2), our sys- 0855036, 0910767, and 0952640. Any opinions, findings,
tem automates the majority of necessary tasks to explore and conclusions or recommendations expressed in this ma-
and discover potential capability leaks. In fact, the only terial are those of the authors and do not necessarily reflect
manual effort comes from the need to verify the detected the views of the ARO and the NSF.
leaks. Meanwhile, note that some Android malware such
as Soundcomber [31] were developed by requesting cer- References
tain Android permissions. Our research shows that these
requests could be potentially avoided as the permissions [1] Android Debug Bridge. http://developer.
might have already been leaked (e.g., RECORD AUDIO). android.com/guide/developing/tools/adb.
More generally, a number of systems that target desktop html.
apps have been developed to detect system-wide informa- [2] Apple App Store. http://www.apple.com/iphone/
tion flow or confine untrusted app behavior. For example, apps-for-iphone/.
TightLip [38] treats a target process as a black box. When [3] IPhone Stored Location in Test Even if Dis-
abled. http://online.wsj.com/article/
the target process accesses sensitive data, TightLip instanti-
SB10001424052748704123204576283580249161342.
ates a sandboxed copy, gives fuzzed data to the sandboxed html.
copy and runs the copy in parallel with the target for output [4] Soot: a Java Optimization Framework. http://www.
comparison and leak detection. Privacy Oracle [26] applies sable.mcgill.ca/soot.
a differential testing technique to detect the correlation or [5] T.J. Watson Libraries for Analysis (WALA). http://
likely leaks between input perturbations and output pertur- wala.sourceforge.net.
[6] Vulnerability in HTC Peep: Twitter Credentials Disclo-
bations of the application. Also, system-level approaches
sure. http://seclists.org/fulldisclosure/
such as Asbestos [36], HiStar [39], Process Coloring [25], 2011/Feb/49.
and PRECIP [37] instantiate information flow at the process [7] A. R. Beresford, A. Rice, N. Skehin, and R. Sohan. Mock-
level by labeling running processes and propagating those Droid: Trading Privacy for Application Functionality on
labels based on process behavior. While we expect some of Smartphones. In Proceedings of the Twelfth Workshop on
these approaches will be applicable on resource-constrained Mobile Computing Systems Applications, HotMobile ’11,
mobile phone environments, they are more focused on de- May 2011.
[8] M. Carbone, W. Cui, L. Lu, W. Lee, M. Peinado, and
tecting information leaks instead of capability leaks (and
X. Jiang. Mapping Kernel Objects to Enable Systematic In-
their applicability to the smartphone setting still remains to
tegrity Checking. In Proceedings of the 16th ACM Confer-
be demonstrated). ence on Computer and Communications Security, CCS ’09,
November 2009.
7 Conclusions [9] A. Chaudhuri. Language-Based Security on Android. In Pro-
ceedings of the 4th ACM SIGPLAN Workshop on Program-
ming Languages and Analysis for Security, February 2009.
In this paper, we present a system called Woodpecker [10] L. Davi, A. Dmitrienko, A.-R. Sadeghi, and M. Winandy.
to examine how the Android-essential permission-based se- Privilege Escalation Attacks on Android. In Proceedings of
curity model is enforced on current leading Android-based the 3rd Information Security Conference, October 2010.
smartphones. In particular, Woodpecker employs inter- [11] L. Desmet, W. Joosen, F. Massacci, P. Philippaerts,
F. Piessens, I. Siahaan, and D. Vanoverberghe. Security-by-
procedural data flow analysis techniques to systematically
contract on the .NET platform. Information Security Techni-
expose possible capability leaks where an untrusted app can
cal Report, 13:25–32, January 2008.
obtain unauthorized access to sensitive data or privileged [12] M. Dietz, S. Shekhar, Y. Pisetsky, A. Shu, and D. S. Wallach.
actions. The results are worrisome: among the 13 privileged QUIRE: Lightweight Provenance for Smart Phone Operating
permissions examined so far, 11 were leaked, with individ- Systems. In Proceedings of the 20th USENIX Security Sym-
ual phones leaking up to eight permissions. These leaked posium, USENIX Security ’11, August 2011.
capabilities can be exploited to wipe out the user data, send [13] M. Egele, C. Kruegel, E. Kirda, and G. Vigna. PiOS: De-
out SMS messages (e.g., to premium numbers), record user tecting Privacy Leaks in iOS Applications. In Proceedings
of the 18th Annual Network and Distributed System Security
conversation, or obtain the user’s geo-location data on the
Symposium, NDSS ’11, February 2011.
affected phones – all without asking for any permission. [14] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. Mc-
Acknowledgements The authors would like to thank Daniel, and A. N. Sheth. TaintDroid: An Information-Flow
the anonymous reviewers for their insightful comments that Tracking System for Realtime Privacy Monitoring on Smart-
helped improve the presentation of this paper. This work phones. In Proceedings of the 9th USENIX Symposium on