The insecure implementation of the OTA (Over-the-air) update mechanism used by numerous Android phone models exposes nearly 3 million phones to Man-in-the-Middle (MitM) attacks and allows adversaries to execute arbitrary commands with root privileges.
The vulnerable OTA update mechanism is associated with Chinese software company Ragentek Group, which didn’t use an encrypted channel for transactions from the binary to the third-party endpoint. According to security researchers at AnubisNetworks, this bug not only exposes user-specific information to attackers, but also creates a rootkit, allowing an adversary to issue commands that could be executed on affected systems.
The code from Ragentek contains a privileged binary for OTA update checks as well as multiple techniques to hide its execution. Located at /system/bin/debugs, the binary runs with root privileges and communicates over unencrypted channels with three hosts. Responses from the remote server include functionalities to execute arbitrary commands as root, install apps, or update configurations.
The issue, tracked as CVE-2016-6564, is that a remote, unauthenticated attacker capable of performing a MitM attack could replace the server responses with their own and execute arbitrary commands as root on the affected devices.
Similar to the issue found in Android devices running firmware coming from Shanghai ADUPS Technology Co. Ltd., the bug in Ragentek’s Android OTA update mechanism is included out of the box. The two issues aren’t related, but they are similar to a certain point, as both allow for code execution on smartphones. The ADUPS firmware was found to siphon user and device information in addition to allowing the remote installation of apps.
The CERT advisory associated with this vulnerability reveals that multiple smartphones from BLU Products are affected, along with over a dozen devices from other vendors, namely Infinix Mobility, DOOGEE, LEAGOO, IKU Mobile, Beeline, and XOLO. BLU is said to have already issued a software update to resolve the issue, but the remaining devices might still be affected.
While analyzing the bug, AnubisNetworks discovered that the unencrypted data transmission starts soon after starting the first-use setup process, and that the inspected device, a BLU Studio G, attempted to contact three pre-configured domains. Two of them were unregistered and the researchers acquired them, which provided them with visibility into the population of affected devices.
This also provided security researchers with the ability to check the type of commands that are supported in the vulnerable setup. One of the interesting findings was that an explicit check was created to mask the fact that “/system/bin/debugsrun” and “/system/bin/debugs” were running. Their presence would be hidden or skipped in the user output, the researchers also say.
Deeper analysis revealed that the Java framework too has been modified to hide references to this process. The researchers found a modified next() method in the core java.util.Scanner class to exclude references to the aforementioned binary names and say that the nextInt() method was modified to always return a pid of 10008 for the processes. What’s more, the local sqlite database that the binary logged events, stored system and user information and fetched from, was located at /system/bin/unint8int, the researchers reveal.
Although the researchers have no explanation on why the author of the process attempted to purposely hide the presence of both the process and local database on the device, they do say that the attempt wasn’t a comprehensive one.
Overall, over 2.8 million distinct devices, across around 55 reported device models, were observed connecting to the researchers’ sinkholes. Interestingly enough, some of the provided device models couldn’t be linked to real world devices, and the security researchers included all of them in an “Others” category.