Once gathered, it is possible to use adb to either start the component or craft an intent that performs the hacker’s desired action. Malicious actors can manually search reverse engineered applications or use command-line tools such as drozer or slicer to scan for vulnerable exported components. The main reason mismanaged exporting is so dangerous is due to how trivial it is to find these vulnerabilities in an app and target them. These incorrectly defined app components pose a huge security risk as they become directly accessible and thus can be potentially exploited. In my experience, it is not uncommon to see app components inadvertently marked as ‘exportable’ when, in fact, they should not be. However, something that might not be obvious to beginners is by specifying an intent filter, the component is marked to the system as exportable even if android:exported=true is not explicitly defined within the manifest. For example, passing the system an implicit intent to show apps that can handle the URL might offer a list of installed web browsers. Through this definition, another app can use an 'implicit intent' ³ to ask the system to show your app as being compatible when offering a specific intent.
Marking a component with this flag allows for an 'explicit intent’ ² to be sent by any other application (or the system) to perform the specified action that can be handled by the receiving component.Īdditionally, components can also define blocks within the manifest to specify the types of intents that the activity, service, or broadcast receiver can respond to. To allow for communication between applications, the app component(s) that we wish to be able to receive an Intent must be marked as android:exported=true within the AndroidManifest.xml file. However, the Android framework also allows for other apps to send and receive Intent instances between them, with the intended purpose of facilitating 'communication' between applications.
The Intent class provides an easy way of parcelling data and passing it to separate app components and is the most common way to achieve this with the framework. That action could be in the form of navigating to a new screen within your app, running a background/foreground service or registering a broadcast receiver to get regular updates from some source.
For those that are new to Android, the platform uses the Intent class as a way of starting an action of some kind. Please excuse the terrible pun, the first common example of misuse of the Android platform comes within the definition of an Intent. Mistakes inevitably happen, but it is my hope that by introducing some of the most common security issues we accidentally write into our code, you will think twice before making the same mistake yourself and save yourself from a potential security disaster. Nobody can be expected to know the entire platform inside out, nor are developers infallible. What do I mean by that hyperbolic statement? Well, it’s usually a developer’s unintentional misuse, negligence or a simple misunderstanding of the Android platform that leads to our most serious security issues. However, what this title is trying to subtly say is the main threat to the security of our mobile apps is actually us. On the face of it, Improper Platform Usage seems a somewhat vague statement for something that is supposed to be the burning issue in mobile application security. In this first part of my series on Android Security, we shall take a look into the #1 threat to Mobile application security as determined by OWASP, which they outline as being Improper Platform Usage. Remember to only test on apps where you have permission to do so and most of all, don’t be evil.įinally, if you enjoy this series or have any feedback, please drop me a message. Please note that this series is for educational purposes only. A companion app that demonstrates the issues outlined in the talk is also freely available for download. Please do check my talks page for more details and relevant links. These posts are also supplementary to my January 2022 talk ‘Don’t get stung by OWASP - An intro into writing code for greater Android Security’ in which I discuss the Top 5 issues in more detail. Whilst these posts focus on the Android platform, many of the ideas and sentiments behind them are totally platform agnostic, as is the OWASP Top 10 list itself. This series will primarily focus on the Top 10 Mobile security threats as determined by The Open Web Application Security Project (OWASP) Foundation, the leading application security community in our field. 👋 Hi and welcome to a new series of blog posts in which we shall deep-dive into Android Security.
0 kommentar(er)
