Netflix Still Sends Cookies Over HTTP

Updated 3/23/2020: A Netflix spokeswoman said that the dismissal of this bug report on the grounds it was out-of-scope was a mistake on the part of the company. The company has since confirmed the validity of the report and began rolling out a fix on Friday. The spokeswoman said that the researcher will receive a bounty, although she didn’t say how much it will be. What follows is the original Ars report:

A Netflix security weakness that allows unauthorized access to user accounts over local networks is out of the scope of the company’s bug bounty program, the researcher who reported the threat said. Despite dismissing the report, the Bugcrowd vulnerability reporting service is trying to prevent public disclosure of the weakness.

The researcher’s proof-of-concept exploit uses a classic man-in-the-middle attack to steal a Netflix session cookie. These browser cookies are the equivalent of a wristband that music venues use so paying customers aren’t charged an entrance fee a second time. Possession of a valid session cookie is all that’s required to access a target’s Netflix account.

Still unencrypted after all these years

Varun Kakumani, the security researcher who discovered the weakness and privately reported it through Bugcrowd, said the attack is possible because of two things: (1) the continued use of clear-text HTTP connections rather than encrypted HTTPS connections by some Netflix subdomains and (2) the failure of Netflix to equip the session cookie with a secure flag, which prevents transmission over unencrypted connections.

The omissions are surprising to find in a major Web service in 2020. In the years following the 2013 revelations of indiscriminate spying by the National Security Agency, these services almost universally adopted the use of HTTPS across all subdomains. The protocol provides end-to-end encryption between websites and end users. Netflix didn’t respond to a message seeking comment for this post. Without an explanation from the company, it’s not clear if the use of plaintext connections is an oversight or done purposely to provide various capabilities.

“Essentially you can hack any Netflix account [of] whoever is on the same Wi-Fi network,” Kakumani told me. “Old-school MITM attack.”

Disclosure not allowed

He said he reported the threat through Bugcrowd, the vulnerability reporting service that Netflix uses to receive disclosures from hackers and pay them a reward in exchange. On March 11, Bugcrowd sent Kakumani a reply that said the weakness he reported was out of scope with the bounty program. Bugcrowd went on to tell the researcher that its terms of service barred him from publicly disclosing or discussing the weakness.

“This program does not allow disclosure,” the response stated. “You may not release information about vulnerabilities found in this program to the public. This applies to all submissions regardless of status example: out of scope. The policy is what you have agreed upon submission. Thank you again and have a good day!”

Kakumani ignored the admonishment and disclosed the vulnerability on Twitter and posted videos that showed in detail how his attack worked. A Bugcrowd worker using the name Breonna replied with a message that said, “Your tweet is a form of unauthorized disclosure, as it indicates that a specific vulnerability is present within this program. It also includes a link to a YouTube POC, which violates our terms and conditions. Please pull down this tweet and this POC Video from YouTube immediately.”

Kakumani complied with the request. On Wednesday, seven days after sending the notification, Bugcrowd contacted Kakumani again to tell him his report was dismissed because it was a duplicate of a previously submitted report.

In a statement, Bugcrowd officials wrote:

Public disclosure of vulnerabilities is a nuanced and highly contextual conversation. As an organization, we strongly advocate for disclosure, and have built functionality into our platform (CrowdStream) that’s meant to help both researchers and organizations work together to disclose findings.

However, due to the nature of security vulnerabilities and potential risks of uncoordinated disclosure, several customers follow the policy that anything reported to the platform needs to be approved by the customer before it can be shared publicly. This allows customers to address the vulnerability before it is disclosed. It is entirely possible that any report can reach this state, so long as the researcher and the organization coordinate their activities. In the event that a researcher posts information about a vulnerability without receiving consent from the organization that has not allowed disclosure, we work with the researcher to remove this information from public forums to protect the researcher and customer.

We facilitate this through our platform and program managers. The express goal in reporting a vulnerability is for it to get remediated, and to make the world a little more secure.

Disclosure isn’t barred in perpetuity. We strongly advocate for disclosure as much as possible—it’s good for the community, and after being fixed, it shows the security-forwardness of the organization remediating the issue. However, it’s important that the disclosure comes only after a discussion between the researcher and customer’s program owners so that both parties reach a mutually agreeable disclosure timeline, etc. In most cases, where there’s a discussion, an agreeable outcome is usually arrived at, and all parties come away with a win (the organization knows about and fixes the finding; the researcher gets paid, and is able to disclose on a timeline after the issue is fixed; and consumers aren’t placed at unnecessary risk due to unauthorized disclosures). Our platform with CrowdStream capabilities and program teams enable this interaction.

As explained earlier, the cookie theft requires the attacker and target to connect to the same Wi-Fi access point or other local network. The unauthorized access also requires that the target be logged in to his or her Netflix account. The attacker uses a technique called ARP poisoning to intercept the traffic between the target and Netflix and then pass it along to the other party. The attacker then waits for the target to make an HTTP connection to any domain. Once the unencrypted connection is established, the attacker injects HTML into the connection to create a second connection request to one of the Netflix HTTP subdomains, such as oca-api.netflix.com.

The connection to the HTTP subdomain makes NetflixId—the name of the unprotected session cookie—free for the taking. If targets don’t access an HTTP connection on their own (something that’s increasingly common since HTTPS is almost ubiquitous these days) an attacker can trick targets into clicking on any HTTP link. Once in possession of the cookie, the attacker then uses a browser console to paste the cookie on an open Netflix page. With that, the attacker accesses the target’s account.

A transcript of Kakumani’s communications with Bugcrowd shows a worker for the vulnerability reporting service saying that possession of the NetflixID cookie wasn’t enough to gain unauthorized access to an account. Instead, the worker said, “This attack would require a man-in-the-middle position and does not compromise the SecureNetflix cookie, which is used to authenticate a user to www.netflix.com. The SecureNetflix cookie has the Secure flag set and won’t be sent over an unencrypted channel. The NetflixId cookie does not have the Secure flag set but requires the SecureNetflix cookie to authenticate a user.”

Kakumani told me the worker’s statement is wrong, and his proof-of-concept videos, which at Bugcrowd’s insistence are no longer public, seem to prove this. The videos show the attacker using only the NetflixId cookie to gain access to an account.

In any event, attackers who gain unauthorized access can’t take over the account, since changing passwords or associated email addresses require knowledge of the current password. Attackers, however, can still watch videos and view a target’s watch history, phone number and other personal data. Attackers can also change plans to ultra high definition, which costs more than high definition. The unauthorized access is possible even when the target logs out of the account or makes a password change on the same device that received the intercepted session cookie, Kakumani said.

Exploit is not for everyone

Given the requirements that the attacker must be on the same local network as the target and must either trick the target to click on an HTTP link or wait for the target to access one on his or her own, there’s little likelihood that this weakness will be widely exploited. Still, the vulnerability provides an opportunity for targeted attacks in a scenario that occurs regularly. It’s surprising that Netflix, a company with a reasonably good security track record, would dismiss Kakumani’s report.

The incident also underscores the role bug-bounty programs play in squashing vulnerability disclosure. No doubt, privacy makes sense when companies are in the process of fixing a vulnerability. The secrecy prevents other hackers from maliciously exploiting the weaknesses before the fix is in place.

But once a weakness is fixed—or in the event a company opts not to fix it—users deserve to have full details of the bug, including how attacks work. Bugcrowd policies barring the free flow of this information serve the interests of Netflix but are less helpful to the public at large.

READ MORE HERE