5 April 2022
Although the usefulness of security tools such as Antivirus, VPN and EDR is now indisputable in business circles, these solutions often need a lot of privileges and permissions to work properly, also making them an excellent target for an attacker. The presence of a bug in one of these types of solutions could allow a malware to elevate its privileges and cause more damage to the organization.
Recent research at Orange Cyberdefense (previously SCRT) has been greatly motivated by the paradoxical idea of attacking security solutions. Could these solutions that are supposed to protect the system and block attackers be abused by an attacker to gain even more privileges on the system?
While doing some research on the subject, I discovered the awesome work already initiated by several security researchers in 2020. We can cite for example the blog posts from CyberAks Lab on common security bugs in Desktop Antivirus products or also the Orange Tsai research on SSL VPN providers. Among the various articles, I did not find any mention about mobile antivirus applications. Are they more secure? Or does no one care about them?
Over the last decade, smartphone usage has grown exponentially whether for personal or professional use. Due to this increasing need for mobility and ease of use, we are seeing more and more applications and activities related to work on an employee’s personal devices (Mail,VPN,Contacts,Documents..).
Malicious actors have understood this and we are also seeing an increased volume of malware distribution on mobile platforms compared to previous years.
Security companies have also taken the turn and have started to develop mobile anti-malware protection solutions which surprisingly seem to be used quite a lot.
Here are some of the most downloaded Antivirus Mobile apps on Android:
The Android operating system (OS) is based on a modified version of the Linux Kernel. The whole system is designed with a defense in depth approach from the lowest layers with hardware-assisted encryption and key handling to the highest application security layers with Sandboxing or Storage Access.
This section will mainly focus on the OS and application security measures, further information about other security features can be found directly in the Android Security Paper.
All Android applications are executed in an application sandbox. The OS takes advantage of the SELinux protection to maintain isolation between the application resources (Data and Code execution). Each application runs in its own process and is assigned with a unique user ID (UID). The applications are therefore not allowed to access other apps files and resources as on Linux each user is isolated from each other.
On Android, every access is denied by default (Access to external storage, Telephony Stack..). When an application needs a special access, it must ask for the permission. We can distinguish 2 types of permissions: Linux Permissions and other Android Framework Permissions.
However, if we look at the permission documentation we can see a lot of other permissions that are not present and mapped to a special GID.
The Inter Process Communication mechanisms are used to allow the apps to offer some services or features to other processes/applications. Each app should explicitly define what features they want to expose to other apps. In general, developers tend to use high-level IPC abstractions such as Intents, Content Providers, Messengers..
Finally, from an attacker point of view, all of these IPC mechanisms are interesting targets as they offer the possibility to interact with higher privileged processes/applications.
Most of this information about Application Components, Permissions and exported features are defined in the AndroidManifest.xml file of each application. This file describes all essential information about an android application.
Knowing about Android’s security model, I quickly wondered what these antivirus apps really do and if they do it correctly. This research started in June 2021. At the same period, some of my colleagues were already doing security research on other McAfee products. This partly guided my choice and defined my first target: The ‘McAfee Security: Antivirus VPN – 188.8.131.52’ application which was the lastest release at the time.
Looking at the McAfee AndroidManifest.xml it is possible to quickly get an overview of the current attack surface and app privileges (though the requested permissions).
By analyzing the permissions, we quickly realize that the application requires a lot of permissions on the system, which makes it an even more interesting target for a malicious application. In total more than 70+ different permissions were defined including permissions deemed as dangerous.
To get an overview of the attack surface, it is interesting to look at all components that allow IPC with other applications without any special permission (or with a misconfigured permission).
By default, any external application installed on the system can directly interact with a component of another app if this component:
Actually, prior to Android 12, all components (activities, services, and broadcast receivers) with a declared intent-filter were automatically exported by default. In Android >= 12, all components must explicitly be declared with the android:exported attribute.
The AndroidManifest.xml of the Mcafee application reveals that several components can be called by external apps.
As an example the com.mcafee.activity.MainActivity component is exported:
This component is an activity which is started following the standard activity lifecycle. As a result, one of the first methods which is called is onCreate().
This onCreate() method in turn calls the method u().
Using this code, it is possible to start arbitrary components with arbitrary extras within the context of the McAfee application.
Here is a simple code example of a malicious application (installed without any permissions) that leverages the McAfee Security: Antivirus VPN application vulnerability discovered to use the “android.permission.CALL_PHONE” permission and call a random number.
Since the activity is started from the context of the McAfee application, this issue can be leveraged to access Content Providers and all kinds of non-exported components with all the permissions defined by the target.
Again, it’s quite surprising for a security product to introduce such bad practices (using so many permissions) and to have a vulnerability of the sort directly in the Main Activity. It shows a certain negligence that really calls into question the usefulness of having certain antivirus applications on mobile phones. However, research done on other McAfee products showed similar results and will warrant another blog post altogether.