How I was able to read Uber logs and internal emails.

After recent finding about Uber subdomain takeover was released, I looked into Uber to find similar bugs. One of my colleagues pointed out that em.uber.com had CNAME pointing to SendGrid and might be vulnerable to same kind of issue. I had limited experience with SendGrid so I decided to put it aside for a while thinking it might not be vulnerable. Then one day, I decided to give it a shot anyway because looking at a website through different angles can sometimes open various doors. So I signed up on SendGrid to start seeing what I could do. 

Based on original hypothesis, I researched regarding how to claim this domain through SendGrid. I could not edit contents of the domain because it was beyond what SendGrid did which was to manage emails of a domain. There was an option called white label which would allow emails to be sent through a verified domain. I attempted to claim the domain. At the same time, I had forgot my password for Uber so I reset it. I realized that the reset email Uber had sent contained a reply email as @em.uber.com so I knew that MX 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, I started to research more about SendGrid’s workflow. At the same time unknowingly, I claimed em.uber.com in the Inbound Parse Webhook. My research discovered that Inbound Parse Webhook was used as a medium of email interception. However Uber had not claimed it 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 edited the program to display the emails in my terminal. Then I ran the python web application. The application was running on localhost:5000. I used ngrok to tunnel that to a web address. This was because Inbound Parse required a receiver domain where it could send POST request. 

Soon I was able to receive emails in em.uber.com. This was also true with all of its subomain. One of them waswww.uber.com which was also used in their sentry plugin. This allowed me to receive sentry logs fromwww.uber.com because they were sent as email. 

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 of resolving the bug Uber rewarded me with $10,000 for reporting this bug.

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

Check the attached video on how this whole thing went:

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

image