Obsolete domain verification process

Domain ownership verification is one of the most commonly used process for companies like Google to verify user's ownership of domains. This is often used when companies provide services that allow to monitor domain's DNS, use features like G Suite or site monitoring services. There are multiple other companies that use the same type of feature.

Similar to other companies, G Suite, a Google service, also has the same feature when you are adding a domain there. To make sure you own the domain, G Suite forces you to verify the domain before you use the service.

In this blog, we will break down how HTML / meta-tag verification works and a small security flaw in these techniques.

TXT file upload verification

For this process, we will use G Suite as an example. In the initial process of signing up in G Suite, you go to gsuite.google.com and register your domain. Once the registration is done, G Suite will redirect you to its dashboard. In the dashboard, you have multiple functionalities. However, before you can use the functionality that G Suite has, you will need to verify your domain. G Suite gives three option for that process:
  1. DNS verification through TXT records
  2. Meta-tag html code verification (will be discussed in this blog)
  3. HTML file upload

After user selects HTML file upload, G Suite will allow you to download a .html file that you are asked to upload in the root directory of the website. Once user uploads the file, G Suite will send a request at https://youregesitered.com/google[randomnumbers].html. User cannot modify the file either because G Suite looks for that specific file that is downloaded from their server.

Once it verifies that the file is uploaded, you get full access to the G Suite account to use its service.

Meta-tag verification

This is a more simpler way to verify the domain. Once you request to do a meta-tag verification, G Suite provides a <meta> html code that you put between <head></head> .

If the meta-tag is anywhere else it will not work.

Once G  Suite verifies that the tag is present in the main page of the website, it considers the domain verified.

What is the risk?

During the analysis of how G Suite works, it was found that once the domain is verified, G Suite never re-checks the domain. If the re-check is not done, user can still use the G Suite service despite them not having control of the domain (for example if the domain expired). This is a pretty serious issue because G suite and other domains that allow such verification are blindly trusting users to let them know (or cancel the service) when they do not have access to the domain.

During the research, the issue was found to be not just blind trust these companies have on customers but also there was a major issue of  how attackers could exploit this.

Live exploitation through Subdomain Takeover

Subdomain takeover is a pretty common vulnerability found in websites that use third party services frequently. When a company uses a third party service to host something through their domain and then later cancels the plan but forgets to remove the domain, they make it open for an external user to claim this domain and display their content. A pretty detailed blog on how this works can be found
here: https://labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more/

As seen through the linked blog, attacker usually has a full control of what content they want to display on the vulnerable domain. In some cases they have the ability to upload files and in some cases they have access to modify the HTML code of the page. This both comes handy when exploiting subdomain takeover and chaining that with G Suite. To show a live risk of this, we will discuss some scenarios in this blog.

When a domain is vulnerable to subdomain takeover, attacker can claim that domain in both the third party service and then in G Suite. G Suite will want to verify the domain to make sure attacker owns the domain. Attacker in this case already controls the content of the website so they can exploit this in two different ways:

  1. By uploading the HTML file that G Suite gives (if they have ability to upload files in the root directory).
  2. Change the HTML code of the website to add G Suite's <meta> tag in between <head></head>. 
 In either case, G Suite will verify this and will allow attacker to have a verified access to G Suite. Having access to verified G Suite of a corp domain can be extremely beneficial in conducting multiple phishing attack to both users and employees. User can send emails as the corp person and easily use that to phish employees working on the same domain.

Misconfigured AWS

Amazon web service (AWS) is quite frequently used by companies to host either statics codes like javascript files or private user information. In either case, a mis-configured AWS buckets always lead to high severity risks to domain. In some cases, s3 buckets are used to supply static code to the main page and in rare but not impossible case, the whole static version of a website (whole HTML code) is saved in the bucket. The domain then points to the s3 bucket and loads it content.

If the ACL is not properly set, attacker can upload and modify content of the page. While they might not have a takeover of the domain they still have ability to upload and change the code of the site. Besides defacing it, they can also now use G Suite to claim and verify the domain.

Research result

Once this research was concluded, we reported this issue to Google and discussed with them the potential fix. Google decided that it will be left as is due to engineering design. They have decided to not fix this right now.

Other services

There are still other services out there that support domain verification with TXT upload. This should never be trusted. It is better to trust verification through DNS rather than verification through TXT upload or editing of HTML page in the website.

Companies potentially vulnerable to this

After researching this on depth thanks to help of @edoverflow, we were able to identify other companies that allow this behavior which adds some risk:


  1. GoDaddy - SSL creation 
  2. Comodo - SSL Creation
  3. Facebook Workspace 
  4. G Suite
plus 50 other companies. 

RFC

During the research, it was also found that there is already a RFC open for this: https://tools.ietf.org/html/draft-bsag-domain-ownership-00 but it seems like it was abandoned. In the RFC, write clearly points the risk I am explaining in this blog:
"Domain names expire or change ownership. Therefore, these methods of verification must be permanently maintained by the website administrator and regularly checked by the service provider."
 - Ben Golightly

One thing that I do not agree in the RFC is that the creator is giving advice to use verify.txt. That will not prevent the case of the providers not periodically checking if the domain is still on control of proper owner.


Comments

Popular Posts