Rojan Rijal

First process was scanning social media sites for any old chatters on the hack. Some hackers like to boast about their hacks online in social media. I scanned twitter and facebook to see if there was any chatter. Unfortunately, this hacker knew how to cover his track. However some media sites were kind of blowing his cover. Seems like he had given some interview regarding the hack. After some check, I found that the data was being sold by the vendor nclay in a darknet website. I usually scan multiple .onion marketplace to see if there was any leaks after a website hack. After seeing the following picture, I immediately knew what site this was: 

Second process was now to go to the darknet. (Not so darknet because this site is known)

I had visited this same .onion site before when investigating about Credit Card leaks etc. It was none other than Hansa market. Reddit list on darknet is here: https://www.reddit.com/r/darknetmarkets/wiki/superlist#wiki_hansa_market

The onion site that works for this is: hansamkt3iph6sbb.onion

You can browse the site without TOR here: http://hansamkt3iph6sbb.onion.link/

So now we know his handle: nclay

the site he uses to sell the file: Hansamarket

When going to his store we find this: 

Now the deal is that, Edmodo recently emailed it user and informed them that they indeed a security breach. Users are requested to change their password immediately. He also provided some sample data which seems to have email address and bcrypt password of the accounts. Most accounts look to be of Edmodo employees because they contain the email address @edmodo.com. 

So far we have been able to link the same hacker for both leaks. I am not familiar with how that specific marketplace works but it seems that 1 order has been placed based on his vendor profile. 

So now lets break everything down: 

This handle joined the site on 2017-05-07 UTC time which is when we started to pick chatter about hackers complaining about Zomato’s unresponsive program. I can certainly bet that this hacker has reported bugs to Zomato through HackerOne platform. 

First, I was made aware of this link through a Slack group I am part of. I knew that the hackers were making this public but did not know when. At about 5:00 am on April 17, 2017 when I woke up, I saw that this link had got media’s attention and one of my colleague shared this on the slack channel I am in. Soon after that couple of the members of that Slack channel who I have decided to keep private, decided to validate this “hack”. Lets breakdown this hack: 

First, one of the slack member raised concern that this dump looked pretty similar to one posted on January 1, 2014. In January 1, 2014 snapchatdb.info site went live. This site included a dump of some 4.6 million users found through an address book api that was exploited through rate limiting. Owner of SnapchatDB, censored the last two digit of the number when it was made public. Unfortunately the site is now down (it was down within 24 hrs of being live in January 1, 2014). However, thanks to WayBack machine we can grab a screencap of the site. 

First analysis began on this image. When you check the banner image it has a supposed SQL query being done which then outputs some phone numbers and user account. The 1st phone number is 21232104XX. If we do the scan for this same number on the dump at https://ghostbin.com/paste/d7f4e, we can noticed that there is one user with that

So this already proves, that DB that was leaked on January 1, 2014 is the exact one that our alleged hackers posted today. Moving further, we found the SQL torrent of the previous leak. 

https://thepiratebay.org/torrent/9419945/Snapchat_Database_CSV__amp__SQL

After downloading the torrent, we got a .sql file which has the exact information when compared to what was found on the link our “hackers” provided. 

Which proves that Snapchat was not exactly hacked and the hackers just pasted an old data that was published online. 

Some hackers and hacking group claimed this hack which was found to be fake. 

Hacker known as Scientist Pandey posted on his Facebook that it was just a demo leak by the the Indian hackers and cyba_tiger. Unfortunately however, this was not a real hack. No data was stolen. “Hackers” here simply downloaded the file found online and shared it. 

If you do find a vulnerability in Snapchat, report it to them through their bug bounty page here.

“Fake it till you make it does not go with cybersecurity”

After I called them, their “officer” picked up the phone and asked for my name. Once I gave my name, he told me that I had done some shady stuff with my taxes. (Man this is fun). I acted as if I was scared and told me how I can fix this as I did not want my employer to know about this. (Man my employer will get PISSED if I did shady stuff in my tax). He told me that, I do not need to worry because he will help me fix this. According to him IRS does not give everyone a chance. (I must be special then). Well moving forward, he told me to go to the nearest Government verified stores like Walmart, Staples etc. 

Alright jokes aside, I was excited that I am going to Walmart yay! (But was I?). To make sure I could kind of raise his pressure, I told him Target was nearer so I wanted to go there. I kept repeating that, he got mad and said “Sir why you keep repeating the same thing. Do you not understand what I say?” After I said sorry and that I would go to the nearest Walmart, he asked me for my zip code which I happily “provided”. He was so kind, he even gave me the nearest Walmart based on the Zip code! I told him that I was in my car and was going to Walmart. (I don’t even have a license let alone drive a car!) Next, I made him wait for 15 mins as I did other stuff. (Lets waste his time but not mine hehe). 

Soon after that, I told him I “reached” Walmart. He told me to go to the Gift card section and read out the names. I gave him some names by looking them on Walmart’s website. He told me to grab the Walmart gift card and get three of them. (He actually knew all the rules & regulations about how much you can buy in the card). 

When I got that notification, it was pretty scary because I remember that secure2.donaldjtrump.com was used during the campaign for donation processing. This could lead to major breach if the server was hosting any confidential information. So I decided, to see who the hacker was. 

First, going to the website, I was greeted with the following screen, 

Seems like the hack is legit indeed and was not just a simple HTML injection. Now the work was to figure who hacked this. As seen the hacker did not give his real name on the screen (Who will actually give it right?)

Well, from my past research on blackhat hackers, specially the ones who hack web applications and deface them, I found that they are notorious for posting about their hacks in social media accounts. This is usually to gain praise or sometimes just to show off. 

So a small Twitter search on the domain was fruitful for the start. Out of all the tweets about people donating, one tweet stood out: 

Interesting... Seems like this twitter account had posted about the hack 2 hrs before. What was interesting was the smiley face. This raised some red flags and my gut claimed that this guy is behind but I had no evidence. Also who the hell tags Donald Trump to let him know his website is hacked? 

Next, the tweet itself did not say much about the person who tweeted about this. So, I decided to check Zone H to see if a hacker had shared about the hack there. Zone H is a mirror site for hackers, so that they can archive their hacks and showcase it. Unfortunately, nothing popped up in Zone H. This felt like a dead end, until one of my friend, shared me a PDF file of a resume of Hussain Adnan (person who had tweeted about the hack). 

The resume was a gold mine! Guess what it had?

So he just claimed on his own resume that he is Pro_Mast3r. Not only that, you could literally find this person’s digital footprint everywhere. Now, his FB post was more interesting than his tweet. 

At the end, it all came to a circle. Full evidence to back up the claim that he was the hacker behind this hack.  Just an alert to all hackers (white hat hackers), platforms like HackerOne and Bugcrowd give you opportunity to be ethical and help companies and government organizations to be more secure. Use your talent for greater use. If you do find vuln on websites like such, try to reach out to someone at these companies and see if they can help instead of hacking the website and trying to claim it on Zone H for showoff. 

How this hack actually went down?

This vulnerability was found when researching a possible weird takeover at ubereats.com. First, while testing some DNS details at 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. 

The initial research of this vulnerability started when investigating a vulnerability on whatsapp.net. It was interesting to see that whatsapp.net had its DNS in following manners (Image attached)

Based on this we can see that the MX setup is through Google. Further investigation showed it was through G Suite configuration which will require you to have such setup for the MX to work. 

Next, we went to G Suite signup page, and then signed up for the domain which created email id [email protected]. At first, this did not bring any security risk because for G Suite to properly work, a domain ownership verification is required so going to gmail.com would show the following screen.

This shows that without domain verification nothing could be done. However when looking up how forwarding and routing was done with G Suite I found this document by Google. https://support.google.com/a/answer/2368153?hl=en

This stated that one could set a routing by using the Default Routing tab in Gmail Advanced settings located at  G Suite. This should still require domain verification. However it did not. 

It did not take much work after that but to set the route in the following manners: 

Next, I decided to send a test email to [email protected] which then arrived to my private email. Once that was verified to work I submitted the report to Facebook Security team through https://facebook.com/whitehat. Facebook fixed it in about 4 days of the report being sent. 

Next, I found similar issue on Yelp through their yelp-support.com domain. Once I found the vulnerability on Yelp I realized this could be more wide spread than I had originally thought so I reached out to Google security team and reported it to their team as well. 

In about 1 day of my report, Google fixed the issue from their side so now when trying to use Gmail’s advanced settings without verification domains will give the following alert: 

“We are unable to process your request at this time. Please try again later. (Error #1310)” 

There are some ways, I tried to set routing after that and I was successful but the system was set in a way that it would detect it and change it immediately setting it back go Google Emails App. 

In the end, this vulnerability was fixed by Facebook, Yelp and Google as well  by January 31, 2017.

Following videos shows a PoC of how the exploit was done on Facebook:

To do further research on the question and gather relevant information, I looked for any way that these emails were being used by Slack. While browsing the HackerOne page for Slack, I noticed that they stated about the Email app that could be used as a way to send a message to a channel through the email. This service however was only applicable to member plans Standard and above. So I upgraded my plan to Standard and started to research on it. After I installed the Email app on my channel I was provided with an email in the form [hashedtext]@uraniumsecteam.slack.com. The hashedtext was randomly generated to make sure they cannot be enumerated because someone could use that to spam the channel. As I mentioned, the email had uraniumsecteam.slack.com as the email domain. I previously mentioned that it had MX, which could be claimed. I proceeded with the plan and set the route in a way that all emails coming to @uraniumsecteam.slack.com would arrive to my inbox. Let’s talk about the exploit scenario. Team X has a domain at x.slack.com. They use the default Email app which is widely used in Slack. Through the email app, they have provided a private email, as an example [email protected]. An intruder then claims x.slack.com through the email service they used and sets the route to their personal email like [email protected]. Once this is done, despite the team members sending a message to [email protected] they would not receive it because the hacker just intercepted it. He could then chose to forward the message to team, modify or edit it. As soon as the issue was reported, it was escalated to tier 0 (critical vulnerability) because it possessed a significant threat where I could read messages of any team. A quick fix was then added by Slack, so that even if I claimed the domain, it would still reject the incoming email.  A permanent fix was then deployed, which still lets claiming the domain but the email will now go through the app and reach the channel instead of reaching attacker’s channel.

Report link: 

Timeline: https://hackerone.com/reports/163938

August 27, 2016 - Report Submitted to Slack

August 29, 2016 - Initial reply by Slack Security and triaged

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: