8 Signs your Android app is about to be hacked

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.

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.

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. 

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. 

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. 

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. 

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. 

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.

Android Security, Android Vulnerabilities, Mobile Application Risks, Mobile Application Security, OWASP, Penetration testing, Vulnerability Assessment, Network Security, MSSP, Managed Security Services, Application Security

Securing Pharmaceutical and Drug Manufacturing Plants

In the past few years, very few other industry segments have faced security threats from as many different angles as the Pharmaceutical industry. Be it insider threats – negligence or espionage, tampering or malware, chemical plants and life science research facilities have seen it all. As exploit techniques and physical intrusion are taking on advanced vectors to evade detection, security implementation teams encounter difficulties in integrating, mapping and monitoring malicious behavior, changes and actions that lead up to a security incident. When safety and critical missions come into play, risk analysis, and threat modeling are indispensable assets the business owner must invest time for.

Be it standalone systems or air-gapped, securing pharma plant/facility requires adept knowledge of targeted threats and impacts. Read the whitepaper for essential tactics, methods and approaches to gain assurance through context-aware security measures. The paper serves as a guide for assessment, baselining, hardening, monitoring, and response. 

Enabling Secure Environments for Pharmaceutical Manufacturing Facilities

-       

      An Implementation Guidebook

Implementation Guidebook, Industrial Control Systems Security, Industrial Security, Manufacturing System Security, Pharma, Plant Security, SCADA, Network Security, MSSP, Managed Security Services, Application Security

Find your fit: How to select a security monitoring solution?

Competitors Company X and Company Y, both have corporate networks to protect from cyber attacks. Company X opts for a certain security analytics feature for their public-facing website linked to database servers. Company Y follows suit even though they don’t have a similar system architecture. When asked why, Company Y responded saying, “We thought it was an industry best practice”.  

Don’t be like Company Y.

We get it. The journey towards finding the right security service provider and the appropriate mix of tools for your organization can be quite disconcerting. Many a detour later, you might be tempted to stop short and just tell the IT guys to do what their peers are doing. But wait, don’t call the IT guys. Take a deep breath and remind yourself that Security Management is a business problem, not an IT problem.

CTOs find it hard to plan security budgets because measuring the ROI for a security tool isn’t as straightforward as it is in the case of enterprise software. But refocusing on your very own set of security goals can go a long way in helping discover what you need and where to seek it. 

Here are some key aspects often neglected. We hope they help your decision-making process.

Define your goals

---

Listing your security visibility and defense goals will help you identify precisely what is needed and what you will lose without it, thereby establishing priority for those goals. Security monitoring is a multi-faceted asset that must be equipped to support the information needs of security analysts, internal and external auditors, and CIOs or CSOs. Define your success criteria. If your business requirements and objectives have evolved, or your operating norms have changed, interface with relevant departments to understand situational information and specifications. You will then have well-planned purchase criteria.

1. Convergence: One or many-in-one?

Getting the most of out of your security expenditure does not mean adding more tools. It is more about making generally independent and isolated controls to work in a concerted manner. This is the principle behind security monitoring solutions like SIEM where security data from different sources are integrated and points of leverage are milked for insight.

As your organization grows and expands, scalability of your security solutions becomes a concern due to challenges in adaptability across different technological platforms. Moreover, one must also consider the cost of purchasing individual licenses for a product intended for higher scale or a wider scope. These complexities can be avoided if you plan ahead while making a purchase. Seek to know how scalable the product is and what benefits it offers in terms of reducing license costs.

Do not hesitate to go for more than one vendor. Like we already mention, the only thing to keep in mind is Convergence. It is highly unrealistic to expect that one firewall or traffic monitoring tool will suffice and be effective in providing thorough visibility. Whether you have existing tools and want to add something new or want to replace them all with a comprehensive platform, unified management must be your ultimate objective. Take the help of Managed Security Consultants to identify the right mix based on their intrinsic value. Just make sure that they interact in a way that does not give the IT department additional responsibilities. Commonly, the most indispensable capabilities like Vulnerability Management and File Integrity Monitoring can be trussed under a security monitoring platform as they have more to offer about vulnerabilities and threats together than segregated.

2. Your location and deployment options

Do you have multiple corporate networks and operational units situated in different places? Do you expect additions or changes in the future? A clever move is to examine the deployment model of the security provider and available options for easy future modifications. Whether the solution you are planning to purchase is software-based appliance-based, it is important to evaluate how the data will be handled. Depending on your needs, you may prefer a centralized set up wherein different locations communicate to a parent server via VPNs and sensors. Or, your choice may be a fully cloud-based solution. You might even need a hybrid of cloud and on-premise. Your service provider must offer these options and a robust environment with the capacity to handle your data retention needs.

3. What are your BYOD goals?

BYOD has greatly impacted the security monitoring challenges of its adopters and the focus of security solution vendors. If you have an extended enterprise or a BYOD program, you will need to vigorously protect your sensitive data from the dangers of negligent use and rogue devices. If you have NAC, look for the ability to monitor it simultaneously along with flow-level visibility and a sweeping view of connections, services and file system changes.

4. Compliance and Threat Intelligence

Let your compliance requirements direct your decisions with respect to the most vital security components you will invest in. But be sure to include within the purview of compliance, issues beyond what is mandated by regulating authorities and standardization agencies as ‘risks’. Find out how a security solution can incorporate industry and location-centric threat information, statistics and experiences. It is important to choose a product that has an active, widespread community of security professionals from whom you can gain knowledge of the threat landscape.

Engage perceptiveness

---

The value that you initially expect to derive from a security monitoring product may be shaped by what has been promised by the vendor and perhaps by what other users have gained out of it. But the true value of a security tool, as is realized only much later, completely rests on how well it is configured, adjusted and primed. Simply put, a non-optimized resource has very little to offer and, misdirects expenditure and labor.

The person or persons who will set up and manage monitoring systems for your assets must have the ability to ‘discern’ and ‘diagnose’. They must be well aware of the mutating security needs and goals and have the insightfulness to judge the adeptness of controls and policies at every stage. Refinement is a key element in making a tool bespoke and context-aware. The Plan-Do-Check-Act cycle is a critical component of continuous infrastructure monitoring and requires experience not just for the analysis of alerts, but more importantly for the refinement of the functions of the tool. Such personnel must have prior knowledge of how the tool functions in different scenarios and how it must be manipulated for the company-specific issues and scenarios of interest.

How much prescience has gone into the evaluation and administration of policies? That is what will determine how well a threat monitoring tool has been put to use. After all, even the most powerful threat signature needs to be applied in the right way, anticipating the threat it is designed to detect.

Need help analyzing requirements or want to pilot leading security monitoring tools?  Reach out to us: alephtavtech.com

Continuous Threat Protection, Managed Security Service Provider, Outsourced Security Monitoring, Security Incident Response, Security Management, Security Monitoring, Threat Monitoring, Enterprise Security, Managed Security Solutions, SIEM, Threat Monitoring