<commit_before>\documentclass[12pt,a4paper]{article}
\usepackage{verbatim}
\usepackage{listings}
\usepackage{hyperref}
\usepackage{url}
\usepackage{caption}
\usepackage{fullpage}
\captionsetup{font=small,justification=centering}

\begin{comment} Write a document describing the design and implementation of
your project, and turn it in along with your project's code by the final
deadline.  \end{comment}

\title{Exploiting common \texttt{Intent} vulnerabilities in Android %
applications}
\date{\today}
\author{<NAME>, \texttt{kcasteel}\\ <NAME>, \texttt{oderby}\\ <NAME>,
\texttt{dennisw}}

\begin{document} \bibliographystyle{plain}

\maketitle

\paragraph{Problem} ~\\

The Android framework allows apps and components within apps to communicate with
one another by passing messages, called
\href{https://developer.android.com/reference/android/content/Intent.html}{Intents},
which specify both a procedure to call and the arguments to use. Applications
must declare in a static manifest file which intents each component services, as
well as both application and component level permissions. While the security
vulnerabilities in outgoing Intents has been well studied
\cite{chin_analyzing_2011} and developer tools exist to limit potentially
insecure Intents, little has been done to address malicious incoming Intents.
Exploits of this nature have been discovered in firmware of various Android
phones \cite{grace_systematic_2012}, but exploits in third-party applications
are not well studied. Application developers must make sure their manifest file
has been properly configured to only accept desired Intents, which can limit
usability. We believe that developers will trust Intent input by default,
allowing malicious input to potentially crash or abuse the application.

\paragraph{Gathering apps for analysis} ~\\

We downloaded 382 applications as application package files (``apk'' for short)
files using Real Apk Leecher \cite{apkleecher}, a utility we found online. This
connects to Google Play to get applications, so all results were verified
applications in the Android market. Various keywords for potential interesting
attack vectors, such as 'camera,' 'contacts,' 'sms,' and more were used to
search for applications. The free applications from the top 60 search results,
sorted by application popularity, for each keyword were downloaded for analysis.
This ensured that the applications were popular and currently used applications;
the attacker could be fairly certain that some were already downloaded by a
potential victim.

\paragraph{Static analysis} ~\\

To start, we implemented a basic static analysis tool to aid us in identifying
potential vulnerabilities in Android applications. The tool, which is similar to
the one built by Grace, et al. \cite{grace_systematic_2012} traces through the
control flow graph of the apps to see if there are paths between publicly
accessible methods and permission uses. We built our tool using
Androguard \cite{androguard}, a python FOS library written ``to play with''
Android applications. Our tool implements the component analysis strategy from
\cite{chin_analyzing_2011} (see section 4.3) to detect public components and
then uses a control flow graph to determine which public components lead to
privileged calls, which represent potential vulnerabilities to privilege
escalation via intent spoofing attacks. Our tool operates on raw Android apks,
the compiled archives of all code required to load and run the application. We
use the apk files in order to analyze both open- and non-open-source
application.

First, we extract the manifest file from the apk and compile a list of ``open''
components: public components, protected by weak or no permissions which are
exported by the app. A component is public if the manifest specifies an intent
filter for it. However, components can override this behavior by setting the
``exported'' attribute to \texttt{false}. Next, we check for any permissions
protecting the component. Developers can also set the ``permission'' attribute
to require a certain permission to access each component, so we only reported
public, exported components which had permissions of level dangerous or normal.

After determining all open components, we need to identify all privileged calls
made by the application. A privileged call is a method call which the Android OS
requires the calling application to hold a permission in order to execute
the call. The mapping from method calls to required permissions is
derived from work in \cite{felt_android_2011}. Using this mapping and the
decompiled source code in the apk, we search for privileged calls with
permission levels of dangerous or signature.

Finally, we construct a control flow graph of the application and search for any
paths of execution leading from an open component to a privileged call. We
report any such path found as a potential vulnerability in the analyzed
application. These paths represent possible vulnerabilities because they allow
an unprivileged application to cause execution of privileged methods via an
intent.

Discuss how we can't find all vulnerabilities, and may vulnerabilities we find
don't lead to real vulnerabilities in practice.

\paragraph{Findings of analysis} ~\\

The permissions most commonly leaked were mostly the permissions most commonly
declared in manifest files. Either INTERNET, READ\_PHONE\_STATE, or
ACCESS\_FINE\_LOCATION were leaked in 113 of 383 applications. While exploits
are possible based on these permissions, the more active permissions, such as
CAMERA or SEND\_SMS, were much less frequently exposed. The correlation between
exposed permissions and common ones, seen below as the percent of vulnerable
permissions to declared ones, suggests that developers don't consider the
security risks of the common permissions. Users are also probably more willing
to simply allow an app to have these permissions.
\begin{table}
\caption{Permission use and leakage}
\input{stats}
\caption*{Android permissions leaked in the analyzed applicatons. Use indicates
  the number of applications that declared the permission in their
  manifest, and Vulnerabilites indicates the number of applications that
  exposed the permission.  Permissions that were declared but not exposed
  are not shown. Signature or system permissions are in bold, all others
  are danerous.}
\end{table}
None of the apps leaked sensitive information (couldn't retrieve any data with<commit_msg>more static analysis text...need to wrap it up still.<commit_after>\documentclass[12pt,a4paper]{article}
\usepackage{verbatim}
\usepackage{listings}
\usepackage{hyperref}
\usepackage{url}
\usepackage{caption}
\usepackage{fullpage}
\captionsetup{font=small,justification=centering}

\begin{comment} Write a document describing the design and implementation of
your project, and turn it in along with your project's code by the final
deadline.  \end{comment}

\title{Exploiting common \texttt{Intent} vulnerabilities in Android %
applications}
\date{\today}
\author{<NAME>, \texttt{kcasteel}\\ <NAME>, \texttt{oderby}\\ <NAME>,
\texttt{dennisw}}

\begin{document} \bibliographystyle{plain}

\maketitle

\paragraph{Problem} ~\\

The Android framework allows apps and components within apps to communicate with
one another by passing messages, called
\href{https://developer.android.com/reference/android/content/Intent.html}{Intents},
which effectively specify both a procedure to call and the arguments to
use. Applications must declare in a static manifest file which intents each
component services, as well as both application and component level
permissions. While the security vulnerabilities in outgoing Intents has been
well studied \cite{chin_analyzing_2011} and developer tools exist to limit
potentially insecure Intents INSERT \cite{citation_needed!!!}, little has been
done to address malicious incoming Intents. Exploits of this nature have been
discovered in firmware of various Android phones \cite{grace_systematic_2012},
but exploits in third-party applications are not well studied. Application
developers must make sure their manifest file has been properly configured to
only accept desired Intents, which can limit usability. We believe that
developers will trust Intent input by default, allowing malicious input to
potentially crash or abuse the application.

Our work is twofold: we developed a static analysis tool to inspect third party
applications for malicious intent vulnerabilities, and we built a working
exploit which takes advantage of such a vulnerability.

\paragraph{Static analysis} ~\\

To start, we implemented a basic static analysis tool to aid us in identifying
potential vulnerabilities in Android applications. We are not the first to look
at such vulnerabilities (\cite{chin_analyzing_2011}), nor to build such a tool
(\cite{grace_systematic_2012}). However, in the absence of any freely-available
such tools, we took it as a learning opportunity to build our own (borrowing
ideas freely from the previous literature). Here, we describe the basic design
of our tool and any interesting decisions we made, but the curious reader should
reference \cite{chin_analyzing_2011} and \cite{grace_systematic_2012} for more
details.

We built our tool using Androguard \cite{androguard}, a
python FOS library written ``to play with'' Android applications. Androguard is
a library built, in part, to support creation of static analysis tools for the
Android platform - it supports disassembly and decompilation of apks into
Java-approximate source code (it doesn't recompile, but it is very nearly
complete) for human-readability, as well as intermediate basic blocks for static
analysis and control-flow graph creation. It provides basic search functionality
over the decompiled basic blocks. Despite this long list of features, a lot of
work went into understanding how to use the library (it has minimal
documentation...) and coercing it into doing what we wanted.

The tool examines execution traces through an application, looking for places
where malicious intents might cause the program to unintentionally perform
privileged actions. We implement the component analysis strategy from
\cite{chin_analyzing_2011} (see section 4.3) to detect public components. We
also identify privileged calls (\cite{felt_android_2011}) made by the
application. Then we use a control flow graph of the program to determine which
public components lead to privileged calls, which represent potential
vulnerabilities. Our tool operates on raw Android apks, the compiled archives of
all code required to load and run the application. We use the apk files in order
to analyze both open- and non-open-source application.

First, we extract the manifest file from the apk and compile a list of ``open''
components: public components, protected by weak or no permissions which are
exported by the app. A component is public if the manifest specifies an intent
filter for it. However, components can override this behavior by setting the
``exported'' attribute to \texttt{false}. Next, we check for any permissions
protecting the component. Developers can also set the ``permission'' attribute
to require a certain permission to access each component, so we only reported
public, exported components which had permissions of level dangerous or normal.

After determining all open components, we need to identify all privileged calls
made by the application. A privileged call is a method call which the Android OS
requires the calling application to hold a permission in order to execute
the call. The mapping from method calls to required permissions is
derived from work in \cite{felt_android_2011}. Using this mapping and the
decompiled source code in the apk, we search for privileged calls with
permission levels of dangerous or signature.

Finally, we construct a control flow graph of the application and search for any
paths of execution leading from an open component to a privileged call. We
report any such path found as a potential vulnerability in the analyzed
application. These paths represent possible vulnerabilities because they allow
an unprivileged application to cause execution of privileged methods via an
intent.

Discuss how we can't find all vulnerabilities, and may vulnerabilities we find
don't lead to real vulnerabilities in practice.

\paragraph{Gathering apps for analysis} ~\\

We downloaded 382 applications as application package files (``apk'' for short)
files using Real Apk Leecher \cite{apkleecher}, a utility we found online. This
connects to Google Play to get applications, so all results were verified
applications in the Android market. Various keywords for potential interesting
attack vectors, such as 'camera,' 'contacts,' 'sms,' and more were used to
search for applications. The free applications from the top 60 search results,
sorted by application popularity, for each keyword were downloaded for analysis.
This ensured that the applications were popular and currently used applications;
the attacker could be fairly certain that some were already downloaded by a
potential victim.

\paragraph{Findings of analysis} ~\\

The permissions most commonly leaked were mostly the permissions most commonly
declared in manifest files. Either INTERNET, READ\_PHONE\_STATE, or
ACCESS\_FINE\_LOCATION were leaked in 113 of 383 applications. While exploits
are possible based on these permissions, the more active permissions, such as
CAMERA or SEND\_SMS, were much less frequently exposed. The correlation between
exposed permissions and common ones, seen below as the percent of vulnerable
permissions to declared ones, suggests that developers don't consider the
security risks of the common permissions. Users are also probably more willing
to simply allow an app to have these permissions.
\begin{table}
\caption{Permission use and leakage}
\input{stats}
\caption*{Android permissions leaked in the analyzed applicatons. Use indicates
  the number of applications that declared the permission in their
  manifest, and Vulnerabilites indicates the number of applications that
  exposed the permission.  Permissions that were declared but not exposed
  are not shown. Signature or system permissions are in bold, all others
  are danerous.}
\end{table}
None of the apps leaked sensitive information (couldn't retrieve any data with
{'fraction_non_alphanumeric': 0.04482182628062361, 'fraction_numerical': 0.006124721603563474, 'mean_word_length': 5.30219298245614, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 8, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '855295', 'n_tokens_mistral': 3440, 'n_tokens_neox': 3203, 'n_words': 1963}