Flicky: Subverting Android TV App Store Control

Analysis of Unconstrained Sideloading Vector on Android TV Platforms

Our team has analyzed a technique for bypassing vendor application store controls on Android TV and derivative platforms (e.g., Amazon Fire OS). This methodology leverages a legitimate, open-source F-Droid client known as “Flicky” to facilitate the installation of arbitrary packages, effectively creating a persistent sideloading channel that subverts platform-native security models. While the tool itself is not malicious, its architecture provides a blueprint for threat actors to achieve code execution and persistence on hardened IoT devices.

Vulnerability Summary

• Identifier: CVE-2025-48151 (Theoretical assignment for tracking purposes)
• Description: A procedural weakness in Android TV’s permission model, where user consent to install a single third-party application installer (e.g., Flicky) can be leveraged to create a trusted channel for subsequent, unvetted package installations. This bypasses the security curation of vendor-controlled application stores like Google Play or the Amazon Appstore.
• CVSS 3.1 Score: 7.8 (High)
• Attack Vector: Local / Physical
• Affected Versions: All Android TV and Fire OS devices where “Install unknown apps” permission can be granted.
• Impact: Arbitrary Code Execution, Persistence, Defense Evasion.

Technical Analysis

The attack chain relies on abusing the trust established by a user-friendly interface to deploy payloads from an attacker-controlled software repository. The analysis assumes the threat actor has achieved initial access to the device, typically through physical access or by convincing a user to enable developer mode and sideload the initial Flicky APK via the Android Debug Bridge (ADB).

Initial Access and Execution

The initial foothold is established by loading the Flicky client onto the target device. In a targeted scenario, an attacker with brief physical access could enable developer options and use ADB to push the installer package. This action falls under T1059.006: Command and Scripting Interpreter: Python if using a helper script, or more broadly, T1574.002: Hijack Execution Flow: Sideloading.

adb install flicky-v3.7.2.apk

Once installed, the Android OS requires the user to grant the `REQUEST_INSTALL_PACKAGES` permission to Flicky. This is a critical control point, but the application’s legitimate purpose (installing F-Droid apps) makes this request appear benign to the user. Upon granting this permission, Flicky becomes a privileged installer, acting as a proxy for the attacker to deploy further payloads without repeated, high-friction security prompts.

Payload Delivery via Custom Repositories

The core of the technique is Flicky’s ability to add third-party F-Droid repositories. An attacker can host a repository containing a malicious APK, weaponized to act as an implant. The Flicky client, by design, will connect to this repository, parse its index file (index-v1.jar), and present the malicious package to the user as a legitimate application, complete with a custom name, icon, and description. This is a classic supply chain attack vector, classified under T1195.002: Supply Chain Compromise: Compromise Software Supply Chain.

The user, operating within the trusted UI of Flicky, initiates the installation. Flicky fetches the package and uses the `PackageInstaller` API to execute the installation. Since the user has already granted installation rights to Flicky, the OS proceeds with the installation of the attacker’s payload, effectively bypassing Google Play Protect’s standard verification chain for store-based applications.

Post-Exploitation and C2

Once the malicious package is installed, it can establish persistence using standard Android mechanisms, such as a `BOOT_COMPLETED` broadcast receiver (T1547.001: Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder, Android equivalent). We have observed in our lab that legitimate networking tools like Tailscale, which are often unavailable in official TV app stores, can be bundled or leveraged by the implant. By embedding a Tailscale client, the implant can create a persistent, encrypted WireGuard tunnel back to an attacker-controlled network, effectively using a legitimate service for Command and Control (T1071.004: Application Layer Protocol: C2 Over Existing Web Service). This C2 channel is difficult to detect as it masquerades as legitimate VPN traffic and does not require opening inbound ports on the target’s local network.

Proof of Concept (High-Level)

An operator can replicate this technique by following these steps:

1. Compile a simple Android implant (e.g., a reverse shell) into an APK.
2. Set up an F-Droid compatible repository using tools like `fdroidserver` and host the malicious APK.
3. Gain temporary access to a target Android TV and use ADB to sideload the legitimate Flicky client (version 3.7.2 was used in our analysis).
4. Manually add the URL of the attacker-controlled repository to the Flicky client’s settings.
5. From the Flicky UI, browse to the malicious app and select “Install.” The user will be prompted by the Android OS to confirm, but the request originates from the already-trusted Flicky app.
6. The implant executes, establishes persistence, and initiates a C2 callback.

Detection Opportunities

Detecting this activity requires a defense-in-depth approach, as the individual actions appear legitimate in isolation.

• Host-Based: Security teams should audit for the presence of non-standard application installers or repositories on managed devices. The existence of the `de.mlm.flickystart` package name is a strong indicator. Monitoring applications granted the `REQUEST_INSTALL_PACKAGES` permission provides a critical choke point for detection (T1548.004: Abuse Elevation Control Mechanism: Elevated Execution with Prompt).
• Network-Based: Egress traffic from IoT devices like Smart TVs should be closely monitored. Anomalous DNS requests for unknown F-Droid repository domains or unexpected, long-lived UDP connections (indicative of a WireGuard tunnel for C2) should trigger an alert.
• Configuration Management: Enforcing policies that disable Developer Mode and ADB access on production devices is the most effective preventative measure against the initial access vector required for this attack chain.