Updated 03/23/2020: A Netflix spokeswoman said that rejecting this bug report on the grounds that it falls outside the scope is a corporate mistake. The company has since confirmed the validity of the report and started rolling out a fix on Friday. The spokeswoman said the researcher would receive a bounty, even though she didn't say how much it would be. What follows is the original Ars report:
A Netflix vulnerability that could allow unauthorized access to user accounts over local networks is outside the scope of the company's bug bounty program, the researcher who reported the threat said. Despite the report's rejection, the vulnerability bug-reporting service is trying to prevent the vulnerability from being disclosed to the public.
The researcher's proof-of-concept exploit uses a classic man-in-the-middle attack to steal a Netflix session cookie. These browser cookies correspond to a bracelet used by music venues so that paying customers are not charged an admission fee a second time. Having a valid session cookie is all that is required to access a destination's Netflix account.
Still unencrypted after all these years
Varun Kakumani, the security researcher who discovered the vulnerability and reported it privately via bug crowd, said the attack was possible for two reasons: (1) continued use of plain text HTTP connections instead of encrypted HTTPS connections by some Netflix subdomains and (2) Netflix's failure to provide the session cookie with a secure flag that prevents transmission over unencrypted connections.
The omissions are surprisingly found in a major web service in 2020. In the years following the 2013 National Security Agency's disclosure of indiscriminate spying, these services have adopted the use of HTTPS in almost every subdomain. The protocol provides end-to-end encryption between websites and end users. Netflix did not respond to a message looking for a comment for this post. Without a statement from the company, it is not clear whether the use of plain text connections is inadvertent or is intended to provide various functions.
"Essentially, you can hack any Netflix account that is on the same Wi-Fi network," said Kakumani. "Old-school MITM attack."
Disclosure not allowed
"This program does not allow for disclosure," the reply said. "You must not disclose information about vulnerabilities in this program to the public." This applies to all submissions regardless of the status example: out of scope. The policy is what you agreed when you submitted it. Thanks again and have a nice day! "
Kakumani ignored the warning and exposed the vulnerability on Twitter and posted videos detailing how his attack worked. A bug crowd agent named Breonna replied with the message: “Your tweet is a form of unauthorized disclosure because it indicates that this program has a specific vulnerability. It also contains a link to a YouTube POC that violates our terms and conditions. Please immediately pull this tweet and POC video off YouTube. "
Kakumani complied with the request. On Wednesday, seven days after the notification was sent, Bugcrowd contacted Kakumani again to inform him that his report had been rejected because it was a duplicate of a previously submitted report.
In a statement, bug crowd officials wrote:
The public disclosure of security gaps is a differentiated and very context-related conversation. As an organization, we strongly advocate disclosure and have integrated functions into our platform (CrowdStream) that are intended to help researchers and organizations work together to disclose results.
However, due to the nature of the vulnerabilities and the potential risk of uncoordinated disclosure, several customers follow the policy that everything reported to the platform must be approved by the customer before it can be shared publicly. In this way, customers can correct the vulnerability before it is disclosed. It is quite possible that any report will reach this state as long as the researcher and the organization coordinate their activities. In the event that a researcher publishes information about a vulnerability without obtaining approval from the organization that did not allow disclosure, we will work with the researcher to remove this information from public forums to help the researcher and the customer protect.
We make this possible through our platform and program managers. The explicit goal of reporting a vulnerability is to correct it and make the world a little more secure.
Disclosure is not permanently excluded. We strongly advocate disclosure as much as possible – this is good for the community and, once resolved, shows the organization's security readiness to address the issue. However, it is important that the disclosure occurs only after a discussion between the researcher and the client's program owners so that both parties achieve a mutually acceptable disclosure schedule, etc. In most cases where a discussion takes place, an acceptable outcome is usually achieved. All parties make a profit (the organization knows and corrects the finding; the researcher is paid and can post it on a timeline after the problem is resolved. Consumers are not exposed to unnecessary risk due to unauthorized disclosures.). Our platform with CrowdStream functions and program teams enables this interaction.
As previously explained, the attacker and the target of the cookie theft must connect to the same Wi-Fi access point or another local network. For unauthorized access, the target must also be signed in to their Netflix account. The attacker uses a technique called ARP poisoning to intercept traffic between the target and Netflix and then relay it 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 inserts HTML into the connection to create a second connection request to one of the Netflix HTTP subdomains such as oca-api.netflix.com.
By connecting to the HTTP subdomain, NetflixId – the name of the unprotected session cookie – can be used. If targets don't access an HTTP connection on their own (which is becoming more common these days, as HTTPS is almost ubiquitous), an attacker could trick targets into clicking an HTTP link. Once the attacker is in possession of the cookie, he uses a browser console to insert the cookie on an open Netflix page. The attacker then accesses the target's account.
A transcript of Kakumani's communication with bug crowd shows a member of the vulnerability service that holding the NetflixID cookie is not enough to gain unauthorized access to an account. Instead, the employee said: "This attack would require a man-in-the-middle position and does not compromise the SecureNetflix cookie that a user is authenticated with at www.netflix.com. For the SecureNetflix cookie, the Secure- Flag set and will not be sent over an unencrypted channel. The secure flag is not set for the NetflixId cookie, but the SecureNetflix cookie is required to authenticate a user. "
Kakumani told me the worker’s statement was wrong, and his proof-of-concept videos, which are no longer public on Bugcrowd’s pressure, seem to prove it. The videos show how the attacker only uses the NetflixId cookie to gain access to an account.
In any case, attackers who gain unauthorized access cannot take over the account because changing passwords or associated email addresses requires knowledge of the current password. However, attackers can still watch videos and view a target’s monitoring history, phone number, and other personal information. Attackers can also switch plans to ultra high definition, which costs more than high definition. Unauthorized access is also possible if the destination logs out of the account or changes the password on the same device on which the intercepted session cookie was received, said Kakumani.
Exploit is not for everyone
Given the requirement that the attacker be on the same local network as the target and either tempt the target to click an HTTP link or wait for the target to access a link itself, there is only one low probability that this vulnerability is widespread. The vulnerability, however, offers the possibility of targeted attacks in a scenario that occurs regularly. It is surprising that Netflix, a company with a reasonably good safety record, would reject Kakumani's report.
The incident also underscores the role that bug bounty programs play in suppressing vulnerabilities. Without a doubt, data protection makes sense when companies are about to fix a vulnerability. The confidentiality prevents other hackers from maliciously exploiting the vulnerabilities before the update is carried out.
However, once a vulnerability is fixed – or if a company chooses not to fix it – users deserve to have all the details of the bug, including how attacks work. Bug crowd guidelines that prevent this information from flowing freely serve Netflix's interests, but are less helpful to the general public.