Top 10 Mobile App Security Risks #1 — Improper Platform Usage on Android
The first article in a series dedicated to the OWASP Mobile Top 10 — a comprehensive list of the most common and significant security risks in mobile applications. The aim of this series is to provide an in-depth description of each risk and offer practical examples that demonstrate the potential threat they pose to mobile app security. By reading this series, you will gain a better understanding of the vulnerabilities that exist in mobile app development and how to mitigate them.
This article is based on the 5th episode of my Android Talks Podcast. In this podcast, I delve into the first risk from the list M1: Improper Platform Usage. The podcast is conducted in Polish, so if you are a Polish speaker and would like to listen, you can access it here 👇
Intro
Security is one of the most important aspects of any app or system. Unfortunately, it is often overlooked in many companies and projects. This is especially evident in start-ups and smaller companies, where knowledge is often lacking and security issues are neglected until customers experience the first hacker attacks.
1) How does one ensure mobile app security? 🔐
2) How do you know what to protect against and how to do it? 🤔
3) How do we test applications in terms of security? 👨💻
If you don’t know the answers to these questions, or you’re just curious about this topic, you’ve come to the right place. This article starts a series dedicated to mobile app security. As part of this series, I will discuss the most significant security risks, weaknesses, and vulnerabilities of mobile apps. I will present the methods of testing them and the requirements that an app must meet in order to be considered “safe”.
This article is also the first one of the OWASP Mobile Top 10 series, which is a list of the ten most common and critical security risks in mobile applications. This series aims to describe all the risks and show examples that illustrate how big a threat they pose to application security.
Are you ready to dive into mobile app security? So let’s get started 🚀
What is OWASP?
First, let’s start with what OWASP is all about.
OWASP, or Open Worldwide (formerly Web) Application Security Project is a nonprofit foundation that works to improve the security of software. Through community-led open-source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is the source for developers and technologists to secure the web.
One of these projects is OWASP Mobile Top 10.
What are OWASP’s Top 10 lists exactly?
What are OWASP’s Top 10 lists? The Top 10 lists are probably one of the most famous OWASP projects. Each Top 10 list is a standard awareness document for developers and application security. They represent a broad consensus about the most critical security risks.
OWASP has published several such lists, among them:
- OWASP Top 10 (Web)
- OWASP Top 10 API
- OWASP Top 10 CI/CD
- OWASP Top 10 Serverless
- OWASP Mobile Top 10
Of course, we, mobile app developers, are most interested in the last one 📱
OWASP Mobile Top 10
The first version of OWASP Mobile Top 10 was released in 2014, while the second, and at the same time the latest, two years later. On the website, we can also find a presentation and a video clip about the list from 2011. This list has been marked as release candidate 1.0 and is currently archived, but it’s still worth checking out to see what changes have been made over the years.
Interestingly, OWASP recently (March 2023) announced on their website the start of work on updating the list in 2023. There is also a link to Slack, so everyone can contribute to the research that is currently being conducted. In this series, I will be discussing the most recent list available, which is the one from 2016. However, if a new version is released, I will definitely publish an article explaining all updates 🧐
Some of you may be asking yourself right now
What, so this list changes over time?
That’s right!
The list changes as some problems disappear and others appear. This can be seen particularly well in the (Web) OWASP Top 10 list, which had its first release in 2003, and the latest — seventh in 2021. At first glance, you might think that the Mobile Top 10 list is a bit neglected because the web version has as many as 7 versions, and the mobile one only two. Don’t worry, this is mainly due to the differences between web and mobile apps. Keep in that the first ones are run in the browser, which can easily verify the host or certificate, and the second ones are installed directly on devices and will do the same, and much more, but only if the developer takes care of it! The tech stack used to create the first and second ones is also different, changes over time, and has its limitations. So, it should be understandable for us that the lists will change, but at a different pace, and will cover different critical security risks.
What is in the current Mobile Top 10 list of 2016?
It looks as follows:
- M1: Improper Platform Usage
- M2: Insecure Data Storage
- M3: Insecure Communication
- M4: Insecure Authentication
- M5: Insufficient Cryptography
- M6: Insecure Authorization
- M7: Poor Code Quality
- M8: Code Tampering
- M9: Reverse Engineering
- M10: Extraneous Functionality
This article will focus on the first security risk — M1: Improper Platform Usage.
How safe and secure are mobile apps today?
Before proceeding to the main part of this article, I think it would be worth checking how safe or dangerous are the applications that are currently in stores. Of course, there is no website where we can give the name of the application and find out if it is safe or not, preferably by listing all its vulnerabilities (😂), but there are certainly some statistics available, based on, for example, automatic tests that will tell us something at least.
There are several companies that keep such statistics. One of them is NowSecure. NowSecure, in a nutshell, monitors threats related to security, privacy, and weaknesses of mobile applications. According to the information on their website, so far they have conducted over 11,000 pen tests, and currently, each pen test consists of over 600 tests performed using practices such as SAST, DAST, IAST, and others.
Of course, all these tests are automatic. Unfortunately, automated tools do not make software secure and will never be 100% effective. Moreover, these types of tools are generic, so they are not tailored to a specific application. The biggest and most important security problems are rarely generic and most often result from business logic or architecture design, which means that automated tools will be able to detect only a part of vulnerabilities that can be generalized for all applications.
Nevertheless, it is worth looking at such statistics.
Click here and find out more👇
The website provides test results that break down security and privacy threats by application categories, such as social media, banking, travel, and more. In 2018, NowSecure reported that 85% of the most popular apps in stores were compromised by at least one of the OWASP Mobile Top 10 security risks, with most being affected by M2: Insecure Data Storage or M3: Insecure Communication. While the situation may have changed in the last five years, it’s likely that as a mobile app developer who has worked on multiple projects, you have encountered or are currently dealing with vulnerabilities to various types of attacks.
M1: Improper Platform Usage
Let’s dive deeper into the first security risk of the OWASP Mobile Top 10 — Improper Platform Usage. It refers to misusing the features provided by the platform or not implementing its security mechanisms correctly. It might seem quite general and vague, so let’s clarify what it is really all about.
First of all, let’s explain what Platform is. In mobile app development, the platform refers to the system on which the app is built. For native apps, the platform is either Android or iOS, while for cross-platform apps, frameworks like Flutter or React Native serve as the intermediary between the developer and the native platform. The platform provides libraries and APIs that developers can use to easily build a secure and functional app. However, issues arise when developers lack knowledge about a particular function, are unable to use the documentation, or simply make a mistake during development.
All that is covered by M1: Improper Platform Usage.
Here are some examples of such cases 👇
1) KeyStore
One of the functions of the Android platform that is used incorrectly quite often is the management of cryptographic keys and secrets, which involves the use of KeyStore and often related biometrics. In order to ensure the protection of sensitive user data and prevent unauthorized access to the application, the developer should use the AndroidKeyStore. It allows you to store cryptographic keys in a secure container and makes it much harder to extract them from the device.
The worst thing you can do, of course, is store keys, secrets, tokens, and other sensitive data in plaintext, for example by saving them to a file or to SharedPreferences. Extracting such data from the device is trivial and can lead to considerable consequences. It is also a bad idea to create cryptography from scratch, i.e. not using the cryptographic methods provided by the platform, but writing them yourself or using untested libraries found on GitHub. Such actions lead to security holes in the app.
Therefore, the absolute minimum that a programmer should use in his application when dealing with sensitive data is to use the AndroidKeyStore for cryptographic keys, and all secrets that are to be stored in a safe way should be placed at least in EncryptedSharedPreferences, to which the key is in the KeyStore. Bear in mind that I said “absolute minimum”. It’s not a perfect solution but should be enough for a lot of apps.
I mentioned biometrics earlier for a good reason, as it is also a serious concern. What’s the problem, you ask? Well, many apps request a fingerprint for authentication or login purposes, but they fail to fully utilize its potential. In other words, these apps do not actually have any real biometric security at all 🤷♂️. Unfortunately, many apps only verify if the fingerprint is correct after it has been applied.
The process often looks like this:
1) If the fingerprint is correct ⤵
2) Retrieve the previously saved refresh token from SharedPreferences ⤵
3) Log the user in and take them to the main screen of the app 🤦♂️
There are at least two problems with this approach:
- Refresh token is stored on the device, so an attacker with access to the phone has an easy job to get to it and use it until it expires
- Only the correctness of the finger is checked, without performing any cryptographic operations using the KeyStore and without verification on the Backend side.
Unfortunately, the scenario above can be found in a huge amount of mobile apps today. You must know that such a trivial finger check can be circumvented very easily by rooting the device and installing a single module with Xposed. The application will suddenly start accepting all fingers, even those not registered in the system.
How to deal with this?
When a new key is generated in the AndroidKeyStore, the developer has the option to associate it with biometrics by setting the userAuthenticationRequired flag to true. Then such a key can only be used when the user is authenticated. This gives us the guarantee that the key associated with the fingerprint will work correctly only when the correct finger is applied. The key can then be used, for example, to decrypt or sign some data so that the Backend then verifies their correctness and authorizes the user’s action.
2) Intents
Intents are another noteworthy Android platform feature when it comes to M1: Improper Platform Usage security risk. Intents are an essential feature of the Android platform, but they can also pose a security risk if not implemented correctly. In essence, an Intent is a messaging object that enables app components to request an action from other app components or even other apps on the device. Intents are commonly used to open various activities within an app, but they can also be used to select a file from the gallery, take a photo with the camera, or open a web browser. Furthermore, Intents are used to handle deep links, a feature that allows an app to be opened automatically on a specific screen when a user clicks on a link on their phone.
Let’s consider an example of an app that uses Intents, but has a vulnerability. Suppose the app opens some of its features in a WebView, which is a common practice in mobile app development, especially when a part of the system’s functionality is based on the web interface. Using WebView is also a cost-effective and flexible solution because updates to the website do not require a new version of the app to be released. However, there’s a risk involved if the app is not properly secured. The app’s Activity that hosts the WebView can be launched using an Intent, and the “url” parameter is passed to the activity, which reads it and opens the corresponding address in the WebView. Unfortunately, the WebView has been configured to allow JavaScript code to execute, and the activity has been marked as “exported” in the app Manifest, meaning that it can be accessed from outside the app. This makes the app vulnerable to a potential attacker who can inject malicious JavaScript code and exploit the app’s features.
And so an application vulnerable to the injection of a URL was created, allowing an attacker to execute any JavaScript code. This type of attack can lead to the leakage of session cookies, tokens, session data, or other confidential information.
And you know what? 🤔
The app I just described is not an example I made up, but a real situation that occurred in the “rif is fun for Reddit” application. In exactly the same way, any JavaScript code could be injected, and the user’s login data could be stolen. Moreover, the example presented is just one of the simplest attack scenarios that can be used when a programmer does not fully consider the use of Intents in their application.
If you’re curious about other applications that could be hacked with Intents and how these attacks were carried out, be sure to check out the articles below, which explain it in detail.
- Exploring intent-based Android security vulnerabilities on Google Play
- Hunting intent-based Android security vulnerabilities with Snyk Code
That’s all for Intents, and now let’s move on to the last point for today, which is improper permission management.
3) Permissions
How often do you install a new app on your phone that, right off the bat, asks you for a bunch of different permissions? Allow access to location, allow access to files, allow access to read SMS, contacts, phone status, and so on and so forth. Personally, I use a fairly simple rule. If I can’t answer the question “Why does this app require these permissions from me?” then I simply don’t use it. I care about my security and don’t want to use suspicious software on my devices. Unfortunately, not everyone is a programmer and knows a thing or two about how it works, just as not everyone reads requests for app permissions and accepts them without thinking.
Earlier, talking about intents, I showed how easily one can manipulate the application’s behavior. Going one step further, we could think of an example of an application that can not only be manipulated but also used to perform operations for which we don’t have permissions, but that application has. And again, I won’t use a made-up example here, but a situation from 2019 when a vulnerability was found in Google and Samsung Camera applications. These apps allowed other apps to take photos or record videos using the camera. The photos were saved on the SD card, and a malicious app could request access to the phone’s memory, which in itself is not very suspicious, and then send an intent to the vulnerable camera app and extract files. Furthermore, if geolocation was enabled while taking pictures, the malicious app could track the user by extracting that information from the metadata.
So, practically every request by an application for permission should be treated, both by the programmer and the user, as a risk of data access by other applications or unwanted persons. Of course, as a programmer, sometimes you have no choice. If the feature you are currently working on requires certain permissions, you have to ask for them. Just remember to always use them in a minimal, secure, and compliant manner with current practices in the documentation. An example of a lack of knowledge of the documentation is the requirement for permissions to the storage and camera when the application only wants to take a picture or select it from the gallery and save it to the internal memory in the application directory. According to the latest documentation, it is sufficient to use the Storage Access Framework or MediaStore. Unfortunately, I have already encountered many devs who did not know about this and their applications unnecessarily asked for these permissions.
Final Thoughts
The first article in the OWASP Mobile Top 10 series is coming to an end. I would like to remind you that in this article, I only discussed a few examples related to the first security risk, while in practice, as I mentioned earlier, it applies to the entire platform. This means that as a developer, you must stay up to date with the latest documentation, recommended security practices, and track the changes introduced in subsequent versions of the Android system.
New articles from the OWASP Mobile TOP 10 series will be coming soon.
Thank you for your attention! 👋
Before you go:
✉️ Android Dev Newsletter
If you enjoy learning about Android as I do and want to stay up to date with the latest, worth-reading articles, programming news, and much more, consider subscribing to my newsletter.
🎙 Android Talks Podcast
If you’re a Polish speaker and want to listen to what I have to say about Android, architecture, security, and other topics, check out my podcast.
Useful links:
- OWASP Mobile Top 10
- M1: Improper Platform Usage
- Mobile App Security and Privacy Tracker (NowSecure)
- Mobile AppSec 101 (NowSecure)
- Exploring intent-based Android security vulnerabilities on Google Play
- Hunting intent-based Android security vulnerabilities with Snyk Code
- How malicious applications abuse Android permissions