December 9, 2019

Enhancing the Security of Data Breach Notifications and Settlement Notices

[This post was jointly written by Ryan Amos, Mihir Kshirsagar, Ed Felten, and Arvind Narayanan.]

We couldn’t help noticing that the recent Yahoo and Equifax data breach settlement notifications look a lot like phishing emails. The notifications make it hard for users to distinguish real settlement notifications from scams. For example, they direct users to URLs on unfamiliar domains that are not clearly owned by the company that was breached nor any other trusted entity. Practices like this lower the bar for scammers to create fake phishing emails, potentially victimizing users twice. To illustrate the severity of this problem, Equifax mixed up domain names and posted a link to a phishing website to their Twitter account. Our discussion paper presents two recommendations to stakeholders to address this issue.

First, we recommend creating a centralized database of settlements and breaches, with an authoritative URL for each one, so that users have a way to verify the notices distributed. Such a database has precedent in the Consumer Product Safety Commission (CPSC) consumer recall list. When users receive notice of a data breach, this database would serve as a reliable authority to verify the information included in the notice. A centralized database has additional value outside the data breach context as courts and government agencies increasingly turn to electronic notices to inform the public, and scammers (predictably) respond by creating false notices.

Second, we recommend that no settlement or breach notice include a URL to a new domain. Instead, such notices should include a URL to a page on a trusted, recognizable domain, such as a government-run domain or the breached party’s domain. That page, in turn, can redirect users to a dedicated domain for breach information, if desired. This helps users avoid phishing by allowing them to safely ignore links to unrecognized domains. After the settlement period is over, any redirections should be automatically removed to avoid abandoned domains from being reused by scammers.

Content Moderation for End-to-End Encrypted Messaging

Thursday evening, the Attorney General, the Acting Homeland Security Secretary, and top law enforcement officials from the U.K. and Australia sent an open letter to Mark Zuckerberg. The letter emphasizes the scourge of child abuse content online, and the officials call on Facebook to press pause on end-to-end encryption for its messaging platforms.

The letter arrived the same week as a widely shared New York Times article, describing how reports of child abuse content are multiplying. The article provides a heartbreaking account of how the National Center for Missing and Exploited Children (NCMEC) and law enforcement agencies are overburdened and under-resourced in addressing horrible crimes against children.

Much of the public discussion about content moderation and end-to-end encryption over the past week has appeared to reflect two common technical assumptions:

  1. Content moderation is fundamentally incompatible with end-to-end encrypted messaging.
  2. Enabling content moderation for end-to-end encrypted messaging fundamentally poses the same challenges as enabling law enforcement access to message content.

In a new discussion paper, I provide a technical clarification for each of these points.

  1. Forms of content moderation may be compatible with end-to-end encrypted messaging, without compromising important security principles or undermining policy values.
  2. Enabling content moderation for end-to-end encrypted messaging is a different problem from enabling law enforcement access to message content. The problems involve different technical properties, different spaces of possible designs, and different information security and public policy implications.

I aim to demonstrate these clarifications by formalizing specific content moderation properties for end-to-end encrypted messaging, then offering at least one possible protocol design for each property.

  • User Reporting: If a user receives a message that he or she believes contains harmful content, can the user report that message to the service provider?
  • Known Content Detection: Can the service provider automatically detect when a user shares content that has previously been labeled as harmful?
  • Classifier-based Content Detection: Can the service provider detect when a user shares new content that has not been previously identified as harmful, but that an automated classifier predicts may be harmful?
  • Content Tracing: If the service provider identifies a message that contains harmful content, and the message has been forwarded by a sequence of users, can the service provider trace which users forwarded the message?
  • Popular Content Collection: Can the service provider curate a set of content that has been shared by a large number of users, without knowing which users shared the content?

The discussion paper is inherently preliminary and an agenda for further interdisciplinary research (including my own). I am not yet prepared to normatively advocate for or against the protocol designs that I describe. I am not claiming that these concepts provide sufficient content moderation capabilities, the same content moderation capabilities as current systems, or sufficient robustness against evasion. I am also not claiming that these designs adequately address information security risks or public policy values, such as free speech, international human rights, or economic competitiveness.

I do not know if there is a viable path forward for content moderation and end-to-end encrypted messaging that will be acceptable to technology platforms, law enforcement, NCMEC, civil society groups, information security experts, and other stakeholders. I do have confidence that, if such a path exists, we will only find it through open research and dialogue.

Watching You Watch: The Tracking Ecosystem of Over-the-Top TV Streaming Devices

By Hooman Mohajeri Moghaddam, Gunes Acar, Ben Burgess, Arunesh Mathur, Danny Y. Huang, Nick Feamster, Ed Felten, Prateek Mittal, and Arvind Narayanan

By 2020 one third of US households are estimated to “cut the cord”, i.e., discontinue their multichannel TV subscriptions and switch to internet-connected streaming services. Over-the-Top (“OTT”) streaming devices such as Roku and Amazon Fire TV, which currently sell between for $30 to $100, are cheap alternatives to smart TVs for cord-cutters. Instead of charging more for the hardware or the membership, Roku and Amazon Fire TV monetize their platforms through advertisements, which rely on tracking users’ viewing habits.

Although tracking of users on the web and on mobile is well studied, tracking on smart TVs and OTT devices has remained unexplored. To address this gap, we conducted the first study of tracking on OTT platforms. In a paper that we will present at the ACM CCS 2019 conference, we found that: 

  • Major online trackers such as Google and Facebook are also highly prominent in the OTT ecosystem. However, OTT channels also contain niche and lesser known trackers such as adrise.tv and monarchads.com.
  • The information shared with tracker domains includes video titles (see Figure 1), channel names, permanent device identifiers and wireless SSIDs.
  • Countermeasures made available to users are ineffective at preventing tracking.
  • Roku had a vulnerability that allowed malicious web pages visited by Roku users to geolocate users, read device identifiers and install channels without their consent.
 Figure 1. AsianCrush channel on Roku sends the device ID and video title to online video advertising platform spotxchange.com

Method and Findings:

Similar to how Android or iOS supports third-party apps, Amazon and Roku support third-party applications known as channels, ranging from popular channels like Netflix and CNN to several obscure ones.

Automation is one of the main challenges of studying how these channels track users. Tools that automate interaction with web pages (such as Selenium) do not exist for OTT platforms. To address this challenge, we developed a system that can automatically download OTT channels and interact with them all while intercepting the network traffic and performing best-effort TLS interception. We describe the different components of our tool in the Appendix. Using this crawler we collected data from the top 1000 channels on both Roku and the Amazon Fire TV channel stores.

The distribution of trackers by channel category and rank is shown in Figure 2. The “Games” category of Roku channels contact the most trackers: nine of the top ten channels (ordered by the number of trackers) are categorized as game channels. On the other hand, five of the ten Fire TV channels with the most trackers are “News” channels, where the top three channels contact close to 60 tracker domains each. Below we summarize our findings:

Figure 2. Distribution of trackers by channel ranks and channel categories.

Google and Facebook are among the most popular trackers

Google and Facebook domains (doubleclick.net, google-analytics.com, googlesyndication.com and facebook.com) are among the most prevalent trackers in the OTT channels on both platforms we studied. Google’s doubleclick.net appeared on 975 of the top 1000 Roku channels, while amazon-adsystem.com appeared on 687 of the top 1000 Amazon Fire TV channels.

Table 1. Most prevalent trackers on top 1000 channels on Roku (left) and Amazon (right).

User and device identifiers shared with trackers

Trackers have access to a wide range of device and user identifiers on OTT platforms. Some of these identifiers can be reset by users (e.g., Advertising IDs), while others are permanent (e.g., serial numbers, MAC addresses). To detect the identifiers shared with trackers, we followed the method described by Englehardt et al. to search for device and user identifiers in the network traffic of the top 1000 channels for each platform. This allowed us to detect leaks even when the identifiers were encoded or hashed. An overview of the leaked IDs on each platform is given in Table 2.

Table 2. Overview of identifier and information leakage detected in the Roku (left) and the FireTV (right) crawls.

Channels share video titles with third-party trackers

Out of 100 randomly selected channels on Roku and Amazon, we found 9 channels on Roku (e.g., “CBS News” and “News 5 Cleveland WEWS”)  and 14 channels on the Fire TV (e.g., “NBC News” and “Travel Channel”) that leaked the title of the video to a tracking domain. On Roku, all video titles were leaked over unencrypted connections, exposing user video history to eavesdroppers. On Fire TV, only two channels (NBC News and WRAL) used an unencrypted connection when sending the title to tracking domains.

Overwhelming majority of the channels use unencrypted connections

Out of the 1000 channels we studied on Roku and Amazon Fire TV, 794 channels on Roku and 762 on Amazon Fire TV had at least one unencrypted HTTP session, potentially exposing users’ information and identities to network adversaries.

Countermeasures

OTT platforms provide privacy options that purport to limit tracking on their devices: “Limit Ad Tracking” on Roku and ”Disable Interest-based Ads” on Amazon Fire TV. Our measurements show that these privacy options fall short of preventing tracking. Turning on these options did not change the number of trackers contacted. Turning on “Limit Ad Tracking” on Roku reduced the number of AD ID leaks from 390 to zero, but did not change the number of serial number leaks.

Roku Remote Control API Vulnerability

To investigate other ways OTT devices may compromise user privacy and security, we analyzed local API endpoints of Roku and Fire TV. OTT devices expose such interfaces to enable debugging, remote control, and home automation by mobile apps and other automation software. We discovered a vulnerability in the Roku’s remote control API that allows an attacker to:

  • send commands to install/uninstall/launch channels and collect unique identifiers from Roku devices – even when the connected display is turned off.
  • geolocate Roku users via the SSID of the wireless network
  • extract MAC address, serial number, and other unique identifiers to track users or respawn tracking identifiers (similar to evercookies).
  • get the list of installed channels and use it for profiling purposes.

We reported the vulnerability to Roku in December 2018. Roku addressed the issue and finalized rolling out their security fix by March 2019.

Going forward

Our research shows that users, who are already being pervasively tracked on the web and mobile, face another set of privacy-intrusive tracking practices when using their OTT streaming platforms. A combination of technical and policy solutions can be considered when addressing these privacy and security issues. OTT platforms should offer better privacy controls, similar to Incognito/Private Browsing Mode of modern web browsers. Insecure connections should be disincentivized by platform policies. For example, clear-text connections should be blocked unless an exception is requested by the channel. Regulators and policy makers should ensure the privacy protections available for brick and mortar video rental services, such as Video Privacy Protection Act (VPPA), are updated to cover emerging OTT platforms.

Appendix

Crawler architecture:

We set out to build a crawler to study tracking and privacy practices of OTT channels at scale. Our crawler installs a channel, launches it, and attempts to view a video on the channel, while collecting network traffic and attempting “best-effort” TLS interception. The crawler consists of a number of different hardware devices:

  • A desktop machine connected to the Internet acts as a wireless access point (AP).
  • An OTT stick connects to the Internet via the WiFi AP provided by the desktop machine. It also connects to a TV through an HDMI Capture and Split Card to sidestep the HDCP protections.

The desktop machine orchestrates our crawls and has the following software components:

  • Automatic interaction engine:
    • Remote Control API: OTT platforms provide an API to enable remote control apps to send commands such as switching or installing channels. We wrote our own wrappers for both Roku and Amazon Fire TV’s remote APIs.
    • Audio/Video processing: We process the audio from the OTT device on the desktop machine and use it to detect video playback, which guides our automatic interaction with channels. Video input is also saved as screenshots for post-processing and validation.
  • Network Capture: We collect network traffic of the OTT devices as pcap files and dump all DNS transactions in a Redis database.
  • TLS interception: We use mitmproxy to perform “best-effort” TLS interception. For each channel and each new TLS endpoint, we attempt to intercept the traffic using a self-signed certificate. If the interception fails, we add the endpoint to a no-intercept list to avoid further interception attempts. On Amazon Fire TV, we manage to root the device using a previously known vulnerability, and install mitmproxy’s self-signed certificate on the device certificate store. In addition, we use Frida to bypass certificate pinning.
Figure 3. Overview of our smart crawler.