After recent finding about one of the Uber’s subdomain takeover was publicly disclosed, I looked into Uber to find similar bugs. One of my colleagues Abhibandu Kafle, pointed out that em.uber.com also had CNAME pointing to SendGrid and could be vulnerable to similar kind of issue.


I had limited experience using SendGrid, so I focussed on finding other issues instead. Sometimes later, I decided to give it a shot anyway because looking at it through different angles can sometimes open various doors and I was running out of endpoints to look into. So I signed up on SendGrid, a transactional and marketing email service used by uber, to see what was possible. 

Based on original hypothesis, I looked around to understand how to claim a domain through SendGrid. I could not edit contents of the domain, like you would normally do to demonstrate a subdomain hijacking, because it wasn’t possible through SendGrid. There was an option called “white-label”, which would allow emails to be sent through a verified domain and this caught my eye.

Meanwhile, fortunately, I forgot my Uber account’s password. So, I reset it and realized that the reset email Uber sent had reply email set to @em.uber.com. So, I knew that MX record for em.uber.com was being used somehow. A quick look into MX through dnsgoodies.com showed that MX was pointing to mx.sendgrid.net.

After I figured that I could play around with MX records for uber subdomains, I started to research more about SendGrid’s workflow. I realized that I could claim em.uber.com in the Inbound Parse Webhook, a medium for email interception, which wasn’t yet claimed by Uber. So, I thought this could be something I should focus on. 

I looked around for API and found a python program written by SendGrid which could be used in inbound parse webhook. I tweaked the program so that it would display the emails in my terminal. Then I ran the python web application,which would setup a local http server on port 5000. I used ngrok to tunnel that to a web address so that Inbound parse could get a receiver domain where it could send POST requests. 

Soon, I was able to receive emails in em.uber.com. This was also true with all of uber’s subdomain. One of them was www.uber.com, which was also used in their sentry(a crash reporter) plugin. This allowed me to receive sentry logs from www.uber.com because they were sent as email. This was a significant information disclosure for Uber.

Uber was able to quickly fix the vulnerability and told me that they also contacted SendGrid to see what they could do. SendGrid stated that the best option is for companies to claim the domain on their side. 

After about 10 days after the bug was resolved, Uber rewarded me with $10,000 for reporting this bug.

Also at the moment of writing this bug, it has come to my attention that SendGrid has added extra verification which forces you to have a verified domain before adding a inbound parse webhook.

The Proof-Of-Concept video that was submitted along with the bug report is as follows:

Attached image shows the list of domains I was able to add in the webhook. 

Thanks to detectify for bringing the issue of subdomain takeover into light, Uber Security Team for generous bounty amount (although there was very little they could do from their side.), and Abhibandu for helping me edit this article.