Reciben recompensa de $10,000 por una vulnerabilidad que filtraba correos de usuarios de YouTube

 (brutecat.com)
1 puntos por GN⁺ 2025-02-13 | 1 comentarios | Compartir por WhatsApp
  • El obfuscated Gaia ID, un identificador interno de cuenta de Google de los canales de YouTube, quedaba expuesto, y podía vincularse con una dirección de correo usando la API de compartición de Pixel Recorder, lo que generaba un problema de privacidad para las cuentas de Google
  • La solicitud de Innertube del menú para bloquear en el chat en vivo devolvía un parámetro moderateLiveChatEndpoint que contenía el Gaia ID del canal objetivo, incluso sin realizar el bloqueo real
  • Al cambiar el ID del canal en los parámetros de la solicitud, el alcance se ampliaba incluso a Topic Channels sin mensajes de chat en vivo, por lo que no era un problema limitado a participantes específicos
  • WriteShareList de Pixel Recorder recibía el obfuscated Gaia ID del destinatario compartido e incluía la dirección de correo en la respuesta, y además era posible impedir el envío del correo de notificación usando un título de grabación de 2.5 millones de caracteres
  • Google recibió el reporte el 15 de septiembre de 2024 y confirmó la corrección de ambas vulnerabilidades el 9 de febrero de 2025, pagando una recompensa total de $10,633

Gaia ID expuesto en la función de bloqueo de YouTube

  • En el documento de descubrimiento de staging de la Internal People API de Google se confirmó que el objeto BlockedTarget usa obfuscated Gaia ID y fallbackName
    • profileId es el obfuscated Gaia ID del usuario bloqueado
    • fallbackName es el nombre visible del usuario bloqueado
  • La ayuda de la cuenta de Google indicaba que era posible bloquear una cuenta desde YouTube, y en efecto, al bloquear a un usuario en una transmisión en vivo de YouTube, ese usuario aparecía en myaccount.google.com/blocklist
  • En la lista de bloqueados, el nombre del canal Mega Prime aparecía como fallbackName, y 107183641464576740691 aparecía como profile ID
  • Partiendo de la premisa de que un canal de YouTube no debería exponer la cuenta de Google subyacente, y dado que ya habían existido errores que convertían Gaia ID en direcciones de correo, se empezó a buscar una ruta adicional

Expansión a canales completos desde el menú del chat en vivo

  • Con solo abrir el menú de tres puntos en el chat en vivo de YouTube, se generaba una solicitud a /youtubei/v1/live_chat/get_item_context_menu
  • La respuesta incluía moderateLiveChatEndpoint y un valor params que llevaba a /youtubei/v1/live_chat/moderate
  • Ese params era un protobuf codificado en base64, algo común en Google, y al decodificarlo contenía el Gaia ID del usuario objetivo del bloqueo
    • La respuesta de ejemplo incluía 113907466537670370590 e identificadores relacionados con el canal
    • Era posible obtener el Gaia ID del objetivo sin ejecutar el bloqueo real
  • Al decodificar los parámetros de la solicitud get_item_context_menu, se veía el channel ID del canal que se quería bloquear, el ID del video del livestream y el ID del autor del livestream
  • Al probar cambiando el channel ID dentro de los parámetros, también se pudo obtener el Gaia ID 103261974221829892167 del Topic Channel generado automáticamente por YouTube

Pixel Recorder como vía para convertirlo a correo electrónico

  • Mientras buscaban bugs o fallas lógicas en productos antiguos de Google que permitieran convertir Gaia ID en correo electrónico, investigaron Pixel Recorder junto con nathan
  • Crearon una grabación de prueba en un teléfono Pixel, la sincronizaron con la cuenta de Google y luego usaron el endpoint web de recorder.google.com
  • Al compartir la grabación con un correo de prueba, la solicitud WriteShareList incluía el obfuscated Gaia ID en la lista de destinatarios compartidos
  • La respuesta de PlaybackService/WriteShareList en pixelrecorder-pa.clients6.google.com devolvía la dirección de correo del destinatario
    • La respuesta de prueba incluía vrptest2@gmail.com
    • Incluso al introducir el Gaia ID 107183641464576740691 obtenido en el experimento de bloqueo de YouTube, se devolvía redacted@gmail.com
  • Esto hacía posible una cadena de ataque en la que el Gaia ID obtenido desde YouTube se pasaba a la API de compartición de Pixel Recorder para averiguar la dirección de correo

El título de grabación de 2.5 millones de caracteres que bloqueó el correo de notificación

  • Al compartir una grabación de Pixel Recorder con la víctima, se enviaba una notificación por correo a la víctima, lo que podía reducir el impacto del ataque
  • En la ventana de compartición no había ninguna opción para desactivar la notificación, y al analizar el protobuf de la solicitud con req2proto tampoco apareció ningún campo para deshabilitarla
  • La estructura WriteShareListRequest tenía los siguientes campos
    • recording_id
    • delete_obfuscated_gaia_ids
    • update_shared_users
    • sharing_message
  • Incluso agregando y eliminando usuarios al mismo tiempo, el correo seguía enviándose
  • Como el asunto del correo de notificación incluía el título de la grabación, se concluyó que si el título era extremadamente largo, el envío del correo podía fallar
  • Se escribió y probó un script en Python que cambiaba el título de la grabación a 2.5 millones de caracteres mediante el endpoint UpdateRecordingTitle, y no había límite del lado del servidor para la longitud del título
  • Después de fijar el título en 2.5 millones de caracteres y compartirlo con otro usuario de prueba, no se envió el correo de notificación

PoC final y cronograma de gestión

  • La cadena de ataque final constaba de tres pasos
    • Obtener el obfuscated Gaia ID del canal objetivo desde el endpoint de Innertube /get_item_context_menu de YouTube
    • Compartir con el objetivo una grabación de Pixel Recorder con un título extremadamente largo para convertir el Gaia ID en dirección de correo
    • Eliminar después a ese usuario de la lista de compartición de la grabación de Pixel Recorder para limpiar rastros
  • El video PoC se ofrece como video de YouTube

Cronología de la recompensa y las correcciones de Google

  • 2024-09-15: se envió el reporte al proveedor
  • 2024-09-16: el proveedor hizo triage del reporte y respondió Nice catch!
  • 2024-10-03: el panel marcó el caso como duplicado de un bug ya rastreado y aplicó un parche incompleto a la exposición inicial del obfuscated Gaia ID en YouTube
  • 2024-10-03: se volvió a explicar al proveedor que Pixel Recorder también era en sí mismo una vulnerabilidad
    • El obfuscated Gaia ID también podía quedar expuesto en reseñadores de Google Maps y Google Play
    • También se proporcionó una vía alternativa para volver a filtrar el obfuscated Gaia ID de canales de YouTube
  • 2024-11-05: el panel otorgó una recompensa de $3,133
    • La justificación fue explotabilidad media
    • Se clasificó como metodología de abuso de alto impacto
  • 2024-12-03: el equipo de producto devolvió el reporte al panel para revisar una recompensa adicional y coordinó la fecha de divulgación para 2025-02-03
  • 2024-12-12: el panel otorgó una recompensa adicional de $7,500
    • La justificación fue explotabilidad alta
    • Se clasificó como metodología de abuso de alto impacto
    • Debido a la complejidad de la cadena de ataque, se aplicó una reducción de un nivel respecto al monto base
  • 2025-01-29: el proveedor pidió extender la fecha de divulgación al 2025-02-02
  • 2025-02-09: se confirmó que ambas partes de la cadena de ataque habían sido corregidas
    • Habían pasado 147 días desde el reporte inicial
  • 2025-02-12: se publicó el reporte

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-02-13
Opiniones de Hacker News

  • El título me confundió. Para quienes no leyeron hasta el final: no es que el correo filtrado haya generado un costo, sino que invirtieron tiempo e ingenio y recibieron una bug bounty de 10 mil dólares

    • Al principio pensé que significaba que ofrecían un servicio para filtrar correos de usuarios a 10 mil dólares por usuario
    • Yo también pensé que significaba que lo ofrecían como un servicio de 10 mil dólares
    • Puede que el título estuviera hecho para atraer clics
    • Al principio pensé que iba a tratarse de algo como el costo computacional de hacer fuerza bruta sobre algún hash

  • Hay mucho ruido sobre la divulgación responsable, la motivación y la recompensa, pero casi no veo que se diga que esto es otro argumento contra las identidades centralizadas permanentes
    Cada vez que un servicio afirma que funciona mejor cuando está vinculado a una sola Real Identity™, me da la impresión de que a las empresas solo les interesa proteger realmente a los usuarios en abstracto, y aun así solo a veces
    Imaginen que cualquiera con quien interactúes en YouTube pueda acercarse de inmediato tres o cuatro pasos más al doxxing; creo que ese es el impacto real de este bug. Me alegra que lo hayan corregido, pero no parece que este tipo de bugs vaya a desaparecer pronto. ¿Qué hará falta para que las empresas y las grandes corporaciones se den cuenta de que este diseño es un campo minado a punto de estallar?

    • En abstracto estoy de acuerdo. En este tipo de cuentas debería permitirse cierto grado de anonimato y descartabilidad. Al fin y al cabo, no son más que una fila en alguna base de datos
      Pero mucha gente hace transacciones con estas compañías usando dinero real. Por ejemplo, suscriptores de YouTube Premium o creadores de contenido. En la práctica, en algún lugar de esa cuenta descartable tienen que almacenarse identificadores de identidad real. Por el riesgo de fraude y la realidad de la banca, terminas entregándole a la empresa tu identidad y dirección reales, y la empresa también las almacena
      No le doy información que me identifique a apps o sitios web aleatorios, pero quien hace negocios conmigo inevitablemente sabe quién soy en la vida real y, en teoría, se convierte en un punto desde el cual esos datos pueden filtrarse
    • No les importa porque no hay consecuencias legales
      Si un proveedor de servicios de salud filtrara datos médicos, quedaría completamente destrozado

  • Es gracioso eso de “POC de exploit funcional: este video fue eliminado por infringir los Términos del Servicio de YouTube”

    • El autor del post original publicó la dirección de correo de un usuario real para la prueba de concepto. En el video resubido, la dirección de correo aparece difuminada
    • Al principio a mí también me aparecía así, pero al volver a abrir el artículo parece que el video ya se ve. No sé si lo acaban de restaurar

  • Como en cada tercer comentario de este hilo se dice que Google pagó muy poco por este bug, vale la pena hablar de algunos conceptos básicos sobre la valoración de vulnerabilidades:
    Las vulnerabilidades del lado del servidor valen menos porque las empresas no compiten por ellas. Prácticamente no hay un mercado gris para vulnerabilidades del lado del servidor. A un tercero le cuesta ponerle precio a un bug que Google puede matar de inmediato, que casi no tiene vida media desde el momento en que se descubre y que, al explotarse, genera telemetría confiable en el objetivo.
    En cambio, bugs como una cadena completa de Android/Chrome se venden por cientos de miles de dólares porque Google compite con un mercado gris bien formado. Un solo proveedor puede tomar ese bug y vendérselo a varias agencias de un país europeo, potencialmente a seis.
    Aun así, comparar recompensas con el mercado gris es comparar peras con manzanas. Google solo necesita una prueba de que se puede escribir el exploit, no un exploit altamente confiable, y tampoco necesita pagar costos de mantenimiento, así que paga mucho menos que el mercado gris. El valor total del resto del mercado se divide en varias etapas y viene con condiciones de riesgo, pero Google puede ofrecer una suma única atractiva aunque descontada.
    Los atacantes compran vulnerabilidades que encajan con sus procesos de negocio existentes. Por lo general no imaginan de forma especulativa todas las cosas geniales que podrían hacer con una vulnerabilidad nueva ni cómo ganar dinero con ella. Recolectar información de pago o conseguir miles de máquinas para una botnet son procesos de negocio existentes. ¿Exponer el nombre real de una cuenta de Google podría convertirse en un negocio? Tal vez. ¿Ya existe? Probablemente no.
    Los pagos de recompensas normalmente no son un plebiscito sobre qué tan ingenioso o interesante es un bug. Aunque aquí un poco sí lo es: 10.000 dólares por un bug web del lado del servidor se siente inusualmente alto.
    Para alguien que vive de encontrar bugs como este, la estrategia de negocio es volverse bueno encontrando muchos. No es como el desarrollo de exploits para iOS, donde se invierten meses en un solo exploit confiable.
    La investigación de vulnerabilidades que hice recientemente en mi carrera se parece más a esto que a muchas otras cosas, así que tengo bastante confianza en lo que digo. Aun así, en HN hay gente que hace este tipo de trabajo de recompensas a tiempo completo, así que me alegraría que alguien así me corrigiera.

    • En la mayoría de los demás campos, a la gente no se le paga según el valor en el mercado negro de lo que produce.
      Si aplicamos este análisis a otras cosas, el precio máximo de un estéreo nuevo para auto o de una bicicleta sería de unos 100 dólares, y el precio de todos los bienes con copyright estaría limitado al costo de transmitirlos por la red.
      Creo que es más útil dividir lo que pagó Google entre el tiempo dedicado a este trabajo y todo el tiempo de intentos fallidos de exploits desde la última recompensa.
      Sospecho que la mayoría en este campo gana menos que el salario mínimo de EE. UU. en relación con el esfuerzo, y está pagando un costo de oportunidad anual de seis cifras.
      Ese número muestra con precisión cuánto valora Google la seguridad y privacidad de los usuarios finales. Es una cifra mucho más baja que lo que les paga, por varios órdenes de magnitud, a otros ingenieros para robar la información personal de esas mismas personas.
    • No me gusta que este hilo de HN trate en su mayoría sobre el monto de la recompensa, pero también es natural. La mayoría de quienes comentan aquí trabajan en la industria del software y quieren normalizar recompensas muy altas.
      Para ellos, es una fuente adicional de ingresos. Así como quieren que la ingeniería de software sea una profesión bien pagada, también quieren que suban las recompensas por bugs. Es natural que los trabajadores pidan mejores salarios para su oficio, y ninguna racionalización va a cambiar ese instinto.
    • Dices que “los atacantes compran vulnerabilidades que encajan con sus procesos de negocio existentes”, pero ¿no hay mercado también para cosas como esta? Por ejemplo: “averigüemos quién está detrás de esta cuenta que critica a nuestra empresa/gobierno turbio y neutralicémoslo”.
      También hay incentivos separados del valor de mercado para atacantes. Una persona violenta que acosa a una celebridad de internet quizá no sea un cliente rentable en el mercado de exploits zero-day, pero si una empresa puede exponer por descuido la identidad de la víctima a un acosador violento, esa vulnerabilidad sigue siendo un riesgo de responsabilidad y ético.
      Personalmente, si se les paga sumas enormes a artistas de performance de LeetCode que producen cantidades enormes de código prestando atención imperfecta a la seguridad, creo que también se debería pagar bien a quienes ayudan a encontrar y corregir sus muchísimos errores antes de que pase algo malo.
    • Que las fuerzas de seguridad exploten bugs del lado del servidor es una zona mucho más gris, o puede ser directamente ilegal. En cambio, las fuerzas de seguridad o agencias de inteligencia ya tienen procedimientos estándar para obtener órdenes judiciales que les permitan explotar el dispositivo de un objetivo específico, como un teléfono o una laptop.

  • Dice que hubo una “reducción de 1 nivel respecto del monto base por la complejidad de la cadena de ataque requerida”; ¿eso es común?
    Solo he participado en unos pocos programas de vulnerabilidades, pero la mayoría pagaba menos cuando se trataba de una falla ridículamente simple pero grave, como que el email del usuario apareciera en el código fuente de la página.

    • Yo entendí lo contrario: que se le aplicó una penalización porque era relativamente compleja para una vulnerabilidad web.
    • Esto me parece al revés. En la práctica encontró 2 bugs, así que deberían haber subido el monto base.

  • Dice: “Hace poco, mientras buscaba objetivos de investigación en Google, estaba explorando la documentación de discovery de Internal People API (Staging)”; ¿está bien que esto simplemente sea público?: https://staging-people-pa.sandbox.googleapis.com/$discovery/...

    • Es solo un archivo de esquema convertido automáticamente a partir de definiciones internas .proto. Google no depende de la seguridad por oscuridad, sino de criptografía real.
      Además, los endpoints de discovery están documentados públicamente[0] y fueron creados para usuarios externos. Alguien interno no leería el endpoint de discovery; vería directamente el archivo .proto en la búsqueda de código.
      Por mi experiencia trabajando en Google, para exponer una API públicamente había que pelear con la burocracia durante semanas. No es como un bucket de AWS S3 expuesto por accidente. El equipo sabía que esto era público y probablemente atravesó la burocracia para hacerlo público.
      [0]: https://developers.google.com/discovery/v1/getting_started

  • Si miramos la cronología del texto, se reportó a la empresa el 2024-09-15; el 2025-01-29 la empresa pidió extender la divulgación hasta el 2025-02-12; el 2025-02-09 se confirmó que ambos lados del exploit ya estaban corregidos; y el 2025-02-12 se hizo público.
    Entonces, ¿no estuvo 136 días sin corregirse y Google pidió una extensión? Fueron 147 días hasta la corrección y 150 días hasta la divulgación.
    Comparado con el plazo de divulgación antes de la corrección que Google Project Zero da a otras empresas, dicen: “Este bug está sujeto a un plazo de divulgación de 90 días. Si se pone una corrección a disposición de los usuarios antes del plazo de 90 días, este reporte de bug se hará público 30 días después de que la corrección esté disponible. De lo contrario, se hará público al cumplirse el plazo”.
    “Si se espera que el parche salga dentro de los 14 días posteriores al vencimiento del plazo, Project Zero puede otorgar una extensión… Sin embargo, como el periodo de gracia de 14 días se superpone con el periodo de 30 días para aplicar el parche, las vulnerabilidades corregidas dentro del periodo de gracia se divulgarán, a más tardar, el día 120 desde el plazo original de 90 días”.
    “Si se determina que la corrección no estará lista dentro de 14 días, usamos el plazo original de 90 días como momento de divulgación. Es decir, solo otorgamos la extensión de gracia de 14 días cuando el desarrollador se compromete a publicar la corrección dentro de ese periodo de gracia de 14 días”.
    https://googleprojectzero.blogspot.com/p/vulnerability-discl...

    • No creo que esta comparación sea útil. Este es un bug de Google en software de Google, y entiendo que lo que Project Zero suele encontrar son bugs en software usado por muchas personas, por lo que la urgencia de corregirlos es mayor.

  • Eso de que “esos params son simplemente protobuf codificado en base64, y es un formato de codificación común en todo Google”... Hay que invitarle un trago al desarrollador de Google responsable de tomar un elegante formato de mensajes binarios, codificarlo en base64 y meterlo a la fuerza en un bloque de JSON.
    Si quieren ver el futuro, imaginen una bota con “worse is better” grabado en la suela, pisoteando el rostro de un ingeniero para siempre.

    • Esto está en todas partes y es lo peor. A veces me pregunto si no habrá más bytes de protobuf representados en base64 dentro de JSON que bytes reales de protobuf viajando por las líneas de internet, y entonces me sirvo un trago.
    • Internamente probablemente sea un protobuf en base64 dentro de un campo protobuf.
      La parte JSON es una conversión automática.
    • Una cadena JSON de un protocol buffer codificado en base64... No sé qué empresa lo hizo, pero sí sé qué empresa lo hizo.

  • La guinda del pastel es que rompieron el sistema de correo electrónico e hicieron que no se enviaran los mails. En una megacorporación como Google, que ha creado muchísimos productos, la seguridad se siente falsa.
    Si cada línea de código es una vulnerabilidad potencial, con millones de líneas simplemente se vuelve inevitable. No parece haber otra forma que mantenerlo simple, por ejemplo, deshacerse del sitio recorder, pero aun así no es fácil.

    • Puede ser otra razón por la que Google mata tantos productos que fueron exitosos, pero no lo bastante como para mantenerlos vivos y seguros dentro de todo el sistema de Google.
    • Lamentablemente, considerando la cantidad de usuarios de Google, cualquier cierre provocará gritos de dolor y reclamos del tipo “dependo de eso para calentar mi computadora con la barra espaciadora”. Basta ver https://killedbygoogle.com/.
    • Me gustaría que dieran un ejemplo de seguridad que se sienta “real” y cómo eso ayuda.
      La mayoría de los productos de software dependen de un stack de software muy complejo, y si confías al 100% en todas las bibliotecas que usas y en el sistema operativo, creo que tienes una mentalidad equivocada. Incluso los procesadores han tenido bugs como Meltdown. La seguridad es una lucha continua; nunca puedes saber si ganaste, y solo a veces te enteras de que perdiste.
    • En esencia, estás proponiendo algo como una ecuación de Drake[1] para calcular la cantidad de vulnerabilidades de seguridad según la cantidad de líneas de código. ¿Qué otros factores entrarían en esa ecuación?
      [1] https://en.wikipedia.org/wiki/Drake_equation
    • El punto es que la seguridad es falsa. Ninguna app es realmente segura. Aunque gastes millones de dólares en seguridad de aplicaciones, un solo error de un usuario humano puede abrir una brecha.

  • Yo también malinterpreté el título como algo tipo 10.000 dólares de costo de cómputo en GPU. Viendo que eligieron un viejo producto de Google y enseguida le encontraron un agujero, parece que debe haber decenas o cientos de bugs más así.

    • No funciona como “eligieron un viejo producto de Google y enseguida le encontraron un agujero”. Lo más probable es que el autor haya investigado varios productos durante semanas o meses hasta encontrar algo valioso.
    • Yo también lo malinterpreté como que querían vender direcciones de correo de YouTubers por 10.000 dólares.