OWASP Mobile Top 10 - 2024 Edition
Update - Earlier version of the article incorrectly used OWASP MAS logo. OWASP MAS Project & OWASP Mobile top 10 are not affiliated.
It's been eight years since the last OWASP Mobile Top 10 update. That's a long time for an industry that keeps evolving by the day. While most entries in the 2016 version still apply, the foundation merged a few items and introduced new ones based on attacks observed in the past few years.
OWASP Mobile Top 10 is a collection of risk categories that assesses the security posture of an app. This could range from securing credentials to checking privacy misconfiguration. All of it is centered around mobile. This article discusses new items that got added. Instead of discussing them abstractly (A bad habit from my academic days 😄), I will walk you through practical examples of attacks seen in the wild. These cases are taken from individual researchers & are threat intel companies.
M1 Improper Credential Usage
Threat agents exploiting hardcoded credentials and improper credential usage in mobile applications can include automated attacks using publicly available or custom-built tools. Such agents could potentially locate and exploit hardcoded credentials or exploit weaknesses due to improper credential usage.
Back in 2020, a researcher was able to extract hardcoded credentials from an app that uses reason.ae marketing messaging platform. The credentials allowed the attacker to send unauthorized SMS to users. A perfect gateway to launch phishing campaigns.
M2 Inadequate Supply Chain Security
The process of fetching third-party repository goes like this (to the most part)
- Application developer adds a dependency in their project
- IDE (Android Studio or Xcode) goes out and fetches the requested dependency from public repository
- The downloaded dependency will be included in the app
- App gets built using the dependency
I won't get into the technical details, but there are many ways #2 (circled in red) can be hijacked. See research from OverSecured. There is also the infamous XcodeGhost chaos from 2015. Hence, developers should be wary about the dependencies they add to their project and should verify the source even when it's from "official" channels.
M4 Insufficient Input/Output validation
Almost all apps require users to enter some kind of data. Email address, password, files, etc. These inputs are entry points into the app's code. Carefully crafted input can exploit vulnerabilities & exfiltrate data.
Recently Xiaomi's system apps (including the System app) contained numerous security issues that allowed unauthorized parties to access arbitrary files, disclosure of phone numbers, etc.
In this example, the Settings app goes out and picks a file for internal processing. However, the app needs to check if the picked file is the right one. Format, extension, structure etc. Otherwise, malicious files (including executables) will make it into the app.
M6 Inadequate Privacy Controls
There are many examples where an app "mishandles" user's sensitive information. This could be an email address, location, physical address, credit card info, etc. Attackers use this information to craft targeted attacks or monetize the data for nefarious purposes.
Recently, an app called iSharing which claims to have over 35 million users faced a catastrophic privacy breach. It allowed anyone (hello spyware 🤦) to track users without their consent. The app revolves around groups. Each member within the group can track each other. But to join a group you need to receive an invite in the form of a 6-digit PIN. However, it's easy to generate this PIN code by impersonating another user in the group.
Make sure there are sufficient authentication & authorization while processing sensitive user data.
That's it for this week. In the next few weeks, I will try to map these examples on top of MITER ATT&CK
Cheers
Sandbox Brief Newsletter
Join the newsletter to receive the latest updates in your inbox.