OWASP MOBILE TOP 10 : Improper Platform Usage - Tutorial Boy -->
Home
Mobile Pentest

OWASP MOBILE TOP 10 : Improper Platform Usage

Introduction

The improper platform usage vulnerability refers to a vulnerability that is derived from the improper usage of platforms in use by an application. In other words, this category covers the misuse of a platform feature or the failure to use certain security controls. Probable misuse scenarios could include the misuse of TouchID or some other security control. In general, the improper platform usage vulnerability might appear to be insignificant at first, but in the hands of an attacker, it could certainly be used as an avenue for an attack on a bigger scale.

  • Exploitability: Easy
  • Prevalence: Common
  • Detectability: Average
  • Impact: Severe

Application-Specific

This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system.

Attack Vectors

the misuse of a platform feature or the failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system. There are several ways that mobile apps can experience this risk.

Security Weakness

For this vulnerability to be exploited, the organization must expose a web service or API call that is consumed by the mobile app. The exposed service or API call is implemented using insecure coding techniques that produce an OWASP Top Ten vulnerability within the server. Through the mobile interface, an adversary can feed malicious inputs or unexpected sequences of events to the vulnerable endpoint. Hence, the adversary realizes the original OWASP Top Ten vulnerability on the server.

Impact

As you already probably understood, such a vulnerability might arise when an app fails to use secure coding practices when creating a mobile application. All mobile applications should use certain security controls – the failure of using them could result in such a vulnerability being introduced into the application in question. According to OWASP, the threat agents for this vulnerability are application-specific and any exposed API call could become a potential attack vector for a nefarious party. For this vulnerability to be exploited, the mobile app should have an exposed service or an API call that is implemented using insecure coding techniques.
  • Poor Web Services Hardening
  • Logic flaws
  • Authentication flaws
  • Weak or no session management
  • Session fixation
  • Sensitive data transmitted using the GET method
  • Insecure web server configurations
  • Administrative interfaces
  • Injection (SQL, XSS, Command) on both web services and mobile-enabled websites
  • Session Management flaws
  • Access control vulnerabilities
  • Local and Remote File Includes

Prevention

To protect your mobile applications from improper platform usage vulnerabilities, limit the applications that are allowed to communicate with your application, familiarize yourself with the OWASP Mobile Top 10 and general security best practices, do not violate the security guidelines of the platform you are developing in and avoid unintentional misuse – if you are implementing services or APIs that are communicating with your application, be sure to implement them properly. If you’re dealing with iOS, for example, use the iOS Keychain instead of the local storage – data stored in the local storage is available in unencrypted iTunes backups. If your API or service is communicating with a web server, be sure to harden its security – test your web server and avoid the OWASP Top 10 vulnerabilities prevalent in web applications, perhaps use a firewall, invest in an intrusion detection system, etc.

Implementation


As far as the real world is concerned, improper platform usage vulnerabilities usually stem from exposed service or API calls that are secured improperly. When exploiting these kinds of vulnerabilities in the real world, the attacker is usually able to provide some kind of unexpected sequences of events and (or) malicious input to a vulnerable endpoint – a service on an API. The service or the API would then process the input and, depending on the vulnerability being exploited (the attacker could potentially exploit any vulnerability outlined in the OWASP Top 10, potentially grant the attacker access to confidential information.

Insecure Components

One of the first things you should check in this configuration file is for the stuff inside the <application> tag, here you will find the components defined for this application, components are either activities, broadcast receivers, content providers, or services, each of one with their own functionality and characteristics. In general, if you see several components with the exported flag set to true, this is most likely a sign of misconfiguration and bad use of the platform. Here, it is important to point out that, even if a component does not have the exported flag if an intent filter is defined within the component, the exported flag is set to true by default.

Debuggable application

While building an application, a debugger is a developer’s best friend, it provides the ability to inspect the application code line by line as it executes, this helps to identify root causes of bugs and fixing them. Shipping your application with the debuggable flag on, however, represents a security risk to your application; this could allow an attacker to obtain access to sensitive information, control the application flow and gain code execution in the context of the debugged application. You can find more detailed information on how to exploit this vulnerability

Allow Backup

Allowing your application to be backed up may also lead to situations in which code injection can be achieved by an attacker with access to the device. Once the attacker has been able to get a backup of the application, the header of the backup is separated from the content (code and resources), the content then is modified by injecting code or changing values of resources, the modified content is then appended to the unmodified header and push back into the device. 

Summary

The first vulnerability in the OWASP Mobile Top 10 is related to the use of an insecurely configured service or an API – a vulnerable endpoint – that usually interacts with another application. To avoid such a vulnerability being introduced into your mobile applications, limit the applications that are allowed to communicate with your application, familiarize yourself with the OWASP Mobile Top 10 and general security best practices, do not violate the security guidelines of the platform you are developing in, avoid unintentional misuse of the platform or security features and you should be well on your way to more secure mobile applications.




Post a Comment