Stephan Huber (Fraunhofer SIT Darmstadt) and Siegfried Rasthofer (TU Darmstadt) discovered a security vulnerability in versions 2.0.0 – 2.0.5 of the security tool AppGuard Pro. A few weeks ago, we informed the vendor Backes SRT who has now fixed the vulnerability in the latest release. The vulnerability gives malicious apps full control of all settings in the AppGuard Pro application. The vulnerability not only allows such apps to bypass any and all of the tool’s security measures, on top of that the malicious apps can even misuse AppGuard Pro to convince the user into perceiving the malicious app as harmless. Users should download the update as soon as possible.

AppGuard Pro

Before we start describing the vulnerability and also how a malicious application could control AppGuard, we first want to describe the general mechanism of AppGuard Pro.

The permissions system of Android does not allow rejecting single permissions requested by an application.  To install an application, the user instead has to accept all permissions the app requests.  To protect private information it could be useful to deny the access to private information by revoking a permission. AppGuard Pro is an Android application that enables the user to revoke permissions by using in-memory code modification and runtime monitoring. On the technical layer, AppGuard Pro does not really remove the permissions from an application. Instead it inlines a runtime monitor into the application’s binary code in memory.  The monitors are controlled by the AppGuard Pro application itself. The user can allow or disallow access to different private information by setting the monitor configuration. More detailed information is described in the research paper of Backes et al. The AppGuard Pro version is in the market  as a paid-app by the Backes SRT GmbH and cost 3,99 € in the Google Play store (currently not available).

The two screenshots above show the UI of the current AppGuard Pro (v. 2.0.5). The left screenshot shows some information about the “Security Status” of the user’s mobile device. Under recommended apps, a user sees a list of apps that AppGuard recommends to be monitored, because their risk score is very high (10 is the highest). This risk score is a metric based on the kinds of permissions the app requested at install time. The right screenshot shows an app (DB Navigator) that a user monitors using AppGuard. In this case, the user chose to revoke the “full network access” and “read your contacts” permissions. Furthermore, it is also possible to whitelist or blacklist the access to URLs (screw wrench next to the “full network access” permission). If the user revokes an application’s permission, the runtime monitor will usually replace the respective private information with some fake information (does not work with all data). The following two screenshots shows the original (left) and the corresponding fake information (right), as displayed by a hand-written test app:

The problem

Each application which is monitored by AppGuard has to know the user settings (e.g., permission revoked or white-/blacklisted URLs), provided by the AppGuard UI. These settings are stored in different ContentProviders. These ContentProviders can be seen as an intermediate layer/interface accessing the configuration database containing the monitor settings for each observed/monitored app:

The Content Provider has to be secured in such a way that every monitored app can read the user settings but only AppGuard Pro can write them. In AppGuard Pro, exactly this setting was incorrect:

The problem in the versions 2.0.0 – 2.0.5 was an unprotected content provider in the AndroidManifest.xml. On Android 4.1.x and earlier, content providers were visible to all other apps by default. With Android 4.2, this default was changed to a safer setting, by default making content providers visible only to the “owning app”. Apps can override this default with a flag android:exported=”true”, which was set in AppGuard Pro! If this flag is set, this gives all applications the possibility to access the providers URI, both reading and writing. Restrictions like read or write permission should prevent such public access. Unfortunately, this was not the case in AppGuard Pro and most of the settings had write access. This gives an attacker the possibility to manipulate the values of the database. The most important settings that are manipulatable are:

• Change of app’s name: This gives an attacker the possibility to fake the name of an application
• Change risk value: This gives an attacker the possibility to create a malicious app but AppGuard would provide a lower security risk.
• Set app to monitor state: An attacker could fake the “monitored” state of an app. This causes the situation that a user is mislead to believe that the app is monitored (e.g., revoked contact data permission), although it is not.
• Change whitelisting-settings: An attacker could change the white-/blacklisting settings of URLs.
• Set permissions: If a user revokes a specific permission, an attacker could grant the permission and vice versa.

The following video shows these capabilities in detail. (Note that, coincidentally, the scoring mechanism in AppGuard Pro rates our “attack” app as benign.)

What is the Attack Mode?

There are a few possible attack modes:

An attacker can develop a malicious applications with “dangerous” permissions but hide these from AppGuard with the “low risk score attack”. Furthermore, the malicious app can increase the risk score value of the other applications to keep a low profile. In result, even if the malicious app might have looked somewhat dubious to the user, through the attack the user might be given a false confidence that the app is benign.

It is also possible that this malicious application makes a DoS-attack agains AppGuard Pro because permissions revoked by the user can be immediately identified and granted again. In result, it is not possible for a user to secure any of her apps!

If a user blacklists some URLs for connecting to those, the malicious application can revoke this settings and thus allow the sending of sensitive data to a malicious server!

How can this vulnerability be fixed?

After discovering the vulnerability, our team reported the vulnerability to Backes SRT at once. The development team confirmed the vulnerability on the same day, and has now, after several weeks, provided an update.

Coincidentally, just a few days before our discovery, AppGuard Pro was removed from Google’s Play Store. By losing the listing in the Play Store, AppGuard Pro also lost its most important update channel. Right now, we therefore strongly advise users of AppGuard Pro to download the latest version of AppGuard Pro from this download site.

Cross-posted from SEEBlog