El fallo de 90.000 dólares de Google: reutilización de secretos OAuth y deserialización con pickle

Simon Köck, ingeniero de software en Otark GmbH, descubrió en agosto de 2026 una vulnerabilidad crítica de ejecución remota de código en la infraestructura DevSite de Google. El fallo permitía a atacantes no autenticados ejecutar código arbitrario en los servidores que alojan developers.google.com y sitios de documentación relacionados. Google calificó el problema como S0, su nivel de severidad más alto, y pagó a Köck una recompensa de 90.000 dólares, aunque tardó dos meses en desplegar una corrección.

Qué ocurrió

La vulnerabilidad existía en DevSite, la plataforma compartida que impulsa siete dominios de documentación para desarrolladores de Google. Köck identificó que la aplicación almacenaba un objeto OAuth2WebServerFlow serializado de la librería obsoleta oauth2client dentro de una cookie de sesión de Flask. Esta configuración exponía inadvertidamente el secreto del cliente OAuth dentro de los datos de la cookie. Más críticamente aún, Google había reutilizado ese mismo secreto del cliente OAuth como clave de firma para las sesiones de Flask.

Dado que el secreto estaba tanto expuesto en la cookie como utilizado para firmarla, Köck podía reproducir la firma sin conexión. Esto le permitía forjar cookies de sesión válidas que el servidor aceptaría sin cuestionarlas. Demostró que las sesiones forjadas eran aceptadas en los siete dominios afectados, los cuales dependían de dos claves de firma diferentes. Ejecutó con éxito su código de prueba de concepto en tres de estos hosts: developers.google.com, docs.partner.android.com y web.dev.

Köck confirmó la ejecución remota de código sin autenticación enviando una carga útil de sueño (sleep) en Python y midiendo los retrasos en la respuesta. Evitó deliberadamente ejecutar comandos que tocaran archivos, credenciales o servicios internos para prevenir daños reales. Google le otorgó un pago base de 75.000 dólares por una ejecución remota de código S0 en una capa de aplicación normal, multiplicado por 1,2 debido a la calidad excepcional de su informe.

Cómo funciona

La cadena de exploits se basaba en la alineación simultánea de tres fallos de seguridad específicos. Primero, la aplicación exponía un valor secreto dentro de una cookie del lado del cliente. Segundo, ese mismo secreto era reutilizado como clave de firma criptográfica para la sesión, lo que permitía a un atacante crear firmas válidas para cookies modificadas. Tercero, la aplicación utilizaba el módulo pickle de Python para deserializar los datos de la sesión durante el proceso de devolución de llamada (callback) de OAuth.

Se sabe que Pickle es inseguro para datos no confiables porque puede ejecutar código arbitrario durante la deserialización. Al sustituir el objeto de flujo legítimo en la cookie con una carga útil maliciosa de pickle y firmarla con el secreto expuesto, Köck obligó al servidor a ejecutar su código cuando procesaba la sesión. Arreglar cualquiera de estos tres problemas —ocultar el secreto, usar una clave de firma separada o evitar pickle— habría roto la cadena de ataque.

Detalles clave

• Sistemas afectados: Siete dominios de documentación para desarrolladores de Google, incluyendo developers.google.com, docs.partner.android.com y web.dev.
• Tipo de vulnerabilidad: Ejecución remota de código sin autenticación mediante deserialización insegura y reutilización de claves.
• Causa raíz: Reutilización de un secreto de cliente OAuth como clave de firma de sesión de Flask y uso de pickle de Python para los datos de sesión.
• Severidad: Calificada como S0 por Google, el nivel más alto en su escala de severidad.
• Recompensa: 90.000 dólares pagados al investigador Simon Köck.
• Tiempo de remediación: Reportado el 6 de agosto de 2026; corrección desplegada el 7 de octubre de 2026.

Por qué importa

Para los equipos de ingeniería, este incidente destaca los peligros de la reutilización de claves criptográficas y las dependencias de librerías heredadas. Usar un secreto para múltiples propósitos, como autenticación y firma de sesiones, crea un único punto de fallo. Si un uso expone el secreto, todas las demás protecciones que dependen de ese secreto colapsan. Además, continuar utilizando librerías obsoletas como oauth2client en lugar de alternativas modernas como google-auth puede introducir anti-patrones y vulnerabilidades conocidas en nueva infraestructura.

La brecha de dos meses entre la aprobación de la recompensa y el despliegue del parche también plantea preocupaciones operativas. Aunque Google no explicó el retraso, estas ventanas dejan los sistemas expuestos a una posible explotación después de que el proveedor sea consciente del fallo. Los investigadores de seguridad a menudo se preocupan por si se aplican mitigaciones interinas, especialmente cuando el radio de impacto total es desconocido. En este caso, sigue sin estar claro si el atacante podría haber accedido al sistema interno de comunicación servicio-a-servicio Stubby de Google o modificado el contenido de la documentación para ataques a la cadena de suministro.

Qué puedes hacer

• Audita tus aplicaciones en busca de cualquier reutilización de secretos entre diferentes funciones criptográficas, como firma y cifrado.
• Reemplaza el módulo pickle de Python por formatos de serialización seguros como JSON o Protocol Buffers para cualquier dato originado por usuarios.
• Migra desde librerías obsoletas, como oauth2client, hacia alternativas compatibles como google-auth.
• Asegúrate de que las claves de firma de sesión sean distintas de los secretos de cliente OAuth y otras credenciales de autenticación.
• Implementa escaneo automatizado para patrones de deserialización insegura en tu base de código.
• Establece objetivos claros de nivel de servicio para los tiempos de remediación de vulnerabilidades para minimizar las ventanas de exposición.