Una extensión de Twitch enviaba tokens OAuth a un servicio comercial de bots

Una extensión de Twitch enviaba tokens OAuth a un servicio comercial de bots

El acceso a cuentas se extendía fuera del navegador sin que los usuarios lo supieran.

image

Una extensión para Twitch, que prometía mejorar la calidad de las transmisiones y eliminar restricciones, resultó ser un canal para la transmisión de credenciales activas. El equipo de Socket descubrió que Twitch Enhanced Viewer | JeetBot enviaba los tokens OAuth de los espectadores mediante una infraestructura proxy del servicio comercial JeetBot, y la audiencia potencial afectada alcanzaba aproximadamente 31.000 personas.

El complemento se distribuía a través de Chrome Web Store y Firefox Add-ons. Al momento de la investigación lo usaban alrededor de 30.000 propietarios de Chrome y varios cientos de usuarios de Firefox. Socket determinó que la extensión interceptaba la cabecera Authorization, que el cliente web de Twitch usa para las solicitudes autorizadas al servicio y para obtener datos de la sesión.

Tras capturar la cabecera, el componente en segundo plano extraía el token OAuth y lo añadía a la URL de la solicitud como el parámetro &auth=. La extensión redirigía las solicitudes a las listas de reproducción de Twitch a través del proxy del operador, de modo que el secreto quedaba en la URL y podía registrarse en los logs del servidor. Para la reproducción normal de vídeo no se requería un token tan amplio, ya que la retransmisión usa parámetros separados.

No se trataba de una clave independiente para ver la transmisión, sino de un token de sesión de usuario. Según la estimación de Socket, el poseedor del token bearer podía actuar en nombre de la cuenta sin contraseña ni segundo factor, incluyendo interactuar con el chat, los mensajes privados y parte de la configuración. Ese robo de sesión puede eludir la autenticación de dos factores, ya que la verificación ya se había superado.

La rama 85.x que examinó Socket transmitía el token junto con la redirección de red. Compilaciones anteriores 4.x actuaban incluso de forma más directa: la versión 4.8 del 8 de enero de 2026 enviaba el token capturado mediante una solicitud POST a un endpoint set-token específico, y si el nodo principal no estaba disponible se cambiaba a direcciones de respaldo en la infraestructura deno.dev y deno.net.

Socket también detectó una excepción para diez canales en ruso: al verlos, el token no se añadía a la solicitud redirigida. Para el resto de los canales el mecanismo funcionaba con normalidad. Esa selectividad llamó la atención del equipo; sin embargo, el hecho de la excepción por sí solo no prueba que los tokens obtenidos se usaran para ataques ni confirma el secuestro de cuentas ajenas.

La situación se complicó por las declaraciones en las tiendas de extensiones. Al momento de la investigación la página de Chrome afirmaba que el desarrollador no recopilaba ni usaba datos de los usuarios, y la política de privacidad no describía la transmisión del token OAuth. Más tarde el operador reconoció que la descripción anterior no reflejaba el procesamiento real de las credenciales, pero rechazó la versión de un uso intencional indebido de las cuentas.

Tras la publicación de Socket, el desarrollador modificó el mecanismo de obtención de listas de reproducción. Firefox recibió la versión 85.8.7 del 12 de septiembre, en la que, según la documentación de JeetBot, el token OAuth ya no se envía al proxy. A fecha del 15 de septiembre, Chrome Web Store todavía mostraba la versión 85.8.4, y la compilación 85.8.7 para Chrome estaba en revisión en la tienda oficial.

La actualización detiene las nuevas transmisiones, pero no revoca los tokens ya enviados. El desarrollador aconseja cerrar todas las sesiones de Twitch y volver a iniciar sesión para que las credenciales antiguas dejen de funcionar. Hasta obtener la versión 85.8.7 es mejor desactivar la extensión. Un riesgo similar ya se había observado en otras extensiones de navegador que, tras actualizaciones, empezaron a recopilar datos sensibles.

No hay confirmaciones públicas de que los tokens enviados se usaran para capturar cuentas. El riesgo principal surgía de la arquitectura: el secreto con permisos de sesión de usuario abandonaba el navegador y pasaba por la infraestructura de un operador externo. La historia muestra cómo el proxy del tráfico puede, sin darse cuenta, convertir una extensión útil en un intermediario entre la cuenta y un servidor ajeno.