A Google pagou uma recompensa de US$ 90 mil ao pesquisador de segurança Simon Köck após ele descobrir uma vulnerabilidade não documentada de execução remota de comandos no DevSite, a plataforma compartilhada que sustenta o developers.google.com e outros sites de documentação. Köck comunicou o problema em 6 de agosto, a Google aceitou o relatório no dia seguinte e aprovou a recompensa em 27 de agosto, mas a correção chegou aos servidores em 7 de outubro.
A Google classificou a vulnerabilidade como S0, o nível mais alto de sua escala de gravidade, e concedeu a Köck um valor-base de US$ 75 mil por uma vulnerabilidade de RCE na camada normal de aplicações, com um aumento de 20% devido à qualidade excepcional do relatório.
Três erros formaram a cadeia de exploração
O DevSite armazenava um objeto OAuth2WebServerFlow serializado da biblioteca oauth2client, abandonada, dentro de um cookie de sessão do Flask. Isso expunha um segredo de cliente OAuth, mas o problema se tornou mais grave porque o mesmo segredo também era usado como chave para assinar sessões Flask.
Köck conseguiu reproduzir localmente a assinatura dos cookies e criar sessões forjadas aceitas pelo servidor. Como o fluxo OAuth usava pickle para desserializar os dados da sessão, ele conseguiu substituir o objeto por uma carga pickle maliciosa assinada e, em seguida, comprovar a execução remota de código Python.
O pesquisador confirmou a execução usando uma carga que atrasava a resposta por meio de um comando sleep e interrompia intencionalmente antes de executar comandos reais ou acessar arquivos, credenciais ou serviços internos. Segundo seu relato, as sessões forjadas foram aceitas nos sete domínios afetados, enquanto o teste de prova de conceito foi realizado em três domínios: developers.google.com, docs.partner.android.com e web.dev.
O alcance do impacto não foi totalmente determinado
Köck não comprovou se o servidor conseguia modificar o conteúdo da documentação da Google ou substituir comandos de instalação e links de download, um cenário que poderia abrir caminho para um ataque à cadeia de suprimentos de software. Ele também não testou se as sessões forjadas permitiam personificar usuários ou acessar seus dados.
O pesquisador Arvin Shivram, conhecido como @brutecat, observou que aplicações internas do App Engine normalmente podem acessar o Stubby, o sistema interno da Google para comunicação entre serviços. Köck afirmou que esse acesso, caso estivesse disponível para esse processo, poderia ampliar significativamente o impacto, mas não verificou as permissões do DevSite nem o alcance de seu acesso aos serviços de backend.
Por que esta notícia importa?
O caso revela que o risco não resultou de um único erro, mas da combinação de três práticas: expor um segredo sensível dentro de um cookie, reutilizá-lo como chave de assinatura e usar desserialização insegura de dados não confiáveis. Corrigir qualquer elo dessa cadeia teria sido suficiente para interromper o caminho de exploração, o que torna a separação de segredos e a rejeição do pickle em dados de sessão controles essenciais, e não melhorias opcionais.
Por outro lado, o prazo de correção, que se estendeu por cerca de dois meses, levanta questões operacionais que a Google não respondeu. A empresa não esclareceu se aplicou medidas temporárias de mitigação, se trocou as duas chaves de assinatura diferentes que, segundo Köck, eram usadas pelos sete domínios, ou se invalidou as sessões existentes. Também não divulgou um resultado forense sobre a possibilidade de exploração da vulnerabilidade antes da publicação da correção e não havia respondido ao pedido de comentário do The New Stack quando o artigo foi atualizado.