Summary

Some mobile apps offer a feature to share local device content to other devices using the Cast or AirPlay protocols. Some apps implement this feature, in part, by running a web server that provides access to local files.

Other devices on the network can access these web servers running on a mobile device. An improperly configured server can provide access to user-downloaded files or internal app files, which results in security and privacy impacts.

In the most extreme scenarios, a misconfigured web server allows remote data exfiltration over the Internet with no user interaction or with a single malicious HTML file download.

I was able to identify at least one app with this vulnerability.

Vulnerability details

When implemented insecurely, these web servers can leak sensitive data to:

• other apps on the device (see attack scenario 1)
• attackers over the local network (including public and office networks; see attack scenario 1)
• attackers over the Internet (no user interaction under certain conditions; see attack scenario 2 and attack scenario 3)
• casual physical attackers (useful when app is passcode-protected; see attack scenario 4)

Leaked data can include:

• User data, such as created or downloaded files
• Configuration files with user-specific data
• Logs with sensitive information, usage data, and details of device hardware and software

Exposed data can identify a user if it's sufficiently unique or detailed. File contents can expose sensitive information about the user and their app usage. File contents and directory listings can also provide a unique fingerprint for tracking or identification purposes.

If the app has passcode protection, and the web server is turned on before the user enters a valid passcode, the passcode protection can be bypassed by making requests to the web server directly. App passcode bypass is most useful for casual physical attackers when the device itself does not have a passcode, but network attackers also benefit from this bypass.

Behaviors that increase impact

Some apps and their web servers may have the following behaviors which increase the impact of this vulnerability, especially over the Internet:

• Directory listings
• Predictable file names
• HTML file rendering and serving attacker-controlled files
• Unnecessary files

Directory listings

Web servers with directory listings remove the requirement of knowing specific file names or paths, which helps attackers identify valid URLs if file names aren't predictable or vary between targets.

Directory listings allow attackers to list and access data over the local network with no user interaction (extremely common; see attack scenario 1).

Directory listings also allow remote attackers to list and access data over the Internet:

• with no user interaction, if the web server is directly accessible over the Internet (uncommon but observed in the wild; see attack scenario 3)
• after a user downloads a single malicious HTML file, if the web server allows rendering of user-downloaded HTML files (see HTML file rendering and attack scenario 2)

Predictable file names

Predictable file names also help attackers identify valid URLs, especially if there are no directory listings.

For example, app developers should ensure user downloads aren't sequentially numbered. If possible, rename the files so the original file names are only known to the app while using hard-to-guess file names in the filesystem.

The impacts of predictable file names are similar to those of directory listings; they allow attackers on the local network and over the Internet to perform attacks with no user interaction or limited interaction.

HTML file rendering and serving attacker-controlled files

If a web server serves user-downloaded files, it can also serve user-downloaded files that contain malicious payloads. If the web server serves a file with the header Content-Type: text/html, the web browser renders the file as an HTML page. When the downloaded HTML file is accessed through the web server, JavaScript in the page has access to all other data in the same origin (http://127.0.0.1:{port}).

This allows attackers over the Internet to target any user with remote data exfiltration attacks, since this method does not require direct access to the web server.

Remote data exfiltration targeting any user is possible if the following conditions are met:

• File names and paths of data is known (through directory listings or predictable file names)
• Downloaded files are accessible through the web server
• HTML files are served with Content-Type: text/html header

See attack scenario 2 for more details on how attacks with malicious HTML files work.

Unnecessary files

Web servers will serve any file within the configured top-level directory and its subdirectories. When configuring a web server, if the top-level directory is the app's main data directory or other sensitive directory, the web server can expose internal files and user files over the network.

If the web server is needed for a specific purpose, such as streaming specific files when requested by the user, the server should use a dedicated directory for this purpose. Having unnecessary files in the directory, such as files which were streamed in the past, increases the amount of data exposed through the web server.

Attack scenarios

These are attack scenarios for a hypothetical mobile app. All scenarios have the following prerequisites:

• App runs a web server with top-level directory containing sensitive data.
• Attacker knows the app's web server port.

Attack scenario 1: Local network or local device access, no user interaction

This attack scenario can be performed by an attacker on the local network, or a malicious app on the device or local network.

Prerequisites:

• Attacker must be on same local network as device (or if malicious app, on the device or local network).

Steps to reproduce:

1. If local IP address of target device is not known, scan local network for devices with the web server's port open. (A local network user may have access to the router's admin panel, which would also list devices on the network.)
2. Make an HTTP request to an identified device on the web server port to list the top-level directory, and from there identify and exfiltrate files of interest.

Attack scenario 2: Remote web page (over the Internet), one-time user interaction

This attack scenario can be performed by an attacker over the Internet.

Prerequisites:

• Web server serves user-downloaded files.
• Web server serves HTML files with header Content-Type: text/html (see HTML file rendering).
• Web server has directory listings or app uses predictable file names.

Steps to reproduce, first time:

1. Navigate to specially-crafted attacker page.
2. Follow attacker prompts (download a file).
3. Attack is performed (after download, payload is automatically executed by landing page).

The landing page prompts the user to download a malicious HTML file with a predictable file name (hello.html). After the download, the landing page opens the downloaded HTML page via an iframe (with src set to http://127.0.0.1:{port}/hello.html). Opening the page executes malicious JavaScript which exfiltrates any files available through the web server.

Steps to reproduce, subsequent times:

1. Navigate to same attacker page.
2. Attack is performed (since payload already exists, payload is automatically executed by landing page).

After the payload is downloaded the first time, any subsequent attacks only require loading an attacker page (or malicious JavaScript within an otherwise safe page). The user can be forced or convinced to visit the malicious page via ad networks, malicious code on websites, or social engineering. Once the payload exists, attacks can also occur on any web browser, not only the vulnerable app, since the web server is accessible from any other browser even while the app is closed.

Attack scenario 3: Remote network (over the Internet), no user interaction

This attack scenario can be performed by an attacker over the Internet.

Prerequisites:

• Target device must be accessible over a remote network (over the Internet). This is uncommon, but is possible depending on network settings, such as port forwarding, IPv6 assignments, or insecure mobile carrier networks.

Steps to reproduce:

1. Identify devices running the app's web server, by either using tools such as Shodan, scanning the open Internet, testing ports of users visiting an attacker's website, checking server logs for known app user-agent headers, or other methods. This is easier if the app and web server have relatively unique signatures.
2. Make an HTTP request to an identified device on the web server port to list the top-level directory, and from there identify and exfiltrate files of interest.

Attack scenario 4: Local device access, app is passcode-protected

This attack scenario can be performed by a locally-installed app or a casual attacker using the device. It's similar to attack scenario 1, but with passcode protection.

Prerequisites:

• Access to device (assumes only remaining barrier is the app's passcode protection).
• App runs web server prior to valid passcode entry.

Steps to reproduce:

1. Open Chrome or any other browser on the device.
2. Navigate to http://127.0.0.1:{port} to list the top-level directory, and from there identify and exfiltrate files of interest.
   • If web page does not load because the app has not been run since device restart, open the app normally but do not enter a passcode. Then, go back to the other browser, and navigate again to http://127.0.0.1:{port}. The web server will be turned on before entering the passcode, allowing access via another browser.

Identified vulnerable apps

I've identified at least one mobile app which had this vulnerability. The vendor fixed the vulnerability, but has not allowed me to disclose the app name or other identifying details.

Have you identified a vulnerable app? After reporting to the vendor and obtaining disclosure approval, send me an email. If you want to collaborate on a report, you can also send me an email.

{Redacted App}

{Redacted App} is an Android web browser that advertises itself as a secure, privacy-preserving browser which hides downloads and browsing activity from unauthorized users. It allows users to download files and stream them over the network. It also offers passcode protection when the app is opened on the device.

The app runs a web server to stream files over the local network. However, due to how the vendor designed and implemented the feature, the web server enabled unauthorized listing and exfiltration of all downloaded files, plus additional internal files which contain sensitive device and user information. The app also had predictable file names for most files. The web server also bypassed the app's passcode protection.

This vulnerability defeated the app's main security and privacy promises, and left users at risk.

Data vulnerable to exfiltration included:

• All user-downloaded files.
• App-generated thumbnails of downloaded media.
• Third-party service configuration files, including user-specific config data.
• Files containing details about whether device is rooted, available processors, manufacturer, total disk space, and total RAM.
• Logs with detailed app usage information, such as which app activities were opened and at what time. This can be used to see when and how many times a user has opened the browser, downloaded files, and performed other activities within the app. There may be other detailed or sensitive data in these logs.
• Other internal files, which appear to be either encrypted or otherwise obfuscated configuration and/or user data. It's unclear whether these have sensitive information.

How to identify and mitigate

Identify as a security researcher

Identify running web servers using:

• Code analysis
  • Look for popular library names or classes, references to server, common headers such as Content-Type and Access-Control-Allow-Origin, and other indicators of web server code.
  • If the library is open source, check the version used in the app and analyze that version using the online source code (usually in GitHub). The original source code is usually easier to read than the decompiled source code from most tools and can help you analyze complex code paths better.
  • Check if the app is using the latest version of the library. If not, check for known vulnerabilities using public vulnerability databases and the library's official website. Some libraries only mention security fixes in release notes, so look carefully through those if other sources aren't fruitful.
  • Check for insecure configurations, such as using a sensitive directory as top-level directory, lax CORS headers, hardcoded credentials, etc. Common configuration pitfalls are sometimes listed in a library's documentation.
  • If you're feeling adventurous, analyze the library for new vulnerabilities.
• Port analysis
  • Run a port scan against the device running the app. To more easily identify app-specific ports, perform a baseline scan with the app closed, then scan again while running the app. Ensure to stop the app completely using the system settings when making app-stopped observations.
  • Compare the output and determine whether there are ports of interest, either for web servers or another common service.
• App store listings
  • Check app store listings for feature lists that include streaming (Cast or AirPlay) or other features which may require a web server.

If you've identified a web server using a method other than code analysis, I recommend performing code analysis for better insights on subtle behavior. See behaviors that increase impact for examples. Libraries vary in how they implement web servers, and the library version used by an app may be outdated and have known security issues.

Identify and mitigate as a software developer

• Consider whether you need a web server in your mobile app at all. A web server will be accessible to other apps and users on the device, other devices on the local network, and potentially over the Internet. This may not be appropriate for your use case.
• If you really need a web server, turn on the server only when needed and turn it off afterward. Do not run the web server immediately when the app starts, especially if authentication is required from the user.
• Ensure the web server's top-level directory is unique for its purpose (see Unnecessary files).
• Disable directory listings (see Directory listings).
• Ensure HTML files are not rendered by web browsers (see HTML file rendering) by sending an appropriate Content-Type header to the browser. This is particularly important if files can be controlled by a user or an attacker.
• Avoid predictable file names for any sensitive files served by the web server (see Predictable file names).
• Use a well-maintained web server library with a good security track record. This doesn't necessarily mean a library with no known vulnerabilities; this can indicate it's safe, but it can also indicate a lack of audits, inadequate vulnerability disclosure processes, or unmaintained software.

Many thanks to Julien Cretel for providing feedback on this article.

Thank you for reading. Don't miss any new research: Get new articles via email.