ADUPS is an Android "firmware provisioning" company based out of Shanghai, China. The software specializes both in Big Data collection of Android usage, and hostile app installation and/or firmware control. Google has blacklisted the ADUPS agent in its Android Compatibility Test Suite (CTS).

ADUPS recently compromised many BLU-phone models and was found to be directly transmitting call logs, SMS, contacts, location info, nd more from handsets within the US to Chinese servers using DES (weak) encryption.

The latest tablet from Barnes & Noble, the newly-released $49 BNTV450, has been found to include ADUPS. In the aftermath of the BLU data theft, ADUPS hostile data collection and control over Android may (or may not) be temporarily quelled, but harmful capability remains with the ADUPS agent. Devices running ADUPS should be considered under malicious control, and they should not be used with sensitive data of any kind.

The extent of the ADUPS BLU data theft was discovered and documented by Kryptowire, who learned that the ADUPS agent was capable of:

• SMS Recording

• SMS Transmission

• IMEI Exfilration

• IMSI (Transmission)

• Call Log Transmission

• Call Contact Information Transmission

• Location Collection and Transmission

• Command Injection

• Remote User Application Update

• Remote User Application Install

• Transmit List of Installed Applications

• Transmit order of application execution

• Programmatic Firmware Update

• Remote Execution and Privilege Escalation (without user notification or request)

• IP Address (Transmission)

• Name (*for contacts)

Significant subsets of this capability were exercised on individuals within the Unitied States, which was escalated to the Department of Homeland Security. A class action lawsuit investigation was launched against BLU by The Rosen Law Firm of New York, which is collecting class members and information for a damages assessment.

ADUPS itself has advertised on its own website that it is capable of:

• App push service

• Device Data Mining

• Unique package checking

• Mobile advertising

Azzedine Benameur, director of research at Kryptowire, regards any device running ADUPS to be permanently compromised. An ADUPS-enabled device should come with a disclosure that "owners can expect zero privacy or control while using it. Minus the spyware, it's a great [device.]" The hostile capability of ADUPS can be enabled any time, and it will not be flagged as malware by any scanner since the device vendor installed it as a fully privileged OS component.

In this climate, it was quite a surprise to discover ADUPS FOTA ("Firmware Over The Air") files on the latest Nook from Barnes & Noble—the $49 BNTV450:

u0_a76@st16c7bnn:/ $ find /system 2> /dev/null | grep -i adups
/system/app/AdupsFota
/system/app/AdupsFota/AdupsFota.apk
/system/app/AdupsFota/oat
/system/app/AdupsFota/oat/arm64
/system/app/AdupsFota/oat/arm64/AdupsFota.odex
/system/app/AdupsFotaReboot
/system/app/AdupsFotaReboot/AdupsFotaReboot.apk
/system/app/AdupsFotaReboot/oat
/system/app/AdupsFotaReboot/oat/arm64
/system/app/AdupsFotaReboot/oat/arm64/AdupsFotaReboot.odex

It might be noted that the BNTV450 is a clear departure for Barnes & Noble from its past OMAP/Snapdragon designs. The budget tablet appears to have been contracted to Shenzhen Jingwah Information Technology Co., Ltd., since erstwhile-partner Samsung does not manufacture Android devices in this price range. The latest tablet runs a processor from MediaTek, the MT8163 ARM Cortex-A53. MediaTek has been directly involved with ADUPS in evading Google security:

[BLU] phones were regularly sending bunches of personal information to servers in China: text messages, call logs, contact lists and so forth. After more investigation, it came to light that this was happening via a low-level piece of software called ADUPS.

When Google had previously updated its systems to check for ADUPS, MediaTek (they make the chipset in millions of low-end phones) simply modified their system software to evade Google's checks. Nice one MediaTek!

MediaTek has a history of protecting malware from Google security scans and is regarded as the worst chipset vendor in the Android community. Since the BLU data theft, MediaTek devices from several OEMs in the Russian market were caught with the preinstalled "Android.DownLoader.473.origin" malware. In the last 30 days, MediaTek's reputation has fallen calamitously.

It should also be noted that BLU devices infected with ADUPS had a "Wireless Update" entry in the Application menu that could disable the ADUPS agent. There is no such functionality in the BNTV450—ADUPS cannot be quelled by the user on this device.

Barnes & Noble should have realized that these were not trustworthy hardware and software partners.

It has been nearly a year since NowSecure last updated the Vulnerability Test Suite (VTS) for Android. Google has taken an unreasonably dim view of VTS and banned it from the Play store, but the scanner is invaluable for assessing the security status of an Android device.

Suprisingly, while the BNTV450 runs Android 6 Marshmallow (patch level September 5, 2016), VTS reports this device as vulnerable to CVE-2015-6616. It is extraordinary that a Mediaserver vulnerability of such age is found in a relatively new software release. The Stagefright/Mediaserver vulnerabilities were first revealed by Zimperium in July 2015, and their severity should have warranted greater attention.

For reference, the Moto G XT1028 with the latest software release runs Android 5.1 Lollipop and received its final updates in Q1 2016. VTS finds no vulnerabilities on this handset (although several critical vulnerabilities have been found since for which VTS does not probe, the most notible of which is Dirty Cow).

Realistically, the only safe way to use the BNTV450 would involve a format of the eMMC, and the installation of a third-party ROM, should one become available.

ADUPS has issued a total of four press releases, beginning on November 16, 2016:

• 2016/12/06 — Privacy Notice

• 2016/12/07 — FAQ

• 2016/11/23 — Updating Notice

• 2016/11/16 — Statement

The first and most important message in this collection is: "ADUPS sincerely apologizes to its partners and users."

Granted, that ADUPS as a corporate entity expresses regret, there are a number of points raised that are inconsistent with the reported narrative:

• ADUPS claims that a new upgrade of its agent (version 5.5) is no longer capable of extracting sensitive data. Credibility will require independent review and confirmation from a trusted security organization (that is, a source code review by Kryptowire, NowSecure, or Zimperium). "Buzz Lab" below is listed, but an organization within the United States is essentially required to establish credibility as this was the location of the theft.

• The BNTV450 appears to be running the following UNSAFE version of ADUPS: android:versionName="5.2.0.2.002". This was obtained by uploading the AdupsFota.apk file to http://www.javadecompilers.com/apk and examining the Android manifest.

• It is asserted that ADUPS "has been cooperating with Google," and further that "We released updated version for Adups FOTA 5.5 immediately, this version has been certified by Google Security Team and Chinese well-known third party organization Buzz Lab." (Google appears to think that "Buzz Lab" is a Boston video production company.) This requires a formal statement from Google that CTS no longer blacklists the relevant versions of the ADUPS agent, preferably along with their reasoning.

• ADUPS continues to collect IP addresses by their own admission in their latest documents. An IP address can be used to uniquely identify individuals, and the practice should cease immediately: "The only data that is collected through Version 5.5 (and subsequent updates thereof as appropriate) are basic device information and product model information, such as device type, platform, model, version, IP address, International Mobile Equipment Identity (IMEI), etc."

• ADUPS appears to have spent a significant amount of its corporate life behaving as a malware company. Why are we now advised to accept the new version of its agent as a valid member of the Android infrastructure community? Who vouches that it is appropriate for security-sensitive OTA updates?

• Kryptowire provided evidence that weak DES encryption was used on SMS messages prior to transmission. ADUPS disputes this with various statements: 1) "ADUPS utilizes https in the transmitting process and uses multiple encryption to ensure data safety." 2) "For example, all data transmission to the ADUPS server was carried out via secure HTTPS channels." 3) "Sensitive data such as SMS messages was further encrypted before the compression." 4) "All user data was compressed before transmission to the ADUPS server and the compressed data was transmitted over a secure HTTPS channel to an ADUPS web server." It is not sufficient to excuse the weak DES cipher with "https" in these statements—specifics are required. Was this TLSv1, TLSv1.1 or TLSv1.2? Did this use AES? Were the sessions configured for forward secrecy with DHE or ECDHE? Was an AEAD cipher used? Did compression introduce the risk of a CRIME attack? What are the scan results from ssllabs.com on the relevant server components? These statements cannot be accepted without far greater detail.

• Among other claims of what was not included in the dataset, "The users' contact list was also not part of the collected data." This also requires independent verification, preferably from Kryptowire.

• Air-gap isolation appears to be asserted: "Specifically, the data storage server is located in a Tier 4 data center and is physically isolated from external contact." However, a firewall is later mentioned: "All ADUPS data storage servers are located within the ADUPS internal network that is protected by a firewall." Was the data storage attached to a network, or not?

• ADUPS should post the session logs supporting this statement: "After ADUPS was contacted by BLU Products regarding the data collection issue on October 28, 2016, ADUPS promptly wiped all cell tower ID data, and call and SMS data from its server."

• ADUPS is headquarted in Shanghai, but also lists physical locations in Shenzen, Taipei, and New Delhi. The data server, however, is located in Hong Kong. What jurisdictions have touched this data, and could be involved in legal action concerning a breach? "ADUPS' server for overseas users is based in Hong Kong which has stringent data protection laws."

Are the statements above enough to trust the new ADUPS 5.5 agent? Regulatory authorities have yet to speak.

Advice for several players in this malware advance is forthcoming.

To Barnes & Noble, your devices with production software should be reviewed by security specialists before a release to manufacturing. Had Kryptowire, NowSecure or Zimperium assesed the security of this Android release, they would certainly have halted attempts to market an Android version with blacklisted malware and an open CVE. Far better to miss the Christmas sales season than to see your customers' vital data in a Chinese database beyond your jurisdiction.

To ADUPS, you must relinquish total control of your Android community, especially in the United States. Our privacy must be beyond your temptation.

To MediaTek, if you respect your customers, you will be welcome. If you abuse your customers, you will be banned from our shores.

And Google, as the master of this puppet show, the quiet withdrawl of the Android Update Alliance did not go unnoticed, and 18 months of patches is far, far too short. Enterprise Linux easily commits to 5-year support cycles. The Pixel is not and cannot be the solution for Android's annus horribilis of 2016, and there is nothing in Google's corporate actions to lead us to believe that 2017 will be any better.

In any event, case number 78952613 has been opened with the Federal Trade Comission on this issue.

Android is fast escaping the management ability of its owners. If we are not yet at the point of nationalizing this critical resource and managing AOSP by congressional control, then we are quite close.

*Disclaimer, the views and opinions expressed in this article are those of the author and do not necessarily reflect those of Linux Journal.