OWASP Mobile Top 10 Security Vulnerabilities and Attack Prevention

OWASP Mobile Top 10 Security Vulnerabilities and Attack Prevention

Far from the days of just phone calls and text messages, mobile apps have captured our attention with efficient experiences that keep us connected to friends, family members, coworkers. It’s all at your fingertips via these amazing apps- anywhere in the world! This blog post takes you through the OWASP mobile top 10 security risks, attack scenarios from OWASP and risk remediations that help cybercriminals get their hands on sensitive data.

In the last five years, our lives have gone through massive changes with the rapid growth of mobile apps, which has become a vital part of our lives. From connecting with friends to work chat to paying bills and watching our house and kids (baby monitors), everything’s available at the tap of a button. Lots of well known applications such as Whatsapp, Tinder, Mediatek and their users have fallen victim to mobile security issues. Spyware such as Pegasus is making news every now and then targeting governments and activities underlining the importance of secure mobile applications and devices.

OWASP stands for Open Web Application Security Project, is a non-profit foundation works to improve the security of applications/software by providing guidelines through local and global conferences and open sources software project such as OWASP mobile top 10 projects, web application project, API security project, serverless computing project and much more.

Our other OWASP popular posts related to web application and API security risks, attack examples, and remediation are:

OWASP Top 10 Vulnerabilities, Application Security Attack Examples (With Recommendations)

OWASP API Security Top 10 (With examples & fixes)

Does OWASP apply to mobile apps?

Yes, the OWASP applies to mobile applications (apps) and, to an extent, the underlying mobile device.

As stated above, the OWASP checklist provides security guidance to web applications and API security. OWASP mobile top 10 is a mobile security project focused on highlighting security vulnerabilities in mobile apps and the remediation and strategies to mitigate the risk associated with them. This top 10 list sheds light on the technical threats and answers the open mobile risk impact on the businesses.

What is the OWASP mobile project?

OWASP mobile project is a centralised resource for app developers and the security team to build and maintain a secure mobile application and mobile device. The project frequently updates the latest attack trends and attack vectors to provide a development control to reduce the attack impact and likelihood of occurrence and exploitation. It includes a testing guide, OWASP mobile top 10 list, cheat sheets and other resources for secure development.

Mobile application architects use the OWASP baseline to design secure app patterns; app developers use it to secure coding understanding and security tester to ensure security in the foundation and arena or mobile internal and external environment.

This community-driven OWASP mobile project is an excellent resource for developers and businesses to create secure mobile apps and configure mobile device security by listing down the critical and top 10 mobile risks that have impacted mobile security over the years.

This article elaborates all of the mobile vulnerabilities with attack examples and remediation guidelines to mitigate the risk. The development team can utilise the listed below checklist to produce a secure application from the starch.

What are the OWASP mobile top 10 risks?

Let’s look at the Top 10 OWASP mobile security vulnerabilities:

• M1: Improper Platform Usage
• M2: Insecure Data Storage
• M3: Insecure Communication
• M4: Insecure Authentication
• M5: Insufficient Cryptography
• M6: Insecure Authorization
• M7: Client Code Quality
• M8: Code Tampering
• M9: Reverse Engineering
• M10: Extraneous Functionality

Here, it is essential to understand that resolving the OWASP top 10 mobile vulnerabilities would not mean your mobile apps are immune to any attacks. Instead, Owasp mobile security risks and prevention methods serve as a strong security baseline for the organisation and development team to design and develop the secured application as far as possible. It is essential to test your application beyond these best practices checklists with other cybersecurity assessments for better security.

OWASP Top 10 Mobile Testing Guide

OWASP mobile top 10 security testing guide is a standard for the mobile application to address tools, techniques and processes with a set of test cases to secure mobile apps. OWASP top 10 offers a mobile security testing guide (MSTG), mobile app security requirements and verification for better mobile security.

Mobile Security Testing Guide (MSTG)

The mobile security testing guide has a security testing manual for iOS and Android security testers, including the following.

• Mobile platform internals
• Security testing in the mobile app development lifecycle
• Basic static and dynamic security testing
• Mobile app reverse engineering and tampering
• Assessing software protections
• Detailed test cases that map to the requirements in the MASVS

Mobile App Security Requirements and Verification

The OWASP Mobile Application Security Verification Standard (MASVS) is, as the name implies, a standard for mobile app security. It can be used by mobile software architects and developers seeking to develop secure mobile apps and security testers to ensure verification of test results.

Mobile App Security Checklist

The following best practices and the security risks checklist are created and based on the MSTG and MASVS with the test cases for each requirement.

What are the OWASP mobile top 10 risks?

M1: Improper Platform Usage

The first and most impactful vulnerability that imposes high risk is improper platform usage. The operating system or platform, such as iOS or Android used by mobile devices, offers a wide range of functions and features. Insecure implementation and development practices provide multiple attack avenues to the attacker, such as API call exposure, misuse of iOS Touch ID or Android Intent, etc.

Android intents, better known as Intent and Intent filters, are responsible for communication between different components such as apps, services, etc. A direct threat linked with Android intents is data leakage. Data leakage is a situation where data is disclosed due to errors, misconfigurations, or other flaws but not related to a data breach situation (unauthorised access of sensitive data).

By identifying code flaws, the attacker can access the application and inject malicious commands to steal data and compromise other application features.  Likewise, incorrect storage of iOS keychains, such as session keys stored in the local app or publicly marked Android Intent, can expose confidential user data or permit unauthorised access.

How to prevent improper platform usage?

This vulnerability can be prevented by addressing the remediation on the server-side features and the following steps.

• Follow the platform development guidelines and best practices for features such as Android Intent, Touch ID, iOS keychain, etc.
• Implement secure coding and configuration for mobile app development and server-side hardening.
• Restrict apps from user data transmission with each other.
• Limit file permissions and access.
• Enforce encrypted data storage

M2. Insecure Data Storage

Insecure data storage is the most threatening risk to many mobile apps, web apps, IoT devices, etc. Almost every application stores data about its users, known as PII (personally identifiable information). If it gets into the hand of any ill-intentioned attacker, that data can create many consequences ranging from fraud, data theft, reputational damage, regulatory violation, etc. Insecure data storage must be improved with storage policies and features that are secure and configured correctly. It would ensure that the sensitive data cannot be accessible to any other unauthorised person or application.

By jailbreaking or rooting the devices that run apps outside of the OS framework can provide the attacker access to sensitive data, and broken cryptography or poor encryption libraries might expose sensitive data or let the attacker access it. In contrast to it, social frameworks such as analytics, advertising, cookies and active sessions have many user information stored in them. If exploited, it can expose a lot of data to the attacker.

If the attacker or infuses malware in the device, repackages the app or gains physical access to the device, he would then assess the device via freely available software and access the application directories to gain PII PHI, financial or any other information.

How to secure data storage?

• Enforce data encryption
• Implement authorised and authentic access mechanism for mobile app
• Restrict access to storage files on mobile apps
• Secure code practices against buffer overflow, cookies object, data logging and caching through appropriate protection measures.

M3. Insecure Communication

Unencrypted and clear text data transmission provides an open path to an attacker to steal data during the communication. Anyone can intercept such insecure data communication by compromising Wi-Fi, installing malware or by a man-in-the-middle attack.

Insecure Wi-Fi networks can be used to gain access to corporate assets to steal sensitive data utilised for identity theft and fraud by cybercriminals. Similar to data in transit, it is important to use strong encryption measures to store important data (based on data classification levels) for the business.

How to prevent insecure communication?

• Implement SSL/TLS certificates for secure communication
• Use trusted and signed CA certificates.
• Deploy industry-standard encryption protocol and best practices.
• Transmit sensitive data, sessions token, etc. to the web service or backend API
• Refrain from sending session user ID with SSL session token
• Encrypt data before giving out them to the SSL channel (if possible)
• Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive information, session tokens, or other sensitive data to a backend API or web service

M4. Insecure Authentication

The attacker bypasses the security controls responsible for exploiting authentication control vulnerabilities such as improper validation, executing backend API service requests without a token or bypassing weak policies, etc. Unintended data disclosures are sometimes the direct result du to insecure authentication or lack of platform security controls.

Insecure authentication will drastically impact the application and communication if an attacker breaks into confidential information or privilege access.

How to prevent insecure authentication?

Implement MFA, complex and robust password policies.

• Match the web app security protocols with the mobile application in terms of authentication mechanism
• Deploy server-side authentication mechanism
• Do not store passwords on local devices
• If local storage is necessary, ensure the encryption key is derived from the user’s login credentials and enforce the process to authenticate application data.
• Refrain from persistent authentication (remember me) functionality
• Ensure data availability after successful authentication
• Give red signal or caution sign whenever user go for remember me an option for future authentication
• Enforce device-centric authentication so no one can access the app data on another device
• Ensure protection against binary attack

M5. Insufficient Cryptography

Mobile apps use and store various sensitive data that needs to be protected with solid encryption, but if the cryptography mechanism is flawed or weak, it loses its purpose. It leads the attacker to access proprietary, sensitive and personal information such as user name, location, credit card details, security numbers, PII, PHI, etc. Likewise, an outdated crypto algorithm such as RC2, MD4, MD5, SHA1 or the wrong implementation of cryptographic measures let the attacker quickly reverse-engineered or bypass the built-in encryption code algorithm.

An attacker can also assess the cryptographic keys and codes built into the operating system through jailbreaking or rooting the device by getting the decrypted codes from memory. Regardless of how strong cryptography is, if the attacker successfully gains codes from memory, he would perform static and dynamic analysis using the debugger or compiler.

Apart from the threats mentioned above, malware is also a significant threat in exploiting insufficient cryptography vulnerability. The attacker can decrypt the data while capturing the network traffic or injecting malware on the device with access to encrypted data.

How to prevent insufficient cryptography?

• Avoid storing data on the device where possible.
• Implement robust crypto algorithm as directed by NIST

M6. Insecure Authorization

The insufficient authorisation allows the malicious intruders to access and execute privilege escalation to steal sensitive information and damage the system, infrastructure. By exploiting insecure direct object reference (IDOR) vulnerabilities, the transmission of LDAP roles, navigating vulnerable access points, or identifying open and hidden end-points, the attacker enables himself to access files, databases, and accounts.

An incomplete or imperfect authorisation that fails to verify the user and grants permission as a legitimate account holder is the significant threat of insecure authorisation vulnerability in OWASP mobile top 10 list. Poor authorization is equally a security risk across web applications and APIs.

Example attack scenario – Insecure authorization

A user submitting an API request to backend rest API includes a userID and an OAuth token. The user includes their user ID and access token as a request header, and the application verifies the bearer token without validating the user ID associated with the bearer token. Due to this situation, the user can change the user ID and obtain other user-submitted information as part of this API request.

How to prevent insecure authorisation?

• Refrain from granting roles and permission coming through a mobile device
• Independently verify and match the identity through backend codes

M7. Client Code Quality

Client code vulnerability occurs as a result of poor programming practices in mobile application development. Such flaws present in the codes lead the attacker to exploit the client-side and server-side flaws by tampering with the codes, crafting malicious input to function call for code executions. These poor code flaws (memory leaks, buffer overflows) are present on the client-side and distinct from the server-side coding, which leads to exploiting the code weaknesses such as buffer overflows, remote code execution, memory leaks and data leakage.

Other than these, various apps depend upon third-party libraries and features for the app functionality and are often not undertaken into consideration. Thus, it offers an avenue for attackers to exploit vulnerabilities by injecting malicious code to change the app behaviour, sensitive data theft, hijacking of device computing power for crypto mining, etc.

Example attack scenario as taken from OWASP:

include 
 int main(int argc, char **argv)
 {
    char buf[8]; // buffer for eight characters
    gets(buf); // read from stdio (sensitive function!)
    printf("%sn", buf); // print out data stored in buf
    return 0; // 0 as return value
 }

The user of gets function in the above code should be avoided due to buffer overflow vulnerability here. This is most likely to come up during static analysis code checks.

How to prevent client code quality risk?

• Enforce secure coding practices.
• Usage of static code analysis tool
• Consistent code pattern
• Avoid simple logic codes
• Hold session until the user is authenticated via MFA, OTP, etc.
• Reliable and secure integration of third-party libraries
• Create third-parties libraries list to update and patch the third party promptly
• Test buffer overflow, memory leak, remote code execution issues via an automated tool
• Enable permission flag on the content provider to prevent unauthorised access.

M8. Code Tampering

By taking advantage of code tampering vulnerability, the attacker modifies and alters the code to create a bogus version of the mobile application and trick users into installing it via phishing and other social engineering scams. The attacker typically modifies the app’s binary to inject malicious code, install a backdoor, etc., on the application hosted in the third-party app stores.

This can be done by making direct changes to the application package’s core binary, resources within the application’s package, or redirecting or replacing system APIs to intercept and execute malicious codes.

Once the application is ready with a forged signature and backdoor, the attacker publishes the modified version on the app store as a legitimate application. The code tempering flaw leads to malware infusion, revenue loss, reputational damage, identity and data theft, etc.

How to prevent code tempering risk?

Focus on android root detection. There are several ways to detect a rooted android device.

• Check for test-keys
• Check to see if build.prop includes the line ro.build.tags=test-keys indicating a developer build or unofficial ROM
• Check for OTA certificates.
• Check to see if the file /etc/security/otacerts.zip exists
• Check for several known rooted apk’s
• Check for SU binaries such as /system/bin/su, /system/xbin/su, /sbin/su, /system/su, /system/bin/.ext/.su,
• Attempt SU command directly.
• Attempt to run the command and check the current user’s id; if it returns 0, then the su command has been successful.
• Enable the app to identify code integration and react accordingly (i.e., report to the server or shutdown)
• Implement anti-tamper techniques such as validation methods, checksum, code hardening, digital signatures.

M9. Reverse Engineering

Reverse engineering refers to disassembling the product to analyse the composition and core concept of development. Generally, all applications are susceptible to reverse engineering, some are more, and some are less. Attackers decompile the application to perform code analysis, identify the connection and information about backend server, ciphers, encryption algorithm to launch an attack to steal intellectual property, code modification.

Once they know how the app operates and is designed to behave, they modify it via tools such as IDA Pro, Hopper and other binary inspection tools to change the application behaviour by inserting codes and changing the functionalities.

In addition, reverse engineering causes a significant impact on the server security and capability to detect jailbroken and rooted devices.

How to prevent reverse engineering risk?

To prevent reverse engineering attacks, verify whether your application can be de-complied or not. A reverse engineer works upstream the usual development practices to find out the logic and inner functionalities of an application. For this, run your application in debugging tools used by attackers. Other than this, you may do the following to refrain your application from reverse engineering.

• Implement good strong obfuscation
• Deploy metadata code obfuscation
• Use C or C++ for application development as they both offer libraries to protect runtime changes.
• Separates the source code block and control the code flow
• Enforce binary packaging to refrain the attacker from directly code de-compilation
• Implement a mechanism to avoid the code debugging from tools such as IDA Pro and Hopper.

M10. Extraneous Functionality

Extraneous functionality refers to an element such as configuration files, log files, test codes, admin end-points, backend system functionalities that any attacker can leverage to perform any cyber attack. Such weaknesses do not require the attacker to run on the user end; they can usually see the flaws directly within their local environment.

This OWASP mobile top 10 list risk is often accidentally exposed by the developer without the end-user interface. However, the potential attacker can use it to gain access to app features such as database information, user details, user permissions, API end-points or might disable MFA or other security measures.

An example attack scenario for Extraneous functionality would be exposing an administrative endpoint. Developers sometimes include a hidden interface within the mobile application that would display an administrative dashboard.

Another example would be enabling debug flag in a configuration file that leads to unnecessary exposure of detailed trace and log files. This is helpful content for a threat actor looking to find ways to enumerate backend objects.

How to prevent extraneous functionality risk?

It is crucial to remember the automated tools cannot detect the vulnerabilities that can be chained up with other security flaws. It is important to perform a manual source code review to detect bugs in the codes.

Along with manual code analysis, make sure to check the following

• Examine the application configuration setting to identify hidden switches
• Examine the API end-points and log statement to ensure they are not publically available  or exposed by OEMs
• Either the accessible API end-point of the app is well-documented or not.
• Does the log have any content related to backend server processes, privileged accounts?

There are multiple areas to consider while developing a secure mobile app. It includes secure coding practices and design areas to avoid unauthorised access, have strong authentication methods, secure encryption practices such as secure encryption algorithms, encryption keys, fixing broken cryptography or other issues.

The use of intentionally vulnerable mobile apps is popular amongst security professionals to learn about mobile apps weaknesses and exploitation methods. Some of these are:

• iGoat iOS
• owasp-mstg
• Damn Vulnerable Hybrid Mobile App
• Android InsecureBankv2
• SecurityShepherd and more.

Conclusion

Owasp mobile security provides you with a good overview of different mobile security threats, including related mobile device issues and threats. You can use this as an internal security baseline for mobile application development practices. With time you should update it with your internal processes to ensure secure SDLC practices are inherent to your development and deployment processes.

Get in touch for your mobile security concerns and mobile application penetration testing services.