White Hats - Nepal

Securing the WWW

[whitehatnepal-blog]

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. 

[whitehatnepal-blog]

I got emails - G Suite Vulnerability

After recent finding about Uber and SendGrid bug, I decided to check other third party applications that were also used for similar cases. During the investigation, some third party applications were found to be vulnerable including G Suite.

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 specifically through G Suite.

Next, I 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 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)” 

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

Thanks to Google, Facebook and Yelp for the generous bounty amount.

Blog post by: uranium238

[whitehatnepal-blog]

Bypassing Ebay XSS Protection to launch XSS by Nirmal Dahal

This is a small proof of concept regarding “Reflective Cross-Site Scripting [ R-XSS ]” which I had found on Ebay. I am not an active participant in bug bounty programs, but one day I had finished all my office works so I was surfing on Facebook and received a  message from my brother, Samir, asking for advice regarding some musical instruments. The message contained a eBay link. Once on eBay, I logged into the site to view details, and suddenly noticed “Help & Contact” menu, I followed that menu and went to “Customer Service” page where I saw a search field, I decided to check for “Cross-Site Scripting [ XSS ]” vulnerability and unexpectedly found POST type R-XSS.

Testing For XSS

As all security researchers do, I also have certain pathways to find vulnerabilities. I always use ’>Test12345<“  as it contains number, letter and syntax. This allows me to see how a website handles user inputs. Some questions like “is the user input sanitized? how sensitive is user input?” can be answered from this idea.

Finding XSS

Once I noticed the “Customer server” page with a search field, I used that specific text in the field. I noticed that the value was being reflected without [ >< “ ]. I immediate figured out that eBay must have been replacing those syntax in White Space. The output in View-Source was like below:

OUTPUT:

<input type=“text” id=“query” role=“combobox” name=“query” value=“’ Test12345 ” title=“Search by help topic, keywords, or phrases” aria-expanded=“false” aria-autocomplete=“list” aria-activedescendant=“” aria-value=“’ Test12345 ” autocomplete=“off” aria-owns=“popup” class=“dText3”></input>

To test and understand the application further, I used this payload “/><script>alert(1);</script><input type=”

however the syntax was still filtered by eBay. So I encoded it in URL ENCODE format:

%22%2f%3E%3Cscript%3Ealert%281%29%3B%3C%2fscript%3E%3Cinput%20type%3D%22

After that the page source for that specific part was as follow:

OUTPUT:

<input type=“text” id=“query” role=“combobox” name=“query” value=“” script alert 1 script input type=“” title=“Search by help topic, keywords, or phrases” aria-expanded=“false” aria-autocomplete=“list” aria-activedescendant=“” aria-value=“” script alert 1 script input type=“” autocomplete=“off” aria-owns=“popup” class=“dText3”></input>

By seeing this, I realized that eBay was also filtering URL encoded syntax except %22 & %3D which decoded value are “ and =

After these research were made, I tweaked my payload a little to: %22 onMouseOver=%22prompt(document.cookie) which decodes to  “onMouseOver=“prompt(document.cookie)”.

Finally after this the XSS attack was successful and all was good to go. 

OUTPUT:

<input type=“text” id=“query” role=“combobox” name=“query” value=“ ” onMouseOver=“prompt(document.cookie)” title=“Search by help topic, keywords, or phrases” aria-expanded=“false” aria-autocomplete=“list” aria-activedescendant=“” aria-value=“ ” onMouseOver=“prompt(document.cookie)” autocomplete=“off” aria-owns=“popup” class=“dText3”></input>

Reply From Ebay

Acknowledgment By Ebay

Video POC: https://www.youtube.com/embed/s0Abd7h6vpg

[whitehatnepal-blog]

How I snooped into your private Slack messages [Slack Bug bounty worth $2,500]

When researching about MX records of slack.com, I noticed that they used a 3rd party email service. In that service, however slack.com was already claimed. After a little more research, I found that all the sub-domains of slack.com like teamname.slack.com also had MX set to the same service. These team domains were not claimed, so the emails for these domains could also be intercepted. What is the major issue with this? Could you send a message to your team from an email? These initial questions lead to a deeper research which discovered a critical vulnerability on Slack that would let me snoop into private slack messages. 

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. 

Written by uranium238. Thanks to Slack Security team for prompt response to the issue and generous reward.

[whitehatnepal-blog]

Reading Uber’s Internal Emails [Uber Bug Bounty report worth $10,000]

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.

[whitehatnepal-blog]

PornHub: Email Confirmation Bypass

Reporter : Vaxo Dai (@___0x00)

After signing up client needs to verify his email address to further use but the confirmation can be bypassed and can put any email address to confirm the user account

http://www.pornhub.com//user/confirm?id=[idname]&code=[code]

Here, user can get this id name using pornhub.com/users/[username] and viewing the source.

For longer description and POC : https://youtu.be/XFGjcfwXoqM (Beware, you might get boner xD )

Thanks,

This is the case of brute forcing, there is no such limit attempts, unlimited attempts can be done, to get correct confirmation code

PornHub Reply To Report :

So from what you describe, it’s possible to retrieve the ID from the page source and the confirmation code would be brute forced. This is possible but unlikely given that an attacker doesn’t gain much from going through the effort. I’m having trouble seeing the security implications. Closing as informative.

[whitehatnepal-blog]

RCE In AddThis

This vulnerability has been fixed as of July 20, 2016 and is shared with consent from the vendor. If you wish to share the information provided in the write up, provide credit for the original author or contact [email protected] for more info.  Timeline of the report

July 20,  2016 8:59 AM: Vulnerability is reported to the vendor through [email protected]

July 20, 2016 11:56 AM: Initial reply from the vendor regarding confirmation and process

July 20, 2016 12:00 AM: Vendor patches the vulnerability.

AddThis launched a responsible disclosure program quite a while ago. I had never paid attention to it until yesterday when I was browsing some articles regarding public exploits and vulnerabilities. One of the article was written by the team at Detectify. This article dealt with possibility of having a remote code execution if a Werkzeug debugger was publicly available.

I started to look into what is known as the Hackers Google, Shodan. During the research of this exploit I noticed that AddThis also had this installed.

During the inital research, Shodan showed that AddThis might be suspectible to this vulnerability. However there was IP address with the port provided. I started to look more into this and was soon able to confirm that this IP blcock was assigned to AddThis server. Now I wanted to find the domain associated as well. This was not a hard one to find. 

The domain and port associated was addth.is:5000. addth.is was a domain used by AddThis to redirect its user to addthis.com if they had clicked any link from sites like Twitter.

This vulnerability was previously reported through the contact page from AddThis however I soon found that the contact page was not working correctly. So I decided to email from [email protected] which worked. Within 2 hours of the initial report, the vulnerability was patched and currently the page shows 503 service unavailable.      

[whitehatnepal-blog]

Title: Multiple Stored XSS and HTML Injection in Edueto. 

Found by: Skelor

[whitehatnepal-blog]

Welcome to our blog.