Heyyy Everyoneeee,

I know it’s been a quite long time since I shared any of my findings sorry about that, I am back now don’t worry :)

In this writeup I will be talking about some of my valid bugs which I submitted to Google VRP , as they are fixed now I can share the details.

One bug was a simple reflected xss in withgoogle.com subdomain which I was able to find using simple automation and the other two were IDORs which I found in appsheet.com , it’s an Acquisition of Google.

Without wasting anytime , let’s get started!

XSS in artsexperiments.withgoogle.com

I have been using this simple script to find some easy xss in the past, I am using two tools here one is Paramspider and the other one kxss.

As input I provide the script with a filename which contains a list of subdomains, then using for loop it iterates over the subdomain list one by one and finds any urls with parameters in them. Then it just pipe the output to the kxss tool which looks for reflection of certain characters like “,>,<,’ which can let you know whether the endpoint is vulnerable to xss or not.

I just collected the list of subdomains of withgoogle.com and then passed it to this script and found that “,>,<,’ these characters are getting reflected as it is.

Here is the url: https://artsexperiments.withgoogle.com/living-archive/?token=158753034

And you can use any common payload here such as :

“><img src=x onerror=alert(document.domain)>

Now moving on to the IDOR

IDOR in appsheet.com

Well I was reading this article: https://medium.com/bugbountywriteup/the-short-tale-of-two-bugs-on-google-cloud-product-google-vrp-resolved-47c913dca8fc (Sadly the author has deleted his writeup)

From this article I got to know about Appsheet which is in scope of the Google VRP, the author shared the details of the IDOR there.

So I decided to find the same ,as you might have heard Zseano saying : “If there’s one IDOR… there will be plentyyy more

I didn’t expected I will find a similar IDOR just same as the other hacker talked about in his writeup so easily, it didn’t took me more than a hour.

The endpoint was same , parameter too the only thing that was different was the Request method.

This was the endpoint https://www.appsheet.com/api/template/{appId}/ , I found that the IDOR is fixed in GET method but the same IDOR still exists in POST method there was some data also in the body of the request .

This is the full request where I found the IDOR:

In the response you will get all the details of the app including the owner’s email , firebase token,etc.

Truncated Response

I quickly submitted the report and I received response from the team that they can’t reproduce the IDOR for them it’s giving forbidden error when they are using other user’s appId in this request.

I then provided additional information and also to help them easily reproduce the bug I gave them a list of appId along with a curl request with my cookies in it.

Atlast my report was accepted and on the next day itself they paid out a $500 bounty which was really fast.

The story doesn’t ends here wait for the climax.

After 4 months , I got a reply from someone from the Google team stating that :

This might not be actually a bug , they told me to look at my app settings to verify few things like which users are allowed to view my app(whether it's set to public or not),etc

I replied stating that I used the default settings and didn’t made any changes .

They replied again:

It seems that what you reported might be working as intended and that there is no security vulnerability and we were just confused.

As I was also confused and had no idea where this is going, I replied to them:

Hey XXXX,
Can you provide me with an appId which I shouldn't have access to?
If I am able to get the information related to that appId than this is indeed a bug which should be fixed or else if that's not the case you can close this report as intended behaviour.
Regards
Sudhanshu

I took it as a challenge and was provided with an appId by Google team, fired up my burpsuite and I came to the conclusion that I am also getting the same error

Your account sudi***@gmail.com id 2342347 does not have access to XXXX-1422495.

I told them yeah they were right that this not a bug as I was not able to view any information related to their app. I wasn’t feeling good after knowing this wasn’t actually a bug and they still paid me bounty by mistake.

Next day, I decided to look again at appsheet.com to find a valid bug this time. I created a new app and after playing around the features , don’t know why I decided to check again for that IDOR .

I took the appId which the Google team member gave me and sent the request and this time it worked ! I was able to view details of their application.

Woot!! But I had no idea how it worked :(

I replied them again:

Kindly ignore the previous message where I told that I wasn't able to get the information for your app.
Today I tried again and I was able to get information for your app.
Well well I am pretty sure this is your email only lastName.firstName@gmail.com :)

After closely looking at the request body parameter values the only thing that was changed from earlier was the version.

When I was confirming this IDOR for the first time in the post body , the version parameter value was set to 1.00003

And on the next day when I tried with a new app , the version parameter value was 1.000010

{
"settings": null,
"getAllTables": true,
"syncsOnConsent": true,
"isPreview": true,
"apiLevel": 2,
"tzOffset": -330,
"locale": "en-US",
"tableTimestamps": {},
"lastSyncTime": "",
"appStartTime": "",
"dataStamp": "2021-01-17T11:32:42.705Z",
"clientId": "4d9ef5e1-5cb0-400f-b432-660adcd24739",
"build": "edf35e60c1c1fcaaa72a-1610841603810-bd06078",
"version": "1.000010"
}

After noticing this little difference , I came to the conclusion that in order to get this IDOR working we need to supply the specific version which is associated with the App.

i.e. for my application the version was 1.00003and for the application of the Google staff was 1.000010

Due to this difference in version , we were both not able to reproduce the bug properly, as now everything was clear I explained everything to them again.

This were the replies I received after giving them the explanation:

Hi Sudhanshu,

Nice, that's my testing application! Definitely a bug - thanks!

Regards,
XXXX, Google Security Team
-------------------------------------------------------------------

Hi Sudhanshu,

Thanks again for your report. I can confirm that this is indeed a valid bug. I've also sent this report again to the VRP panel so they can have a look again.

Regards,
XXXXX, Google Security Team

I was really happy after this as I proved that my bug was a valid one.

After a couple of weeks the bug was fixed and as a surprise they also awarded another $500 (which I didn’t expected at all).

The other IDOR which I talked about was in this endpoint: https://www.appsheet.com/api/loadApp/{appId}/?checkConsistency=true

The information disclosed in the response here didn’t have any sensitive info like owner’s email ,etc so although they fixed the issue , no bounty was awarded for the second IDOR.

That’s the end of the story.

Thankyou so much, if you have read it till the end really appreciate your time.

Syaa Everyonee


How I made it to Google HOF? was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.