Google pagó una recompensa de 90.000 dólares al investigador de seguridad Simon Köck tras descubrir una vulnerabilidad no documentada de ejecución remota de comandos en DevSite, la plataforma compartida que sustenta developers.google.com y otros sitios de documentación. Köck informó del problema el 6 de agosto, Google aceptó el informe al día siguiente y aprobó la recompensa el 27 de agosto, pero la corrección llegó a los servidores el 7 de octubre.
Google clasificó la vulnerabilidad con el nivel S0, el más alto de su escala de gravedad, y concedió a Köck una cantidad base de 75.000 dólares por una vulnerabilidad RCE en la capa de aplicaciones ordinaria, con un aumento del 20% debido a la calidad excepcional del informe.
Tres errores formaron la cadena de explotación
DevSite almacenaba un objeto OAuth2WebServerFlow serializado de la biblioteca obsoleta oauth2client dentro de una cookie de sesión de Flask. Esto expuso un secreto de cliente OAuth, pero el problema se volvió más grave porque el mismo secreto también se utilizaba como clave para firmar las sesiones de Flask.
Köck logró reproducir localmente la firma de las cookies y crear sesiones falsificadas que el servidor aceptaba. Como el flujo OAuth utilizaba pickle para deserializar los datos de sesión, pudo sustituir el objeto por una carga maliciosa de pickle firmada y demostrar la ejecución remota de código Python.
El investigador confirmó la ejecución mediante una carga que retrasaba la respuesta con un comando sleep y se detenía deliberadamente antes de ejecutar comandos reales o acceder a archivos, credenciales o servicios internos. Según su relato, las sesiones falsificadas fueron aceptadas en los siete dominios afectados, mientras que la prueba de concepto se ejecutó en tres dominios: developers.google.com, docs.partner.android.com y web.dev.
El alcance del impacto no se determinó por completo
Köck no demostró si el servidor podía modificar el contenido de la documentación de Google o sustituir comandos de instalación y enlaces de descarga, un escenario que podría haber abierto la puerta a un ataque contra la cadena de suministro de software. Tampoco probó si las sesiones falsificadas permitían suplantar a usuarios o acceder a sus datos.
El investigador Arvin Shivram, conocido como @brutecat, señaló que las aplicaciones internas de App Engine normalmente pueden acceder a Stubby, el sistema interno de Google para la comunicación entre servicios. Köck afirmó que este acceso, si estaba disponible para ese proceso, podría ampliar considerablemente el impacto, pero no verificó los permisos de DevSite ni el alcance de su acceso a los servicios backend.
¿Por qué importa esta noticia?
El caso revela que el riesgo no surgió de un único error, sino de la combinación de tres prácticas: exponer un secreto sensible dentro de una cookie, reutilizarlo como clave de firma y utilizar una deserialización insegura para datos no confiables. Corregir cualquiera de los eslabones de esta cadena habría bastado para cortar la vía de explotación, lo que convierte la separación de secretos y el rechazo de pickle en los datos de sesión en controles fundamentales, no en mejoras opcionales.
En cambio, el plazo de corrección, que se extendió aproximadamente dos meses, plantea preguntas operativas que Google no respondió. La empresa no aclaró si aplicó medidas de mitigación temporales, si sustituyó las dos claves de firma diferentes que, según Köck, utilizaban los siete dominios, o si invalidó las sesiones existentes. Tampoco reveló un resultado forense sobre la posibilidad de que la vulnerabilidad hubiera sido explotada antes de la publicación del parche, y no había respondido a una solicitud de comentarios de The New Stack cuando se actualizó el artículo.