|Jul / 20 / 2017|
|Zoltan Balazs, @zh4ck|
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
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.
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
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.
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.
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.
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.)
Result of re-test
Re-test confirmed that the upgraded version displays a warning to the user, when being initialised on a rooted device.
Testing revealed that the application does not utilize certificate pinning. Instead, it utilizes the OS CA store.
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.
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.
Testing revealed that an intercepting attacker or a piece of malware can avoid being detected by changing the submitted hash values.
An intercepting attacker is able to change the URL or the returned reputation value, therefore effectively to disable the URL checking feature.
It is recommended implement certificate pinning on all SSL connections.
Re-test confirmed that the updated version refuses to connect to endpoints providing unpinned SSL certificate chain.
Testing revealed that the “allowBackup” directive is missing from the AndroidManifest.xml file, leaving the setting on default.
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.
It is recommended to disable backup by setting the allowBackup setting to ‘false’. For further information, refer to the Android developer portal.
Furthermore, it is also recommended to apply the countermeasures in 2.4.
Analysis revealed that the affected setting has been adjusted.
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.
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.
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.
A re-test confirmed that the plain text entries have been eliminated from the affected database.
Regarding the limitation of Android AntiVirus scanners, please refer to our blog post.