What Is Sub-Domain Takeover?

What Is Sub-Domain Takeover?

What Is Sub-Domain Takeover? – A sub domain takeover is really what it sounds like, a situation where a malicious person is able to claim a sub domain on behalf of a legitimate site. In a nutshell, this type of vulnerability involves a site creating a DNS entry for a sub domain, for example, ExploitByte (the hosting company) and never claiming that sub domain.

1. example.com registers on ExploitByte
2. example.com creates a DNS entry pointing sub domain.example.com to unicorn457.ExploitByte.com
3. example.com never claims unicorn457.ExploitByte.com
4. A malicious person claims unicorn457.ExploitByte.com and replicates example.com
5. All traffic for sub domain.example.com is directed to a malicious website which
looks like example.com

So, in order for this to happen, there needs to be unclaimed DNS entries for an external service like ExploitByte, Github, Amazon S3, Shopify, etc. A great way to find these is using KnockPy, which is discussed in the Tools section and iterates over a common list of sub domains to verify their existence.

What Is Sub-Domain Takeover?

Subdomain Takeover Bug Bounty Example Report:-

Swiping Facebook Official Access Tokens

I don’t know whether this meets the technical definition of a sub domain takeover (if one even exists) but I think this is an awesome find which allowed Philippe to hijack any Facebook account with minimal interaction.

In order to understand this vulnerability, we need to take a quick look at OAuth, which according to their site, is an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications. In other words, OAuth allows users to approve an application to act on their behalf without having to share a password with the application. If you’ve ever visited a site which permits you to log in with your Google, Facebook, Twitter, etc. account, you’ve used OAuth.

Now, that said, hopefully you’ve noticed the potential for exploitation here. If OAuth allows for user authorization, the impact of an incorrect implementation could be huge. With regards to process, Philippe provides a nice image explaining how the protocol is implemented:

What Is Sub-Domain Takeover?

In a nutshell, what we are seeing here is:

  1. A user requests to use the Facebook API for some purpose via some app
  2. That app redirects the user to the Facebook API to grant permission
  3. Facebook API provides the user with a code and redirects them to the app
  4. The app takes the code and calls the Facebook API for a token
  5. Facebook returns a token to the app which authorizes calls on the user’s behalf

In this process, you’ll notice that no where did a user have to provide their Facebook username and password to the app in order to authorize the app to access their account. This is also a high level overview, there are a number of other things that can occur here, including additional information which can be exchanged in the process.

A significant vulnerability here lies in Facebook providing the access token back to the application in #5.

Taking this back to Philippe’s find, he details on his blog how he wanted to try and capture those token, to trick Facebook into sending them to him instead of the appropriate application. However, instead, he decided to look for a vulnerable Facebook  application which he could take over.

Here’s the similarity to the broader concept of a sub domain takeover.

Turns out, that every Facebook user has applications authorized by their account but that they may not explicitly use. According to his write up, an example would be “Content Tab of a Page on www” which loads some API calls on Facebook Fan Pages. The list of apps is available by visiting https://www.facebook.com/search/me/apps-used.

Looking through that list, Philippe managed to find an app which was misconfigured and could be abused to capture tokens with a request that looked like:

https://facebook.com/v2.5/dialog/oauth?response_type=token&display=popup&client_\ id=APP_ID redirect_uri=REDIRECT_URI

Here, the application that he would use for the APP_ID was one that had full permissions already authorized and misconfigured – meaning step #1 and #2 were already done, the user wouldn’t get a pop up to grant permission to the app because they had actually already done so! Additionally, since the REDIRECT_URI wasn’t owned by Facebook, Philippe could actually own it – exactly like a sub domain. As a result, when a user clicks on his link, they’ll be redirected to:

http://REDIRECT_URI/access_token_appended_here

which Philippe could use to log all access tokens and take over Facebook accounts! What’s even more awesome, according to his post, once you have an official Facebook access token, you have access to tokens from other Facebook owned properties, like Instagram! All he had to do was make a call to Facebook GraphQL (an API for querying data from Facebook) and the response would include an access_token for the app in question.

What Is Sub-Domain Takeover?

Conclusion

Sub Domain Takeovers really aren’t that difficult to accomplish when a site has already created an unused DNS entry pointing to a third party service provider. There are a variety of ways to discover them, including using KnockPy, Google Dorks (site:*.hackerone.com), Recon-ng, etc. The use of all of these are included in the Tools chapter of this book.

What Is Sub-Domain Takeover?

Additionally, as was the case in the Facebook Access Token example, when you’re considering this type of vulnerability, broaden your scope and think about what stale configurations exist on a target which may be out of date. For example, the  redirect_uri to a pre-approved Facebook app.

If You Like This Blog Please Comment Down And For More Bug Bounty Content Click Here

Related posts

Leave a Comment