SBN

Understanding the OWASP Mobile Top 10 Security Risks: Part Two (M4-M7)

The post Understanding the OWASP Mobile Top 10 Security Risks: Part Two (M4-M7) appeared first on Intertrust Technologies.

Mobile application use is growing exponentially across the world, and so are the avenues of attack for hackers. The OWASP Mobile Top 10 threats list includes the most significant security risks that mobile applications face today. 

We’ve already looked at risks M1-M3 in part one of our OWASP Mobile Top 10 primer. Now we’ll investigate risks M4-M7 to find out what these threats mean and how they can be countered.

OWASP Mobile Top 10 Threats: M4-M7

M4: Insecure Authentication

Mobile apps typically have weaker authentication practices as they are limited by their device form factor and passwords often consist of 4 or 6-digit PINs. They also are not expected to be constantly online (which would allow for continuous verification). The requirement to be able to authenticate sessions offline often results in authentication schemes that are more prone to exploits and require a greater attention to detail during the implementation. 

Why it’s a problem

If the authentication procedures for a mobile app can be bypassed, a bad actor can anonymously execute functions and transactions within the app or backend server. If the attacker gains additional permissions, it can lead to widespread material and data theft for businesses, as well as damaging customer trust. 

How apps are vulnerable to insecure authentication 

Poor authentication in mobile apps can take many forms:

  • Weak password protocols, such as only requiring 4-digit authentication.
  • The storage of mobile app passwords on the device. 
  • Authenticating locally, rather than requiring online access, though this is often necessary for offline usage of apps.
  • Compromised platform authentication features such as TouchID or not requiring access tokens for execution requests.

What can be done

This particular OWASP Mobile Top 10 threat creates issues for the app user and distributor beyond unauthorized access, as an app’s code or cryptographic keys may also become vulnerable to attack. 

To create a more secure authentication process, a number of best practices can be followed, including:

  • Making authentication a server-side rather than local process and loading application data only after successfully authenticated. 
  • Not storing passwords locally on the device.
  • Using enhanced cryptography, such as whiteCryption Secure Key Box, which keeps crypto keys secure and bolsters data encryption on the device.
  • Avoiding vulnerable authentication methods which can be spoofed, such as geo-location or device identities.
  • Using multi-factor authentication which, unlike two-factor authentication, uses an additional layer of authentication like biometric data along with the standard username-password and secure code.

M5: Insufficient Cryptography

With the wide array of threats targeting mobile apps, and given that the devices they run on may be jailbroken, rooted, or otherwise compromised, it can be difficult to prevent data from falling into the hands of bad actors. However, that risk can be mitigated if the data that does get stolen is properly encrypted. The biggest hacks and problems for companies arise when they have insufficient cryptography implemented for their data.

Why it’s a problem

Most modern apps handle or store some kind of sensitive data. Encryption is a commonly used method to protect this data but when implemented incorrectly, the whole purpose of encryption is lost. Insufficient cryptography can lead to hackers getting access to proprietary information as well as personal information about an app’s user such as their name, location, credit card details, social security information, medical ID, and more. It also has a major impact on the business behind an app, as its code can be accessed and reverse engineered, creating further exploits or leading to the theft of intellectual property. 

Reputational damage and regulatory punishment are also concerns. While it’s undeniably serious if hackers steal a million customer details written in plain text, it is nearly as damaging if they get access to an encrypted dataset that uses poor encryption techniques and is easy to exploit. 

How apps are vulnerable to insufficient cryptography

There are a number of methods that both developers and OS manufacturers use to try and encrypt app code and data, but unfortunately most of these are relatively easy to bypass. Code encryption that is built into the OS can still be accessed through jailbroken/rooted devices, with snapshots of the decrypted application code captured from the memory and then using a compiler or debugger to perform static or dynamic analysis.

Custom encryption protocols or insecure/outdated cryptographic algorithms also put data and code at risk—MD4, MD5, SHA1 are all examples of outdated cryptographic algorithms that are insecure but are still being used. As the computational powers of hackers improve, cryptography needs to increase its complexity to stay ahead.

Key management is another major flaw in commonly used cryptography, as most often the weakest part of any cryptographic system is the key used to create it. If hackers can locate or steal those keys, it doesn’t matter how strong the cryptography is.

What can be done

Stronger cryptography is a clear solution to weak algorithms, and standards should be implemented that will last into the future. However, there can also be a trade-off between lead-in and connection times for using ‘heavier than necessary’ encryption. This means that while cryptographic systems should be strong, other aspects of shielding an app’s cryptography also need to be employed.

The most important step that can be taken to safeguard against this OWASP Mobile Top 10 threat is using a proven white box cryptography solution that has been tested over time and for strength. The whiteCryption Secure Key Box is an easy-to-integrate white box cryptographic library that makes encryption keys resistant to static or dynamic analysis. The keys are never visible in the clear—neither at rest nor during transit or execution. It supports most popular cryptographic algorithms, ensuring your keys stay safe, thus shielding code and data from theft.

M6: Insecure Authorization

Insecure authorization is related to insecure authentication, as they both deal with user identities and credentials. However, while authentication checks that the user is who they say they are, authorization checks for the authenticated user’s permissions. Authorization usually follows directly after authentication. A mobile app with insecure authorization means that users can gain a level of access that allows them to execute commands that they shouldn’t have permission to.

Why it’s a problem

Easy access to permissions or over-privileged users can cause major issues for app owners. It means hackers will be able to navigate to databases and directly steal data or take over other accounts. For example, after a few hours playing with a smart automobile tech company’s app, this researcher managed to exploit its poor authorization system. In doing so, he was able to: 

  • Find out where every car using the system was located (and their location history)
  • Unlock any car using the system
  • Start or turn off the engine of any car they wanted
  • Gain complete access to other user accounts and the ability to change their passwords

 

With that kind of unauthorized access, hackers could conduct large-scale and dangerous activities beyond simply exfiltrating information.

How apps are vulnerable to insecure authorization

There are several exploits hackers can use to take advantage of insecure authorization, including:

  • Exploiting Insecure Direct Object Reference (IDOR) vulnerabilities, which allow hackers to access databases or files using only user-supplied identifiers
  • Navigating to vulnerable or hidden endpoints that were not intended to be accessible but allow hackers to execute privileged commands
  • Incomplete authentication processes which fail to properly identify users or allow users to spoof identities after passing initial authentication

What can be done

Authorization processes should be run through remote servers rather than local inputs. Allowing high levels of permissions through the mobile device can act as a backdoor to expose remote databases.  

Backend processes should consistently verify matching requests to identities to stymie hackers who may have managed to get past initial authentication. Using pen testing to establish what can be achieved through low-level permissions will give developers a better idea of how vulnerable the app is to insecure authorization. 

M7: Client Code Quality

When writing code for an application, it is almost impossible to avoid bugs. Not all of these are serious, but when multiple teams are working together, when apps are being created off third-party frameworks, or when an app is being updated by piling more code on top of older code, flaws and vulnerabilities are more likely to appear. 

For the OWASP Mobile Top 10 threats list, this entry refers solely to poor code quality on the app itself.

Why it’s a problem

Hackers use easily available tools to perform reverse engineering, fuzzing, and static or dynamic analysis of mobile apps to understand how its code works and what code quality vulnerabilities exist. From there, the range of possibilities depend on the type of exploit, but can include:

  • Injection of malicious code that causes the app to perform in ways other than intended
  • Theft of private user data
  • Theft of intellectual property
  • Hijacking of device computing power for use in botnets or cryptomining
  • Reputational damage for firms who distribute apps with poor code quality

How apps are vulnerable to client code quality

As we’ve discussed before, most code contains around 15 errors per thousand lines of code. Modern mobile apps containing millions of lines of code, equaling tens of thousands of errors per application. Even apps with the safest reputations, such as WhatsApp or the Mail client on iOS, can often contain serious zero-day exploits that can be used to attack groups of people or targeted individuals.

Common vulnerabilities that hackers exploit in-app coding include:

  • Buffer overflows, especially for code written in C and C++, can give a hacker the chance to run arbitrary code or gain unauthorized access 
  • Vulnerabilities which allow remote code execution and thus give attackers the potential to circumvent authentication and other security protocols
  • Integration with insecure third-party libraries
  • Using the wrong or an insecure API
  • Poor or insecure coding language constructs including format string errors

What can be done

Guarding against poor code quality is an ongoing battle for app publishers. One important consideration, especially for large or decentralized development teams, is the use of consistent coding patterns throughout the organization, backed up by clear and strong documentation such as a source code protection policy. Apps can be tested for buffer overflows and memory leaks arising from poor code quality, which can help to reveal vulnerabilities.

Code owners or app publishers can also implement code protection as part of an application shielding approach to protect themselves from code manipulation or IP and information theft. whiteCryption Code Protection from Intertrust employs a wide variety of methods, including advanced obfuscation, diversification, and integrity checking, to make it almost impossible for hackers to understand code and identify vulnerabilities caused by poor code quality. 

Stay tuned for Part Three

Next week we’ll cover the final OWASP Mobile Top 10 threats, M8-M10.

Meanwhile, to learn best practices to protect your applications from attack, we recommend reading The Practical Guide to Application Hardening.


*** This is a Security Bloggers Network syndicated blog from Intertrust Technologies - Security Blogs authored by Prateek Panda. Read the original post at: https://www.intertrust.com/blog/understanding-the-owasp-mobile-top-10-security-risks-part-two-m4-m7/