Remote Deactivation of AVIRA App Scan Engine
- Vendor: Avira
- Product: Avira Antivirus Security for Android (https://play.google.com/store/apps/details?id=com.avira.android)
- Affected Version: 4.2 , Platform Build version 5.0.1-1624448
- Severity: medium
- Short summary:
The update traffic at install time or requested by user is handled by an unprotected and unauthenticated http connection. A man-in-the-middle attacker, controlling a WI-FI access point can exchange a binary file (.so) with a “corrupted” file, which deactivates the scan engine without user knowledge (denial of service).
An attacker can deactivate the Avira scan engine (libaescn.so file) by overwriting it with a non-binary
file. The engine will not run any longer and will deliver an error to the log interface:
E/Avira Mobile Security( 2257): Antivirus - Failed to initialize scan
engine - Error = 121
E/Avira Mobile Security( 2257): Antivirus - Rolling to backup
The user interface on the application layer does not interpret or handle error messages from the scan engine layer. As a result the application shows still a scanning task to the user without any critical findings. The overwriting of the libaescn.so by an attacker can be done as follows:
Because of a missing integrity check of the aengine-arm_linux_androideabi-int.info file, an attacker can add an additional section:
In this scenario the injected libaescn.so file will be loaded a second time and overwrite the original libaescn.so binary. The Update engine checks the signature of the downloaded .so file, so the injection of a remote Binary (remote code) injection is currently not working. But if we use for instance another signed Avira file with textual content like the aevdf.dat file and rename it to libaescn.so it will bypass the signature verification and overwrite the libaescn.so, previously loaded with textual content. After that the native code layer cannot load the file as binary anymore and returns the Error = 121 code.
It is also possible to locally exchange the libmavapi.so file by another native code binary, which will be executed instead by the scan engine. But currently we did not find a solution to inject this file remotely or by another app without breaking the sandboxing (e.g. root application).
Avoid public or unknown Wi-Fi hotspots (access points) or use them only through a trusted VPN connection.
Proposals of a vendor fix can be done using different approaches: (1) transfer the file(s) using a protected SSL (HTTPS) connection and/or (2) establish a correct signature process for the configuration files and the downloaded files to prevent modification of the files.
- 2015-10-10 Vulnerability Discovered
- 2015-10-22 Vulnerability Reported
- 2015-11-03 Vulnerability Fixed