O Google concedeu ao estudante de 18 anos, Ezequiel Pereira, um total de US $ 36.337 pela descoberta de uma vulnerabilidade crítica de execução remota de código que afetava o Google App Engine.

O Google App Engine é uma estrutura que permite que os utilizadores do Google desenvolvam e hospedem aplicativos Web numa plataforma totalmente serverless.

Em fevereiro, Pereira ganhou acesso a um ambiente de desenvolvimento do Google App Engine que não era de produção. Depois, descobriu que era possível usar algumas das APIs internas do Google.

Pereira reportou eticamente o problema por meio do Google’s Vulnerability Reward Program (VRP). Os especialistas do Google classificaram a falha como uma prioridade P1, um nível que é atribuído a vulnerabilidades que poderiam ter um impacto significativo sobre um grande número de utilizadores e que, por esse motivo, devem ser resolvidas o mais rápido possível.

Enquanto isso, Pereira continuou o teste e enviou um segundo relatório ao Google. Depois de descobrir outros problemas, o Google indicou ao investigador para interromper as atividades devido ao risco de “quebrar algo” usando as APIs internas”.

A equipa de segurança do Google descobriu que a falha descoberta pelo jovem permitia  a execução remota de código.

google-flash-ad-html5

 

Pereira publicou uma análise em detalhe do seu trabalho depois do Google corrigir os problemas.

“In early 2018 I got access to a non-production Google App Engine deployment environment, where I could use internal APIs and it was considered as Remote Code Execution due to the way Google works. Thanks to this I got a reward of $36,337 as part of Google Vulnerability Rewards Program.” reads the blog post published by the researcher.

“Some time ago, I noticed every Google App Engine (GAE) application replied to every HTTP request with a “X-Cloud-Trace-Context” header, so I assumed any website returning that header is probably running on GAE.
Thanks to that, I learned “appengine.google.com” itself runs on GAE, but it can perform some actions that cannot be done anywhere else and common user applications cannot perform, so I tried to discover how was it able to do those actions.
Obviously, it has to make use of some API, interface or something only available to applications ran by Google itself, but maybe there was a way to access them, and I looked for that.”

Below the timeline for the flaw:

  • February 2018: Issue found
  • February 25th, 2018: Initial report (Only the “stubby” API)
  • March 4th and 5th, 2018: The “app_config_service” API discovered and reported
  • March between 6th and 13th, 2018: The access to non-prod GAE environments was blocked with a 429 error page
  • March 13th, 2018: Reward of $36,337 issued
  • May 16th, 2018: Issue confirmed as fixed