Quite often the security aspect of our apps is not taken in consideration when we are working in our projects. Generally speaking the mobile ecosystems are perceived as very secure due the particular architecture and design of the main platforms (Android and iOS) compared to other platforms like, let’s say the Windows PC operating systems.

From a user point of view there is also this relaxed perception about the security of our devices. As we are going to see in this post we should take much more seriously the security of our platform, as developers and also as users, taking into account the massive amount of personal information that we carry in our devices. And here we as developers have a big responsibility.





The evolution

The malware and cybersecurity threats as we know it’s not something new. Hackers are being around for a while and their practices have been evolving with the progress and evolution of the computer systems.

In the early days malware were usually more kind of a joke, experiments and bit of fun with normally no much harm done in the attacked system. We remember virus like the ping-pong, bars, etc that were just an annoying joke in most cases.

Later on, massive infections of more disrupting malware started to spread mainly in the Windows platform, we remember viruses like Melissa, Conficker or Sasser that infected millions of computers around the world in a few hours, and in some cases leaving the systems unusable.

Pretty soon hackers realised that there was an opportunity to make money exploiting systems and vulnerabilities so this was the next logic step in the malware evolution. For example, very well known in these days are the ransomware cases where the attacker request an amount of money in order to unlock and decrypt the user machine.

And last but not least we can’t forget the special interest and effort of almost all governments around the world and how they are investing fortunes in spying, attacking and influence to internal or external targets for political and strategic interests.

With the popularisation of the portable devices it was a matter of time that they become the target of the bad guys who would try to access the massive amount of information collected by these powerful tools, not only personal information like bank accounts or emails but also access to critical sensors, location, microphone, camera, etc.





Threats in the mobile platforms

Based on Kaspersky report for Q1 of 2017, the mobile products of the security company detected 1,333,605 malicious installation packages, 32,038 mobile banking Trojans and 218,625 mobile ransomware Trojans.

One of the most common malware types identified were Trojans capable of gain super user rights. This is doable by exploiting well known vulnerabilities in older versions of Android. Unfortunately is quite common in the Android ecosystem that many devices never receive the latest updates of the OS to fix these vulnerabilities.

As we can imagine, once these malicious programs has gained super user rights, the possibilities and ways to control the device are massive. Read and alter text messages, modify URLs, steal login credentials, key logging, encrypt data, etc. just to name some of them.

These malware samples are not only distributed in dodgy stores, but also Google Play has been used to spread these malicious apps despite the improvements and effort from Google to increase the security and analysis of all the apps published in the market.

One example as reported by Kaspersky Lab was a Trojan app that was supposed to be a Pokemon Guide. But underneath, the application contained malicious code that downloaded rooting malware and installed unsolicited apps.

This application was downloaded more than 500,000 times and managed to perform at least 6,000 infections.

Another example was the false OS cleaning app Wiperius, that in reality was a Ransomware tool able to encrypt the device disk and afterward demanded a ransom to unblock the phone.

As we can see the mobile platforms are not so secure as most of users might think, compared to other traditionally more affected platforms like Windows.

So from a developer point of view, what can we do to make our apps more secure? How can we avoid hackers trying to break into our systems? How can we keep the personal data of our users safe and sound?

OWASP Mobile Security Project

OWASP is a non profit organisation and an open community dedicated to help organisations to develop, maintain and operate Software that can be trusted.

As part of the organisation there is the OWASP Mobile Security Project with the goal of classify mobile security risk and provide resources to mitigate the risk and impact of any possible threat, with the focus on the developers and at application level where we can make a difference in our apps.

They provide a few really helpful tools and frameworks like the Mobile Security Check List and Testing Guide, a list of tools and one particularly interesting for us as developers which we are going to focus our attention now, The Top 10 Mobile Risks.

Let’s take a look to the list and see how we can make a difference as developers to make our platform a safer system:

M1 – Improper Platform Usage

Misuse of a platform feature or failure to use the OS security controls, like Intents in Android, permissions, misuse of Touch ID, etc.

For example asking for too many or risky permissions can provoke misuse of them and increase the risk of an attack. Or using implicit Intents to run a Service, because you don’t know which service will respond to the Intent.

We can find here the official Android documentation about security tips and good practices.

M2 – Insecure Data Storage

Insecure data storage includes things like SQL Databases, Log files, binary data, resource files, etc.

For example, an app that is logging publicly critical or sensitive information of a user, or a “hidden” url of our backend services. Or an app that is storing sensitive non encrypted data in shared preferences or the database. If an attacker gain access to our device would be quite easy to get lot of personal information or critical for our business.

Follow the guidelines for storing data of the official documentation.

M3 – Insecure communication

Exploit any vulnerability to intercept sensitive data while travelling across the wire. This includes communication using Bluetooth, Wifi, NFC, GSM, etc. As sensitive data we understand things like session tokens, account details, metadata, passwords, etc.

As an example of attack scenarios we have seen apps sending personal information via non secure channels instead of SSL, or applications accepting connections even though certificates handshake fails.

Some recommendations to mitigate this threats would be using SSL/TLS, strong cypher suites, certificates signed by CA provider, do not send sensitive information via SMS or notifications, etc. Once again for a more complete list of recommendations check the official Security with HTTPS and SSL and Network Security Configuration.

M4 – Insecure Authentication

In this category we include the bad user authentication and session management, like failing to identify and/or maintain the identification during the app life.

Once an attacker understand and exploit a weak authentication process, he would be able to perform malicious request to our backend services,

Some ways to prevent these attacks: Ensure you always perform auth in the backend side, do not store credentials locally. If you need to keep any auth info in the device always do it encrypted. Do not use weak auth mechanisms like 4 digits Pin codes.

M5 – Insufficient Cryptography

So you are using cryptography but is not strong enough or your encryption process has flaws and weakness. In this scenario an attacker that have access to our device, if we are storing sensitive information encrypted but this is not strong enough or we are managing wrongly our keys, the data could be extracted and decrypted.

To avoid this scenarios use a strong cryptographic standards, avoid (if possible) to store sensitive information, use hardware backed encryption (if possible), etc.

M6 – Insecure Authorisation

Important here to understand the difference between Authorisation and Authentication. Where authentication is the process to identify an user, authorisation is the mechanism to check that the user has the right permission to perform a task.

Weak or flawed authorisation process might allow an attacker to perform actions as administrator of the system.

To avoid this scenario store the rules for authorisation only in the backend and do relay on device stored rules, perform authorisation checks when the app is hitting the backend on task requests, etc.

M7 – Client Code Quality

Here as mobile developers is where we have a big responsibility. Poor code standards, either intentionally (taking shortcuts, workarounds, tech debt or even malicious developers) or unintentional (junior or low skilled developers) can end up in poor quality code. And this will make vulnerable to memory leaks, buffer overflows, etc.

In order to avoid this maintain consistent coding practices, perform code reviews, use automated tools to detect leaks and other defects in the code base, implement a continuos learning and improving policy in your team, etc.

M8 – Code Tampering

There are different attack vectors in code tampering, like reverse engineering and modifying resources or even code source of the released app package, change dynamically the content of the memory at runtime of the app, replace the API that the app is using, etc.

Applications like games are quite susceptible of these attacks for example to skip payment for paid versions of the game, new features, etc.

For more information about this refer to this OWASP project.

M9 – Reverse Engineering

Hackers can download the app from the store and decompile our binary looking for source code, libraries used, assets, algorithms, etc. trying to find vulnerabilities and points of attack.

There are a few tools and solutions that we can use to obfuscate and make reverse engineering as difficult as possible, like the well known Proguard or more complete and complex commercial solution like Arxan.

M10 – Extraneous Functionality

An attacker can download the app and analyse it looking into logs, source code, configuration files, etc. and try to find extraneous functionalities. They will try to find hidden switches or backend APIs in order to perform an attack.

To avoid this, before releasing the app check for any app configuration settings where you disclose switches or hidden back doors. Check for public logs disclosing sensitive information, check that all APIs are well documented and no hidden administrative or debug endpoints are available.

Conclusion

As we have see the Android and others mobile platforms are not 100% secure. There are many attack vectors that hackers can exploit and we as developers have a massive responsibility to keep our systems and users safe.

A security breach can destroy the reputation and even the whole company itself so let’s do all what is in our hands to prevent crime, be aware of the risks and develop software with security always in mind.

As usual please leave any comments or suggestions that you might have.

Safe coding!