In early 2018, an 18-year-old programmer named Ezequiel Pereira from Uruguay got access to a non-Production App Engine deployment environment where he was able to use internal APIs and it was considered as Remote Code Execution due to the way Google works. Thanks to this, the programmer got a reward of more than $36k as part of Google Vulnerability Rewards Program.
Toying with a non-production GAE deployment environment, he came up with a new way to find which websites and web services are using Google’s web framework & Google’s cloud computing platform for hosting their web applications and services.
He mentioned that in his blog:
“Some time ago, I noticed every Google App Engine (GAE) application replied to every HTTP request with an “X-Cloud-Trace-Context” header, so he 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.”
After discovering that appengine.google.com itself runs on GAE, Pereira started looking for ways to access the “API, interface, or something only available to applications” run by Google.
“I had already seen [“stubby”] mentioned before in error messages from some Google products… so I knew it was a RPC infrastructure, and it might be a way for appengine.google.com to perform internal actions,” he stated.
While Pereira initially could not find a way to access the “stubby” RPC in the production GAE deployment environment, he leveraged another bug (which accounted for over $5,000 of the bounty) that enabled him to enter Google’s staging and test environments.
This was the final piece of the puzzle, as the more relaxed security of these environments granted access to the “stubby” RPC server, which returned a “nice rpc.ServiceList listing all the services (and their methods) the target supports”.
“After discovering this, I did some testing, but I was not able to find any “stubby” call that I considered dangerous,” he said. “Nevertheless, I reported this to Google and it got a P1 priority.”
Interestingly, following the initial report, Pereira pulled focus on another argument he received from his Java launcher binary named app_config_service, which could allow anyone with access to change application configuration settings directly on the endpoint.
“After discovering this, I reported the new findings to Google and they bumped the priority of the internal ticket,” he said. “I was not aware until then that this was regarded as remote code execution (the highest tier for bugs).”
While Google provided little details surrounding the flaw, a reward panel member told Pereira: “It is RCE for the way Google works”.
This comment, along with the huge bounty handed to the researcher, suggests the bug could have enabled an attacker to read files, open connections, or perhaps even carry out reconnaissance on the tech giant’s own internal network.
If you are also interested in bug hunting and want to participate in bug bounty programs, you should check our article on Top 10 Bug Bounty Programs for Ethical Hackers.
Thanks