This domain is my domain — G Suite A record vulnerability
In part two of G Suite vulnerability discussion, I am writing about a simple but quite serious vulnerability in yet another part of G Suite Application. In general, G Suite is a major application of Google with multiple features. Its primary security relies on the concept of Domain Ownership Verification.
This vulnerability was found when researching a possible weird takeover at ubereats.com. First, while testing some DNS details, about ubereats.com I found that it had its A record set to Google’s A record. This looked interesting to me so I decided to dig around and see what happens.
First, my initial thought was to give a shot at G Suite because that A record was a flashback to me. I had seen the same A record somewhere in G Suite but was not sure exactly which application of G Suite utilized it. When signing up in G Suite, it was interesting to see that despite having Google’s A record, ubereats.com was not yet claimed.
As previously mentioned on the G Suite Email vulnerability blog, they require specific records to be set for ownership verification. So my hands were tied on this case because I could not do much things to the domain. However when snooping around, I noticed that there was an option/facility called Add New Domain.
This was an interesting part of the research. This part of the application allows me to set a redirect for the domain I “own”. So I decided to see if it actually worked. I clicked the “Redirect your naked domain” function and was greeted by this page.
Interesting! However as usual my belief was that Google will force me to verify domain ownership before I could set anything up. I still decided to gave it a chance and replaced “www” with “hacked”. (Fair warning here: never put hacked when you are testing a domain takeover!) I went with “hacked” because my experience said it should not work but my gut said it will.
Next, right after I pressed continue, it showed me the page where it listed the A records which had to be setup in order for the redirect to work.
And my reaction to this was:
One of the A record matched exactly to the one that Uber had on ubereats.com domain. Fingers crossed, I pressed “I’ve completed these steps” hoping that Google will not stop me from taking that action.
Next thing I know is that the domain redirect was going through it. Once I visited ubereats.com it will take me to hacked.ubereats.com.
Bummer about this bug was that, I could not take the domain to other personal sites that I owned. So only risk was potential chances to scare the customers of the company and make them loose revenues. Specially in case of Uber, ubereats.com is an actively used site. So after it started to redirect, some complaints were made to Uber by their customers who were freaked out to see it.
After about 5 mins I reached out to a personal connection at Uber to make sure the issue was resolved quickly with minimal impact to customers. This was because, I took over the domain after 5 PM which could mean that they will (probably) not take a look at the report till the next business day. (This probably would not have happened after customers’ complains). Soon after that, Uber’s Security team released a quick fix (around 15 mins since exploitation).Uber then ran an investigation to make sure other domains did not suffer the same risk. They also encouraged me to reach out to Google and inform them about this. Google validated that this was a vulnerability from their side and fixed it rather quick.
Originally published at blog.pentestnepal.tech.