Estimated difficulty: 💜💜💜💜🤍
Welcome back to the MOBster series!
The last post I published, covered the different aspects of an APK file – otherwise known as an app. This post I want to take some of these principles a step further and look at the possible effects of a misconfigured app! Following the guidelines of the OWASP (Open Web Application Security Project) Mobile Top 10 2016, I’m going to write about M1: Improper Platform Usage, and walk you through how the exploit is working given the application is vulnerable to this.
What in the APK is it?
Improper platform usage is where an app or the server-side aspect of the app intentionally or unintentionally ignores security best practices for the mobile platform (Android, iOS, Windows, etc) that the app is running on. Security standards can differ for each platform. There are different ways that your application might fall into this category:
The application fails to implement the security controls or features recommended by the manufacturer or the app is inadvertently incompatible upon implementation. Some security controls include:
- Intents
- Permissions
- TouchID – iOS allows developers to implement this.
- Keychain
Common security best practices when developing an app may be left out/ not implemented into the functionality of the application.
- Generally, insecure coding fits this category.
According to the OWASP Mobile Top 10 itself, the vulnerability exposed through the design or failed implementation of security controls can be exploited when a service or an application programming interface (API) call used by the application is exposed.
There are several services and factors, such as the back end of the application and the actual misconfiguration itself. We need to consider and find out what the misconfiguration is to discover what vulnerabilities might be present in the application. There isn’t just one vulnerability defined for improper platform usage, as it can be a combination of things. To help simplify this post I have selected a real-life case study to help explain what improper platform usage can be, before walking through how to exploit the vulnerability ourselves.
How it works
To break this down further it would help us to understand how an app may talk to an API or what kind of services it could use.
Mobile API
It is likely that the application running on your mobile device has internet connectivity. These days everything is connected! I don’t know about you, but I choose my apps because they serve a purpose to me. For example; the TrainLine app. When I search for train times, prices and other information I am querying the mobile backend or server with that data through an API. An API stands for Application Programming Interface and is something that can take an input or request, talk to the backend and then return the data you requested. Multiple APIs may be used. If this service is exposed then an assailant (much like ourselves when we have our white hats on) may gain unauthorised access to the data stored in the backend database.
Mobile Service
This is the same as what I mentioned in my last post. A service runs in the background and can be kicked off by an activity. These activities could be something the user has pressed or interacted within the application. This service could be anything such as a LocationSharingService or any others, like the ones shown in the example below:
See my last blog post for more details!
Case Study
Now we know how the application is vulnerable and how it might be exploited, let’s take a look at a real-world example! As mentioned previously, your application may be subject to the improper platform usage vulnerability for many different reasons. One of these reasons is the failure to properly implement the TouchID security controls within an application. Since iOS allows developers to implement this feature, not all apps quite get this right.
Wired produced a post pointing out a scam that was going around where certain apps acting as calorie trackers or fitness apps would prompt you to scan your fingerprint when this would actually instead authenticate a purchase. This violates the Apple App store guidelines and constitutes improper platform usage. This is seemingly intentional, however other mistakes in the implementation of Touch ID have also been found, such as users being able to bypass the authentication completely.
Try it yourself!
Now we have more of an idea of what improper platform usage actually is, we can try to find some of these vulnerabilities in our own vulnerable application! It can be a little dry just reading about these vulnerabilities, so I am glad you are still with me. Let’s get stuck in! I am using a Kali Linux virtual machine to carry out these steps.
1. First things first, we need to download a deliberately vulnerable application. There are plenty of apps that have been developed for us to practice finding these kinds of vulnerabilities. To find mine I went delved deep into pentesterland… I cloned down my vulnerable application from this Git repository, called Android-InsecureBankv2. This application is open to a whole host of vulnerabilities waiting for us to find and exploit.
2. Now we have our vulnerable application we want to focus on finding its vulnerabilities. You can use tools such as apktool to automatically reverse the application.
sudo apktool d -o InsecureApp InsecureBankv2.apk
The above command runs the apktool and specifies d for decoding and -o to specify the name of the directory where the output will be kept. I have used the name InsecureApp. Finally, we just specify the app that we would like to analyse.
3. We want to understand how this app is working so we can open up the AndroidManifest.xml file to view what the components might be in the application. These components can be defined as activities, services, a receiver or a provider. I’ve selected the components found in the app and pasted them below.
activity android:exported="true" android:label="@string/title_activity_post_login" android:name="com.android.insecurebankv2.PostLogin"/>The app shows an activity with the following features:
| android:exported=”true” | This means that the activity can be launched by components of other applications. |
| android:label=”title_activity_post_login” | A user-readable label for the activity. |
| android:name”com.android.insecurebankv2.PostLogin” | The name of the class that implements the activity. |
The most important part to note here is that the activity is set to public or properly known as “true”.
4. We have found our first vulnerability! All of the components defined in this vulnerable application have been set to true. This comes under insecure coding, as the Android Security Best Practices Guide states that we need to enforce secure communication between the different applications.
This application is vulnerable to attacking/malicious applications that have been created to receive broadcasts or implicit intents from any other generic applications. Any activity happening on our Android-InsecureBankv2 application, such as viewing a statement or logging in, may be captured by the malicious app.
It is not a crime to allow data to be shared between applications, however permissions should be set to only allow authorised applications to access the data. No further restrictions have been set to any of the components, so access should be restricted by setting signature-based permissions, where the other application (if authorised) trying to call the data can successfully access it with the same signing key.
5. One step further would be to exploit the improper platform usage vulnerability found within this deliberately vulnerable application. Tools such as Drozer and Qark can be useful to exploit this. Go on get your hackerman on. 😉
6. Try to find some of the other vulnerabilities of this app yourself.
This post I wanted to focus on M1 Improper Platform Usage, however, next post I plan to focus on M2 Insecure Data Storage. I will use the same setup and application to show how an app could insecurely store data.
What did we learn?
To recap, we have covered what improper platform usage is and two of the different ways that an application can be vulnerable. For the first vulnerability we looked at how improper implementation of the security control, such as the TouchID can be bypassed or exploited by looking at case studies. Secondly, we performed basic static analysis on the application by reverse engineering it using the apktool. This analysis allowed us to find the vulnerability of exposed activities and components of the app, where malicious applications target these exposed components.
Thank you for taking the time to read this post, let me know if you enjoyed this post and the type of content!
Happy Friday!
Sarah <3
