Fuga en Vercel: Cómo el Hackeo de OAuth Comprometió las Variables de Entorno

# Incidente de seguridad en Vercel: Cómo una filtración de OAuth llevó al compromiso de variables de entorno

La plataforma de desarrollo en la nube Vercel confirmó acceso no autorizado a sus sistemas internos después de que la cuenta de un empleado fuera comprometida mediante una app OAuth maliciosa en Google Workspace. El incidente fue posible gracias a una filtración de datos en la plataforma de IA de terceros Context.ai, lo que permitió al atacante acceder a variables de entorno no marcadas como confidenciales.

Aunque los servicios principales de Vercel siguieron funcionando sin interrupciones y los datos de los clientes permanecieron encriptados e intactos, la brecha expuso debilidades críticas en la gestión de secretos y la dependencia de integraciones de terceros. La empresa notificó de inmediato a las autoridades policiales, contrató expertos externos en respuesta a incidentes e implementó actualizaciones en el panel de control para reforzar el control sobre las variables confidenciales.

Cómo ocurrió la brecha

El ataque se originó en la cuenta de Google Workspace de un empleado de Vercel. El atacante obtuvo acceso después de que las credenciales de la cuenta se filtraran en la plataforma Context.ai, que utiliza IA para automatizar flujos de trabajo. A través de esta cuenta, se autorizó un token OAuth para la app con ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com.

Esta app, desarrollada por una herramienta de terceros, tenía permisos excesivos, incluidos accesos a recursos internos de Google Workspace. Una vez obtenido el token, el atacante se movió lateralmente hacia la infraestructura de Vercel y accedió a variables de entorno no marcadas explícitamente como confidenciales. En estos casos, Vercel no las encripta en reposo, confiando en su lugar en las clasificaciones establecidas por los administradores.

Qué se vio comprometido

Según publicaciones en foros de hackers, el atacante, conocido como "ShinyHunters", afirmó estar vendiendo los siguientes datos:

• Claves API (incluidas tokens de NPM y GitHub)
• Acceso a despliegues internos de Vercel Enterprise
• Código fuente de herramientas internas
• Base de datos con 580 registros de empleados (nombres, correos corporativos, estados de cuentas, marcas de tiempo de actividad)
• Capturas de pantalla del panel de control interno

Sin embargo, Vercel ha confirmado oficialmente solo un acceso parcial a variables de entorno y niega cualquier compromiso de datos de clientes o proyectos públicos como Next.js y Turbopack. Todas las variables de clientes marcadas como secretas permanecen encriptadas e inaccesibles.

Recomendaciones de Vercel para desarrolladores

La empresa insta encarecidamente a todos los usuarios, especialmente a los propietarios de cuentas empresariales, a tomar estas medidas:

• Revisar la lista de apps OAuth autorizadas en Google Workspace y revocar el acceso a cualquier app sospechosa o no utilizada.
• Auditar las variables de entorno: asegúrate de que todos los datos sensibles (claves API, tokens, contraseñas) estén marcados como confidenciales en el panel de Vercel.
• Habilitar la función de revisión de variables confidenciales, ahora disponible en el panel actualizado.
• Rotar todas las claves y tokens que puedan haber estado expuestos, incluso si se almacenan en variables no confidenciales.
• Configurar autenticación multifactor y políticas de acceso condicional para todas las cuentas con acceso a la infraestructura.

Lecciones para equipos de DevOps y SRE

El incidente de Vercel resalta lo frágil que puede ser la cadena de confianza con integraciones de terceros. Incluso en una infraestructura madura y multicapa, un solo token OAuth comprometido puede permitir movimiento lateral.

Lecciones clave para equipos técnicos:

• El principio de privilegio mínimo debe aplicarse a las apps OAuth, no solo a los usuarios. Los permisos deben limitarse estrictamente al mínimo indispensable.
• La clasificación automática de secretos supera siempre a la manual. Permitir variables sin encriptar por defecto crea una falsa sensación de seguridad.
• El monitoreo de actividad anómala en el proveedor de identidad (por ejemplo, Google Workspace) debe ser fundamental en la estrategia del centro de operaciones de seguridad. Ubicaciones geográficas inusuales, nuevos dispositivos o solicitudes masivas de API son señales de alerta para una revocación inmediata de tokens.

Puntos clave

• La filtración comenzó con el compromiso de una cuenta a través de la plataforma de IA de terceros Context.ai.
• El acceso a datos fue posible porque las variables sensibles carecían de la marca confidencial.
• Los datos encriptados de clientes no fueron comprometidos.
• Vercel lanzó actualizaciones del panel para mejorar la gestión de secretos.
• El ataque subraya los riesgos de las integraciones OAuth y la confianza en servicios de terceros.

— Editorial Team