A while back I was researching Google Maps ‘timeline’ feature, and specifically the capability to add your own ‘places’. I was trying to replicate a previous XSS I found in the ‘export as KML’ feature, and thought the custom place ‘name’ could be a good spot to place my payload. As I was poking around, suddenly something caught my eye - one of the ‘places’ I entered was displayed incorrectly. I couldn’t remember what ‘name’ I entered, but I was sure it was not what was displayed:
What? Placeholder? What’s going on here?
Initial discovery
I set about trying to reproduce the result above. I initially thought that, perhaps, I entered something along the lines of “aaaaaaa}” (notice the curly brackets), and somehow these curly brackets ‘closed’ the input, allowing me to ‘inject’ free chars, and then something got broken.
Following this line of thought, I tried inputting the payload “aaa{}”. I didn’t get the result I was looking for, but instead something else happened - Suddenly, the GUI ‘hang’ and I could not continue working without a hard refresh. Reviewing the network requests, I finally found that the response for the “aaa{}” payload was a ‘500 error’ from the server that subsequently caused something to break on the client side.
Further testing showed that any payload into the ‘place’ name that contains a curly bracket will cause the server to fail.
Encouraged by these initial results, I kept attempting more & more payloads, until I finally was able to reproduce the 'placeholder' issue by entering a payload of the form “xxxxxx’ ” (i.e. any char ending with a single quote).
So now I had two working ‘payloads’ that break something, one error recoverable and one not, which led me to two conclusions:
The server is using the client-provided ‘place name’ while generating the client side page, using some sort of template.
The input validation is lacking, and the client can interfere with the template structure.
In other words - we had here a clear case of server-side-template-injection!
I continued to poke around until I managed to build a payload that injects ‘harmless’ content without breaking the template, of the form “ANYTEXT}=2 {ANYTEXT}ANYTEXT{ANYTEXT'”
The results can be seen here:
Is it exploitable?
As exciting all of this research was, I still could not really point to an actual risk. Encouraged by amazing research on SSTI vulnerabilities I wanted to do something scary, to reference environment variables, to read sensitive data, even to run server side code… but I managed to do absolutely nothing. Not knowing which template engine I was working with, I had very little knowledge on how to move forward with this research.
Google has this awesome policy of rewarding the researcher for maximum potential damage, even if it was not demonstrated (you can read about it in the FAQ section of their policy) and so I decided to report this ‘as is’ and hope for the best.
Days after my initial report, I received a response that made me feel both confident and unconfident at the same time:
So, the positive side was that Google’s team was able to reproduce this, identified this indeed as SSTI, and even were kind enough to clue me in into what template is used.
The not-so-positive side was that Google’s team was clearly struggling to exploit this just as I was, and while I could excuse my own difficulties to my general blindness of the system internals, if Google’s engineers could not find a way to abuse this then it might not be possible to do.
Indeed, I spent a lot of time trying to research the referenced template engine. I even recruited one of my most skillful colleagues to the challenge. Nonetheless, I just couldn’t make this happen. What I had here was a SSTI with no real harm.
I’ve reported my failure back to Google, which replied with similar conclusions:
Inevitably, my ‘bug’ was no more:
Final thoughts
While I was for sure disappointed with the end result, that is the lifecycle of bug bounty - not all paths end in bounties. Nonetheless I enjoyed this research a lot, and was on the edge of my seat throughout - which at the end is why I do security research to begin with. Hope you enjoyed this as I did :)