Reports
CRÍTICA[EXPOSICIÓN DE DATOS]#2915647

Un token de Netlify de Mozilla quedó a la vista en los logs públicos de su CI

Un log público de una tarea de Firefox CI mostraba en claro un token de la API de Netlify con acceso a la cuenta "Mozilla IT Web SRE", de la que dependía crash-pings.mozilla.org.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

Mozilla ejecuta sus tareas de integración continua en Firefox CI (Taskcluster), y los logs de esas tareas se pueden consultar públicamente. En uno de ellos, el live.log de una tarea concreta, aparecía impreso en claro un token de autenticación de la API de Netlify. Con ese token se podía hablar con la API de Netlify en nombre de la cuenta de equipo Mozilla IT Web SRE, asociada, entre otros, al sitio https://crash-pings.mozilla.org.

No hacía falta ninguna técnica especial: bastaba con abrir el log, buscar la cadena auth: y copiar el valor que la seguía. El investigador lo comprobó llamando a la API de Netlify y obteniendo los datos de la cuenta (plan Enterprise, configuración SAML, datos de facturación, IDs de los propietarios, etc.).

Datos del caso:

  • Programa: Mozilla
  • Debilidad: Information Disclosure (exposición de un secreto en logs)
  • Severidad indicada: crítica
  • Enviado: 27-dic-2024 · Divulgado: 13-may-2025
  • Estado: resuelto, con recompensa (importe no público)

Pasos de reproducción

  1. Abrir en el navegador el log público de la tarea de Firefox CI:
https://firefox-ci-tc.services.mozilla.com/tasks/d5NRF8FdQamV9XdPO_mTBQ/runs/0/logs/public/logs/live.log
  1. Buscar dentro del fichero la palabra clave auth:. Junto a ella aparecía el token de Netlify sin ningún tipo de enmascarado.
  1. Comprobar que el token es válido consultando el endpoint de cuentas de la API de Netlify:
curl -X GET https://api.netlify.com/api/v1/accounts -H "Authorization: Bearer [REDACTADO]" -s | jq
  1. La respuesta devuelve la información de la cuenta. Un extracto de lo que mostró el investigador (se han omitido datos identificativos):
[
  {
    "name": "Mozilla IT Web SRE",
    "slug": "mozilla-it",
    "role": "Developer",
    "selected_access_site_ids": [
      "5a05c659-aa54-4184-bdbe-7faa4dd497b5"
    ],
    "billing_name": "it-sre",
    "billing_email": "[REDACTADO]",
    "roles_allowed": [
      "Owner",
      "Developer",
      "Billing Admin",
      "Reviewer",
      "Publisher",
      "Content Editor"
    ],
    "saml_enabled": true,
    "enforce_saml": "enforced_strict",
    "org_mfa_enabled": false,
    "type_name": "Enterprise",
    "owner_ids": ["[REDACTADO]", "..."],
    "has_builds": true
  }
]
  1. A partir de ahí, según el investigador, el mismo token servía para el resto de endpoints de la API de Netlify (https://open-api.netlify.com): desplegar, modificar o borrar sitios y leer logs, variables de entorno o configuración.

Un detalle que conviene leer con cuidado: el campo role de la respuesta es Developer, mientras que roles_allowed es la lista de roles que existen en la cuenta. El reporte presenta el token como de acceso total (propietario, facturación, etc.); el original no muestra ninguna acción de escritura que lo confirme, solo la consulta de lectura anterior y un vídeo de prueba que no es público.

Impacto

Con un token válido de la cuenta de Netlify, un atacante podría, según el reporte:

  • Comprometer el sitio crash-pings.mozilla.org: modificarlo, borrarlo o desplegar contenido malicioso bajo un dominio de Mozilla.
  • Leer datos sensibles de la configuración: variables de entorno, logs y ajustes de los sitios.
  • Usar la cuenta para alojar phishing o contenido malicioso, con el consiguiente daño reputacional.
  • Borrar sitios y configuraciones, provocando un daño difícil de revertir.
  • Tocar la facturación: el investigador menciona cambiar el billing_email de la cuenta para desviar pagos.

Además, la propia consulta de lectura ya exponía información interna: configuración SAML del proveedor de identidad, IDs de los propietarios de la cuenta, periodos de facturación y plan contratado.

Remediación

El reporte figura como resuelto, pero no detalla qué hizo Mozilla. Las medidas que propuso el investigador fueron:

  • Revocar de inmediato el token expuesto y avisar a los afectados.
  • Revisar los pipelines de CI/CD para que los secretos se enmascaren en los logs.
  • Restringir el uso de los tokens (ámbitos limitados o lista de IPs permitidas) y vigilar el uso anómalo de la API.

Qué aprender de este caso

  • Los logs de CI de proyectos abiertos (Taskcluster, GitHub Actions, GitLab CI) suelen ser públicos y se pueden rastrear: buscar en ellos cadenas como auth:, token, Bearer o Authorization es una vía real de encontrar secretos vivos.
  • Cualquier paso del pipeline que imprima su configuración o los argumentos de una herramienta de despliegue puede acabar volcando un token en el log. Conviene registrar los secretos como "enmascarados" en el sistema de CI y evitar los modos verbosos que muestran la configuración completa.
  • Los tokens que se usan en CI deberían limitarse a lo mínimo que necesita la tarea. Aquí el token filtrado respondía a /api/v1/accounts con datos de toda la cuenta del equipo.
  • Al validar un token filtrado basta con una llamada de solo lectura como la de este reporte; no hace falta (ni conviene) desplegar o borrar nada para demostrar el impacto.