CVE-2023-33293 was published today, outlining an information disclosure concern with api-daemon whereby websites can determine what apps and which versions are installed on KaiOS 3.0 and 3.1 devices.
Why it matters? KaiOS 3.0 & 3.1 users in the US are disclosing what apps and which versions they have installed to websites they visit.
What can attackers do with this vulnerability?
Attackers can use the list of installed applications and versions to create digital fingerprints for tracking users. This information can also allow hackers to craft targeted phishing campaigns. For instance, if a malicious website knows that you have LocalBack v1.0.3 installed they can craft a more compelling call to action like, “We blocked unauthorized access to your account, please reset your LocalBank password here,” and redirect the user to a website that they control.
Background
KaiOS 3.0 was first released in September 2021 with the Alcatel Go Flip 4 and TCL Flip Pro as the successor to KaiOS 2.5. To date, it is only available on devices in the United States. Runtime analysis the Alcatel Go Flip 4 (carrier: MetroPCS, model: 4056Z) was performed to identify vulnerabilities to enable Developer Tools to debug KaiOS applications using the USB Debugger in Firefox. As of the time of writing (May 2022), no commercial KaiOS 3.0 or 3.1 device has DevTools enabled. However, the process uncovered other vulnerabilities.
Technical Details
The KaiOS operating system comes with the
api-daemon binary exposing a local web server that responds to HTTP requests on port 80 under the hostname localhost. It is meant to provide platform-specific APIs in a package decoupled from the rest of the operating system, allowing for updates outside of Over-the-Air (OTA) updates published by OEMs. This server also exposes subdomains for each installed applications, http://myapp.localhost, as well as the reserved hostname cached.localhost for cached Progressive Web Apps (PWAs). Additionally, the pre-installed system app Shared is available at shared.localhost, providing a bundle of shared system resources. These loopback addresses can be used to fetch assets that are part of the application’s bundle.
How It Works
An attacker can make fetch requests to determine if a given app is installed. Given that KaiOS 3.0 has about ~400 apps available, it is feasible to replicate the process to return all installed apps. Exposing whether the user has a given app installed can be used for digital fingerprinting as well as targeted phishing. Additionally, because the manifest is returned in the HTTP response with proper CORS headers, it is also possible to extract additional information such as the app version.
Example
The example below will check whether my application,
PodLP, is installed on a KaiOS 3.0 or 3.1 device. The fetch call will resolve to a Promise that returns the application name and version. This promise will reject with an error on non-KaiOS devices or devices without PodLP installed.
1fetch(`http://podlp.localhost/manifest.webmanifest`)
2 .then((r) => r.json())
3 .then((r) => ({ version: (r.b2g_features) ? r.b2g_features.version : undefined, name: r.name }))
Recommended Mitigation
api-daemon should check the Origin header and only return valid responses for the same origin, or to shared.localhost. These checks could be further extended to encompass standards like
Digital Asset Links validation used by Android and iOS to allow a website to check if related apps are installed. This approach is more robust and would allow websites, not just apps, to check if their corresponding app is installed.
Conclusion
Given that KaiOS 3.0 only has ~400 applications available for install, the majority of which are games, this is unlikely to pose a significant threat. However, it highlights the broader need for same-origin checks and placing restrictions on the information that local services are inadvertently sharing with apps and websites.