Aquí está el compromiso de la cuenta de Netflix que Bugcrowd no quiere que sepas [Updated]

Actualizado el 23/03/2023: Una portavoz de Netflix dijo que la desestimación de este informe de error porque estaba fuera del alcance fue un error por parte de la empresa. Desde entonces, la compañía ha confirmado la validez del informe y comenzó a implementar una solución el viernes. La portavoz dijo que el investigador recibirá una recompensa, aunque no dijo cuánto será. Lo que sigue es el informe original de Ars:

Una debilidad de seguridad de Netflix que permite el acceso no autorizado a las cuentas de los usuarios a través de las redes locales está fuera del alcance del programa de recompensas por errores de la compañía, dijo el investigador que informó sobre la amenaza. A pesar de descartar el informe, el servicio de informes de vulnerabilidad Bugcrowd está tratando de evitar la divulgación pública de la debilidad.

El exploit de prueba de concepto del investigador utiliza un clásico ataque de intermediario para robar una cookie de sesión de Netflix. Estas cookies del navegador son el equivalente a una pulsera que usan los lugares de música, por lo que a los clientes que pagan no se les cobra una tarifa de entrada por segunda vez. La posesión de una cookie de sesión válida es todo lo que se requiere para acceder a la cuenta de Netflix de un objetivo.

Todavía sin cifrar después de todos estos años

Varun Kakumani, el investigador de seguridad que descubrió la debilidad y la informó en privado a través de Bugcrowd, dijo que el ataque es posible debido a dos cosas: (1) el uso continuo de conexiones HTTP de texto claro en lugar de conexiones HTTPS encriptadas por parte de algunos subdominios de Netflix y ( 2) la falla de Netflix para equipar la cookie de sesión con una bandera segura, que evita la transmisión a través de conexiones no encriptadas.

Las omisiones son sorprendentes de encontrar en un importante servicio web en 2023. En los años posteriores a las revelaciones de 2013 de espionaje indiscriminado por parte de la Agencia de Seguridad Marketingdecontenido, estos servicios adoptaron casi universalmente el uso de HTTPS en todos los subdominios. El protocolo proporciona cifrado de extremo a extremo entre sitios web y usuarios finales. Netflix no respondió a un mensaje en busca de comentarios para esta publicación. Sin una explicación por parte de la empresa, no está claro si el uso de conexiones de texto sin formato es un descuido o se hace a propósito para proporcionar varias capacidades.

“Esencialmente puedes hackear cualquier cuenta de Netflix [of] cualquiera que esté en la misma red Wi-Fi”, me dijo Kakumani. «Ataque MITM de la vieja escuela».

Divulgación no permitida

Dijo que informó la amenaza a través de Bugcrowd, el servicio de informes de vulnerabilidades que utiliza Netflix para recibir información de los piratas informáticos y pagarles una recompensa a cambio. El 11 de marzo, Bugcrowd envió a Kakumani una respuesta que decía que la debilidad que informó estaba fuera del alcance del programa de recompensas. Bugcrowd continuó diciéndole al investigador que sus términos de servicio le prohibían divulgar públicamente o discutir la debilidad.

«Este programa no permite la divulgación», decía la respuesta. «No puede divulgar al público información sobre las vulnerabilidades encontradas en este programa. Esto se aplica a todos los envíos independientemente del estado ejemplo: fuera del alcance. La política es lo que usted ha acordado en el momento de la presentación. ¡Gracias de nuevo y que tengas un buen día!”

Kakumani ignoró la advertencia y reveló la vulnerabilidad en Twitter y publicó videos que mostraban en detalle cómo funcionaba su ataque. Un trabajador de Bugcrowd usando el nombre de Breonna respondió con un mensaje que decía: “Tu tweet es una forma de divulgación no autorizada, ya que indica que un vulnerabilidad específica está presente dentro de este programa. También incluye un enlace a un POC de YouTube, que viola nuestros términos y condiciones. Descargue este tweet y este video POC de YouTube de inmediato.”

Kakumani cumplió con la solicitud. El miércoles, siete días después de enviar la notificación, Bugcrowd contactó a Kakumani nuevamente para decirle que su informe fue desestimado porque era un duplicado de un informe presentado anteriormente.

En un comunicado, los funcionarios de Bugcrowd escribieron:

La divulgación pública de vulnerabilidades es una conversación matizada y altamente contextual. Como organización, abogamos firmemente por la divulgación y hemos incorporado una funcionalidad en nuestra plataforma (CrowdStream) que está destinada a ayudar tanto a los investigadores como a las organizaciones a trabajar juntos para divulgar los hallazgos.

Sin embargo, debido a la naturaleza de las vulnerabilidades de seguridad y los riesgos potenciales de divulgación no coordinada, varios clientes siguen la política de que todo lo que se informe a la plataforma debe ser aprobado por el cliente antes de que pueda compartirse públicamente. Esto permite a los clientes abordar la vulnerabilidad antes de que se divulgue. Es muy posible que cualquier informe pueda llegar a este estado, siempre que el investigador y la organización coordinen sus actividades. En el caso de que un investigador publique información sobre una vulnerabilidad sin recibir el consentimiento de la organización que no permitió la divulgación, trabajamos con el investigador para eliminar esta información de los foros públicos para proteger al investigador y al cliente.

Facilitamos esto a través de nuestra plataforma y administradores de programas. El objetivo explícito al informar sobre una vulnerabilidad es repararla y hacer que el mundo sea un poco más seguro.

La divulgación no está prohibida a perpetuidad. Recomendamos encarecidamente la divulgación tanto como sea posible: es bueno para la comunidad y, después de solucionarlo, muestra el avance de seguridad de la organización para remediar el problema. Sin embargo, es importante que la divulgación se produzca solo después de una discusión entre el investigador y los propietarios del programa del cliente para que ambas partes lleguen a un cronograma de divulgación mutuamente aceptable, etc. En la mayoría de los casos, cuando hay una discusión, generalmente se llega a un resultado aceptable y todas las partes salen ganando (la organización conoce y corrige el hallazgo; al investigador se le paga y puede divulgar en un cronograma una vez que se soluciona el problema; y los consumidores no corren un riesgo innecesario debido a divulgaciones no autorizadas) . Nuestra plataforma con capacidades de CrowdStream y equipos de programas permiten esta interacción.

Como se explicó anteriormente, el robo de cookies requiere que el atacante y el objetivo se conecten al mismo punto de acceso Wi-Fi u otra red local. El acceso no autorizado también requiere que el objetivo inicie sesión en su cuenta de Netflix. El atacante utiliza una técnica llamada envenenamiento ARP para interceptar el tráfico entre el objetivo y Netflix y luego pasarlo a la otra parte. Luego, el atacante espera a que el objetivo establezca una conexión HTTP a cualquier dominio. Una vez que se establece la conexión sin cifrar, el atacante inyecta HTML en la conexión para crear una segunda solicitud de conexión a uno de los subdominios HTTP de Netflix, como oca-api.netflix.com.

La conexión al subdominio HTTP hace que NetflixId, el nombre de la cookie de sesión desprotegida, sea gratuito. Si los objetivos no acceden a una conexión HTTP por su cuenta (algo que es cada vez más común ya que HTTPS es casi omnipresente en estos días), un atacante puede engañar a los objetivos para que hagan clic en cualquier enlace HTTP. Una vez en posesión de la cookie, el atacante utiliza una consola de navegador para pegar la cookie en una página abierta de Netflix. Con eso, el atacante accede a la cuenta del objetivo.

Una transcripción de las comunicaciones de Kakumani con Bugcrowd muestra a un trabajador del servicio de informes de vulnerabilidad diciendo que la posesión de la cookie NetflixID no fue suficiente para obtener acceso no autorizado a una cuenta. En cambio, el trabajador dijo: «Este ataque requeriría una posición de hombre en el medio y no compromete la cookie SecureNetflix, que se usa para autenticar a un usuario en www.netflix.com. La cookie SecureNetflix tiene el indicador Seguro establecido y no se enviará a través de un canal no encriptado. La cookie NetflixId no tiene el indicador Seguro establecido, pero requiere la cookie SecureNetflix para autenticar a un usuario».

Kakumani me dijo que la declaración del trabajador es incorrecta, y sus videos de prueba de concepto, que ante la insistencia de Bugcrowd ya no son públicos, parecen probarlo. Los videos muestran al atacante usando solo la cookie NetflixId para obtener acceso a una cuenta.

En cualquier caso, los atacantes que obtienen acceso no autorizado no pueden hacerse cargo de la cuenta, ya que cambiar las contraseñas o las direcciones de correo electrónico asociadas requiere conocer la contraseña actual. Sin embargo, los atacantes aún pueden mirar videos y ver el historial de reproducción, el número de teléfono y otros datos personales de un objetivo. Los atacantes también pueden cambiar los planes a ultra alta definición, que cuesta más que la alta definición. El acceso no autorizado es posible incluso cuando el objetivo cierra sesión en la cuenta o cambia la contraseña en el mismo dispositivo que recibió la cookie de sesión interceptada, dijo Kakumani.

Explotar no es para todos

Dados los requisitos de que el atacante debe estar en la misma red local que el objetivo y debe engañar al objetivo para que haga clic en un enlace HTTP o esperar a que el objetivo acceda a uno por su cuenta, hay pocas probabilidades de que esta debilidad sea ampliamente explotado. Aún así, la vulnerabilidad brinda una oportunidad para ataques dirigidos en un escenario que ocurre regularmente. Es sorprendente que Netflix, una empresa con un historial de seguridad razonablemente bueno, descarte el informe de Kakumani.

El incidente también subraya el papel que juegan los programas de recompensas por errores en la eliminación de la divulgación de vulnerabilidades. Sin duda, la privacidad tiene sentido cuando las empresas están en proceso de corregir una vulnerabilidad. El secreto evita que otros piratas informáticos exploten maliciosamente las debilidades antes de que se implemente la solución.

Pero una vez que se soluciona una debilidad, o en el caso de que una empresa opte por no solucionarla, los usuarios merecen tener todos los detalles del error, incluido cómo funcionan los ataques. Las políticas de multitud de errores que impiden el flujo libre de esta información sirven a los intereses de Netflix, pero son menos útiles para el público en general.