Threats / 04 Malware

Developing and distributing fraudulent apps is the simplest and most common method of mobile malware attacks on Android and iOS devices. This can involve:

But attackers can also distribute malware in any executable format that can be loaded onto a device, which might also be via: 

And although it may not always be categorized as malware, in this page we’ll also cover third-party libraries which developers integrate into their applications without knowing that they too might be malicious.

A mobile app consists of various components (or building blocks), but the fundamental ones are the User Interface (UI) Container, Data Provider, Background Worker, and Notification Observer. Depending on the OS or platform, some or all of these components can be made accessible. In other words, they can become entry points to your application. And that means that other apps, including malware, can interact with your application through any of these components. For example, your app can define an accessible data provider component to let other apps access its data and resources. That’s why it’s so important to make sure that accessible app components aren’t able to host any vulnerabilities. If they do, they’ll become easy prey for malware to exploit.

Let’s look at an example. Malware could access all the files of your application by exploiting the Path Traversal vulnerability in the app’s data provider components (Content Provider for Android or File Provider for iOS). How does it work? Well, the malware attacks by sending a specially-crafted path to obtain a handle of your application directory. And if your app stores sensitive data such as authentication tokens in that directory, then this vulnerability might lead to sensitive information leakage. This is a particularly dangerous threat for Android. A malware could also render your app inoperable or perform arbitrary code execution by taking control of a particular memory region in your app. It could interfere with the component that receives data from other applications and then try to process that data without any validation.

Malware doesn’t always employ highly sophisticated techniques to exploit applications and their users. Sometimes it abuses innocent features which are provided by the OS in the first place to provide a better experience for the users. This is a very common attack vector - especially on Android-based mobile devices. In recent years we have seen a significant number of Android-based mobile malware attacks abusing Accessibility Service. As the name suggests, Accessibility Service is a feature to help users with disabilities to operate their mobile device more easily. So, it has the privilege to do special things that most apps simply cannot do. By using the APIs provided by Accessibility Service, applications can perform things like:

To access these functionalities, the requesting application needs to first register its own Accessibility Service to the OS through its manifest. The requesting app also needs to specify particular features of Accessibility Service that will be enabled. The OS will then start the requesting application’s Accessibility Service after the user's approval. A malware is likely to also specify the aforementioned functionalities above.

What makes Accessibility Service so attractive for malware is that it can help it to circumvent the sandbox or isolation provided by the OS to protect applications from unauthorized access to its protected resources. And without needing to look for exploitable application components. For example, auto-clicker apps can inject input actions into your app. Normally, injecting input actions into other apps without sufficient permission would result in an error thrown by the OS. But when using Accessibility Service, auto-clicker apps such as Automatic Transfer System (ATS) malware can easily work around these restrictions and achieve their objectives. The malware can also render your app unusable by displaying continuous overlays on top of it every time the user launches it.

Although it’s practically impossible for malware to do the same thing on iOS, it’s still possible for malware to interfere with your application through legitimate OS features. One example is taking advantage of the keyboard system. The malware could masquerade itself as a custom keyboard app and, once the user sets it as the default keyboard, it could intercept any keystrokes made by users of your application.

Malware might be able to take control of your application runtime by exploiting vulnerabilities within your app or by abusing OS features. For example, by corrupting a particular memory region within your app or displaying continuous overlays on top of your app, rendering it inoperable or unusable.

Stealing sensitive data is often the main goal of mobile malware attacks. By trespassing over your application sandbox system - perhaps exploiting vulnerabilities like path traversal - a malware can freely access and retrieve any data processed or stored by the app and then send it to the attacker’s C&C server. Abusing OS features like Accessibility Service in Android can make it easy for malware to steal end users’ data, including sensitive account credentials.

Supply chain attacks have really hit the headlines in recent years. Any type of software or application can fall victim to this type of attack - including mobile applications. 

While using third-party SDKs may significantly ease the development burden and enrich your mobile app’s functionality, security considerations should never be sidelined for convenience. Remember that you’re working with third-party code - you should put a standardized policy or practice in place to determine and vet any SDK before it’s integrated into your mobile application. That’s where Software Composition Analysis (SCA) comes into play. It’s like doing due diligence on third-party SDKs, which goes a long way to preventing malicious SDKs from getting through and corrupting your app from the inside.

You can integrate dependency validation tools into your build pipeline, meaning every time you try to add an SDK into your mobile application project, these tools will automatically verify all listed SDKs. Alternatively, you can use tools to scan the app’s dependencies after compilation and identify any known vulnerabilities.

It’s best practice to encrypt stored data. Particularly if that data is sensitive. Encryption helps to prevent any sensitive information leakage even if the malware successfully accesses your application’s private directory by exploiting vulnerabilities like path traversal.

In Android you can take advantage of built-in frameworks like EncryptedSharedPreferences and EncryptedFile. And in iOS you can use NSFileProtection configurations during file creation to encrypt any sensitive data that is about to be emitted from the app into the local storage. Leveraging built-in security frameworks for encrypting data is also recommended as they often take advantage of hardware-based security modules or trusted execution environments on modern devices that are much harder to compromise.

One point that should not be overlooked is the importance of educating your end users about reducing the risks of malware getting onto their device in the first place. As mentioned at the top of this page, malware is most often ‘invited’, through users downloading a malicious app or clicking a link. User education - including warning dialogs within the app - can go a long way to reducing the dangers and the costs of malware.

As a first step prior to exploiting a particular vulnerability, attackers will often decompile your app, analyze it, and figure out how it works and identify targets. Code hardening (obfuscation, encryption, virtualization) can add hurdles, making this type of reverse engineering through decompilation and static analysis difficult-to-impossible for attackers, as covered in the Decompilation and Modification threat page of this guide. And for the same reason, it’s equally vital to prevent dynamic analysis, as described in the Dynamic Analysis & Tampering threat page.

If your mobile application operates online then it will ordinarily have some sort of authentication UI page. This allows your end users to sign into their account and access authorized data and services. This authentication page should be protected because it accepts and processes sensitive information from your end users such as credentials and verification codes.       

Another example of a sensitive UI page that needs protecting is a confirmation page that pops up when a user wants to proceed with a particular transaction. This is often the case in financial applications like mobile banking and electronic wallet apps. Malware usually targets these sensitive UI pages in order to steal information - often using overlays or a keylogger. So, we highly recommend you use a robust security solution for your app that enables you to:

For security-sensitive applications, it’s important you make sure that the execution environment where the app is running is secure and can be trusted. The presence of malware in the vicinity is never a good sign, and most applications are blind to its presence or what it’s targeting. And sometimes the OS doesn’t provide a way for your app to detect or prevent an attack. Scanning for malware can be a good countermeasure in this situation. In addition, malware that successfully obtains elevated privileges in the system may disable some essential device security features, so it’s crucial that your application checks for this too.

For example, in Android you can leverage frameworks provided by Google such as SafetyNet Verify Apps API. It instructs the system to query and scan for potential malware in the device and report back to your app and Play Integrity API to assess the given device’s security posture. This helps to make sure that no compromises like rooting or system hooks are made, which is crucial because malware often attempts to exploit OS vulnerabilities in order to gain elevated privileges or perform persistent code injection (including hooks) in the system. iOS apps can leverage Apple DeviceCheck to achieve the same thing.

For the most reliable malware detection, the app should perform its own checks on the device, scanning for known malware signatures according to an up-to-date database.