Webroot SecureAnywhere Android AV coordinated disclosure

Researchers of MRG Effitas tested the Webroot SecureAnywhere Android application. During use, we came across implementation details, which might undermine the Vendor’s efforts to provide a comprehensive mobile security solution with the potential to aid users in case of encounters with malware.

Testing covered the following application version.

Application name Webroot SecureAnywhere

Store URL https://play.google.com/store/apps/details?id=com.webroot.security

Version 4.1.0.8032

We considered the situation and opted for a coordinated disclosure approach to aid the Vendor in their efforts. In accordance with industry standards, we disclose the issues based on Google’s 90-day policy. As a result, after a 90-day plus a 14-day grace period, we make the discoveries public. For further details, refer to the following URL.

https://security.googleblog.com/2014/07/announcing-project-zero.html

https://googleprojectzero.blogspot.hu/2015/02/feedback-and-data-driven-updates-to.html

Important dates:

2017. 04. 05: Vendor notified

2017. 04. 05: Vendor reply, they are investigating

2017. 04. 14: Vendor acknowledges the issues and provides us their plan to fix the product

2017. 06. 11: Vendor sends us the updated product

2017. 06. 26: We verify all issues have been fixed

2017. 07. 20: Publishing of this blog post

2 Vulnerability details

2.1 No user warning on rooted/compromised devices

Finding

Testing discovered that the application was normally installed and initialized on a rooted test device, provided with a dynamic hooking framework application (xposed framework). This scenario is a highly insecure one, as the hooking framework can be utilized to bypass every security measure of the Webroot SecureAnywhere application. This is by no means something that an Android security suite can be properly prepared for, nevertheless no user warning has been displayed.

Risk

As a result, a highly sophisticated piece of malware using dynamic hooking might even abuse the SecureAnywhere application to convince the user that there are no threats on the device. Note that no cloaking has taken place and as per the logs, the Xposed installer application has even been scanned by the SecureAnywhere application.

Consider the following scenario.

1. The Android device with no preliminary protection, gets infected by a highly sophisticated piece of malware.
2. The users suspects that there might be something going on and opts for the SecureAnywhere suite to run a security scan on his device.
3. Upon installation and scanning, no warning is displayed and the user is reassured that his device is clean from malware.

Recommendation

It is recommended to at least warn the user in such clear cases that there might be something going on with his device and that the scan results are not trustworthy in any way.

Nevertheless, it is important to point out that reliable root detection is theoretically impossible in untrustworthy environments (such as a user controlled Android device). When it comes to root detection, false positive errors are rather uncommon, however false negatives are more dangerous from security perspective. It is possible to install readily prepared tools to fool common root detection methods (e.g. RootCloak), however, presence of the Xposed installer and the RootCloak application itself is a good indication that the device has been rooted. All in all, a comprehensive approach is recommended, where the user is notified at the slightest sign of deviation from a ‘clean’ device state.

As an alternate approach, it is possible to harden the application itself to detect tampering (both off-line patching plus re-packaging and runtime hooking) to some extent. Should any of the below checks fail, assume that the environment is tampered with and notify the user. Note that even a careful implementation of all below methods can only raise the bar in terms of attacker skill, motivation and expertise, it can deter and detect novice users, who solely rely on off-the-shelf tools.

1. Upon startup, check if the package has debug mode enabled.
2. Regularly check the signature and the signing key of the app package if it deviates from an expected value.
3. List the calling stack of security related methods (such as certificate pinning, root detection etc.) Should the RootCloak tool be used, the calling stack contains elements that are clearly not from the originating application.

Figure 1 Evidence of dynamic hooking based tampering

For further information, refer to the following whitepaper (An Android Application Protection Scheme against Dynamic Reverse Engineering Attacks. Lim, Yeong et al. Journal of Wireless Mobile Networks, Ubiquitous Computing, and Dependable Applications, issue September 2016.)

http://isyou.info/jowua/papers/jowua-v7n3-3.pdf

Result of re-test

Re-test confirmed that the upgraded version displays a warning to the user, when being initialised on a rooted device.

Figure 2 – Warning displayed on rooted devices

2.2 No certificate pinning

Finding

Testing revealed that the application does not utilize certificate pinning. Instead, it utilizes the OS CA store.

Risk

As a result, it is trivial to bypass certificate validation using various methods (e.g consider a social engineering attack, where the user is asked to install a certificate authority on his Android device). Considering the fact that mobile security suites are intended also for non-security conscious users, this design consideration should be re-evaluated.

The risk is increased by the following factors, which mean that this single design decision might undermine the purpose entire suite.

1. The application provides ‘remote wipe’ and ‘remote lockdown’ features. The implementation of the services involves a HTTP communication flow between the remote server and the lost/stolen device. Testing revealed that the following HTTP message enforces the PIN change.

The request is followed by the response, which adjusts the new PIN.

An analysis of the response revealed that the new PIN is set in the ‘commandData’ field:

As a result, it is possible for an intercepting attacker to hijack the remote PIN change process and thus enforce a new PIN without knowing the current one.

2. When a new package is installed the hash of the package is checked              from a reputational perspective within Webroot’s cloud service.

An intercepting attacker is able to change the URL or the returned reputation value, therefore effectively to disable the URL checking feature.

Recommendation

It is recommended implement certificate pinning on all SSL connections.

Re-test results

Re-test confirmed that the updated version refuses to connect to endpoints providing unpinned SSL certificate chain.

Figure 3 – SSL error displayed

2.3 Missing Allow-Backup Directive in AndroidManifest.xml

Finding

Testing revealed that the “allowBackup” directive is missing from the AndroidManifest.xml file, leaving the setting on default.

Figure 4 Excerpt from the AndroidManifest.xml

Risk

In most Android versions, this means that the application sandbox can be backed up to various cloud service providers and 3rd party backup software. Considering the fact that the application maintains traces of user activity in plain text format within the sandbox, this design might result in privacy breach.

Recommendation

It is recommended to disable backup by setting the allowBackup setting to ‘false’. For further information, refer to the Android developer portal[1].

Furthermore, it is also recommended to apply the countermeasures in 2.4.

Re-test results

Analysis revealed that the affected setting has been adjusted.

Figure 5 – Backup disabled

2.4 Traces of user activity stored in plain-text format

Finding

Testing revealed that the Webroot application maintains traces of user activity within the sandbox. For instance, the %sandbox%/databases/appinfo.db discloses every application that has been installed since the initialisation of the Webroot suite, even if the application has been removed from the device.

Figure 6 Traces of user activity in plain-text format

Risk

An analysis of the application sandbox reveals information regarding user activity (e.g. the names of installed applications). The risk is influenced by the following factors.

• The risk is increased by the fact that the application maintains the log, even in case the device is rooted.
• The risk is increased by the insecure setting of the ‘allowBackup’ directive in the manifest.

Recommendation

It is recommended to encrypt all trace of user activity, even within the sandbox. Furthermore, the user should be provided with options to delete all traces of his activity from the sandbox using the application GUI.

Re-test results

A re-test confirmed that the plain text entries have been eliminated from the affected database.

Figure 7 – Contents of the appinfo.db file

[1] https://developer.android.com/guide/topics/manifest/application-element.html

Regarding the limitation of Android AntiVirus scanners, please refer to our blog post.