8 Signs your Android app is about to be hacked.

Aleph Tav Technologies Android Application Vulnerabilities_header

Developing Android apps that make the cut as secure, reliable and robust is a goal that is getting increasingly dodgy, thanks to the myriad ways in which hackers are exploiting inherent platform vulnerabilities, code loopholes and API bugs. The Android development community is faced with new challenges as devices are perked up with futuristic technologies, modified operating systems and the security risks that come with fragmentation. While users can be warned against insecure practices, developers have the true power to make apps inherently resilient and naturally those that stand the test of time. As Malware Scares like the Quadrooter and Godless are making it hard to trust the Play Store review system, developers need to have their apps undergo rigorous testing before release to avoid damages to embarrassing damages to reliability and integrity, getting replicated and the risk of being blacklisted everywhere.

If you are planning a roll-out of an Android app and drawing up security activities in production, check to make sure it is protected from these malignant issues:

1. Inappropriate use of Platform Security Features

2. Insecure Data Environments

3. Improper Implementation of Cryptographic Controls

4. Inadequate Transport Protection

5. Authentication Inconsistency

6. Permitting Unauthorized Actions

7. Unsecured Code

8. Lack of responsive User Privacy Controls



Inappropriate use of Platform Security Features

With numerous forked versions of the Android OS serving the demand for variety, your application faces hidden challenges with regard to perceptively adapting to their fundamental differences, and security gaps introduced by inbuilt apps, emulators, and so on. Device makers have developed their very own security features aimed at safeguarding their users’ identities, data and activities. Apps may not be coded to recognize and integrate with the built-in security features of every platform they run on. Incorrect use or failure to use such platform features weakens the security of your user’s data but the real detriment here is the violation/contradiction of the manufacturer’s best practices, easily making the app unsuited or undesirable for said device.

Sometimes apps use a permission model that is not well thought-out. This issue can also have the same consequences.

[back to top ↑]


Insecure Data Environments

Protecting data in its entirety with appropriate controls, mechanisms and safeguards is a topmost goal of secure development. Issues in data protection arise when the developer adopts a rather uninformed approach in identifying storage options. Each data type has a distinct use and its leakage puts different assets/functionality at stake. Device file systems are highly vulnerable places to store sensitive information. Data security measures must include in its purview, the risks associated with rooted devices that nullify the effect of encryption. For instance, an app that does not have the ability to detect when a device has been rooted will allow the user and other apps with root access to read its sensitive data and allow encrypted data to be converted to readable text.  For this reason, an app that allows backup is also vulnerable.

Unintended data leakage can result from scenarios like URL caching, Clipboard or Keylog caching, HTML5 data storage, Browser cookie objects and third part app analytics. All application data which may include SQL databases, logs, cached messages, manifest files, cloud sync data and histories should undoubtedly be stored encrypted in the app data directory since storing executables or class files anywhere else can risk tampering.

As for apps that need to share data through Content Providers, developers must choose the best controls based on whether they want to limit data access to that application or to allow access by other trusted apps or do not want to set any data access restrictions at all. Study the development frameworks for Storage Access and Interprocess Communication (IPC) and its components such as intents, binder and messenger interfaces and use the preferred attributes to disable exporting or restrict functionality to other apps you may develop.

[back to top ↑]


Improper Implementation of Cryptographic Controls

Barring issues related to TLS, there are a number of ways your cryptography could be a bad fit. When controls to encrypt data have not been enforced with pertinence, their effect is nullified. The invincibility of encrypted data depends on proper, context-aware implementation. Using a weak cryptographic algorithm holds the risk of a cryptanalysis attack which now has plenty of exploit tools in the market.

The best way to prevent hackers from stripping open your data is to eliminate broken or risky algorithms, one-way hashes not secured against rainbow tables, keys that are too small and not sufficiently random, easily forged signatures and weak ciphers.

[back to top ↑]


Inadequate Transport Protection

The entirety of protecting data in transit – be it from the app to server, across apps, device to device or between a mobile and a smart device – depends on three factors – data integrity, data confidentiality, and origin integrity. Risks are introduced by inherent weaknesses in communication technologies such as SSL v3 which has the Poodle vulnerability. As an Android developer, you are expected to aggressively analyze whether and where protected data is being passed via a non-secure channel. Applications could have a gap in encryption for connections from client to server, server to database or backend processes – regardless of the fact that they might be behind a firewall. Also, never assume that everything sent across a secure connection. Most often, flawed configuration is the real threat. Client-side injection attacks and traffic interception are possible when a TLS connection has not been negotiated properly or is setup with weak a cipher suite. The app cannot unconditionally accept any certificate that the server provides. If it loses its capacity to authenticate the web server, it becomes susceptible to eavesdropping by a TLS proxy. Likewise, session cookies must be affixed with mandatory security-related attributes.

[back to top ↑]


Authentication Inconsistency

Poor Authentication schemes and session management flaws can make it too easy for hackers to get their hands on personally identifiable information and impersonate them. Even apps whose purpose entails that they must be thoroughly secure seem to have issues in this area. Your users may expect a quick access to their dashboards or a one-touch login and yet their data may require high privacy. Such paradoxical challenges set the bar high on how you must plan your defenses against spoofing, session hijacking, accidental data leakage and brute-forcing. Once they find a gap in the authentication scheme, an attacker would try to directly interact with backend services. Apart from sending credentials over unencrypted channels, which has been covered under transport security, here are some of the issues that need attention:

– Default or weak identifiers – Could be spoofed. User-revocable Authentication tokens can also provide data confidentiality if a device if stolen.

– Session handling errors – Keep in mind that mobile app users aren’t accustomed to logging out after every session. Indefinitely available sessions, multiple sessions and session fixation are critical flaws.

– Lack of password complexity/entropy  – Simple passwords are guessed with very less effort.

– Non-generic authentication responses – Letting a potential threat actor know that he is almost there by telling him what he got wrong – the password or username – is not the best way to stop him from bruteforcing. Use ambiguity. 

– Absence of account lockout policy – stop automated attempts at guessing passwords.

[back to top ↑]


Permitting Unauthorized Actions

Regarded one of the most common types of flaws, insecure authorization accounts for attacks that are simple to carry out but hold big impacts. Your Android app may be doing a great job at handling the user’s preferences, privilege level, and allowed menus/features. But the problem arises when the server or servicing endpoint blindly accepts requests assuming that it is within the user’s privilege level simply because the app code authorizes it. Validating requests only based on whether the requester is an authenticated user, is a fatal error. But as scary as it sounds, many apps still allow any random user to access menu pages of other users with something as effortless as a modified user id or label.

[back to top ↑]


Unsecured Code

Your application code – its quality, implementation and design can be the cause for insecure functionality, more often than not. Incorrect APIs or APIs insecurely invoked are responsible for threats arising from untrusted inputs. If the quality of your code is not optimized to the kind of input expected, attacks like buffer overflow are possible. Poor code can make it easy to mess around with the business logic. A major part of this issue deals with how well input validation is enforced and client-side code is sanitized. Use of parameterized queries and intent filters can mitigate common injection risks here. 

Preventing parameter tampering with mandatory flags and sanitization and other controls can be done through modifications to the code.

These are loopholes just waiting to be found. And that brings us to another aspect of code hygiene – preventing tampering and reverse engineering. The very first layer of defense an app can have against hackers on the prowl is hiding all information that would be valuable in constructing exploits that will have definite success. Letting a burglar know in advance the type of lock you have on your gates, doors and safe is going to save him a lot of time and heighten his chances of breaking in. Make sure error handlers are customized with generic messages, directory paths obfuscation and

Android apps are particularly susceptible to repackaging with rogue actions, counterfeiting and defacement. Source code must be protected from replication and decompiling using obfuscation techniques.

[back to top ↑]


Lack of responsive User Privacy Controls

There are several other independent, recommended techniques to prove that your application is built to protect the privacy of user. These controls may be influenced by the innate characteristics of the platform or OS. Anyhow, eavesdropping must be addressed through measures like Certificate Pinning, support for HSTS (HTTP Strict Transport Security), Remote Session Invalidation and so on. User action could be manipulated through rogue actions like Tapjacking. Steps must be taken to prevent such attacks using explicit adjustments to content security policy headers.

[back to top ↑]



Construct an extensive threat model for your app based on how the Android version, platform and frameworks handle the above scenarios.

Talk to us for objective assessments.




Leave a Reply

Your email address will not be published. Required fields are marked *

* Please enter the Characters - [Case Sensitive]