“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.