Skip to content

critfinds/Subdomain-Takeover-Base

Repository files navigation

Subdomain Takeover on brand.base.org

Vulnerability: Subdomain Takeover Target: brand.base.org

Description

This document outlines a potential subdomain takeover vulnerability on brand.base.org. A subdomain takeover occurs when a subdomain (in this case, brand.base.org) points to a third-party service (e.g., a cloud provider, a SaaS platform) that is no longer in use or has been de-provisioned. An attacker can then claim the abandoned service and gain control over the subdomain.

Impact

A successful subdomain takeover can have a severe impact, including but not limited to:

  • Reputation Damage: The attacker can host malicious or inappropriate content on the subdomain, damaging the brand's reputation.
  • Phishing Attacks: The attacker can create a convincing phishing page on the legitimate subdomain to steal user credentials or other sensitive information.
  • Session Hijacking: If the subdomain is within the same cookie scope as the main application, the attacker can potentially steal session cookies.
  • Cross-Site Scripting (XSS): The attacker can execute malicious scripts in the context of the user's browser, potentially leading to session hijacking or other attacks.
  • Remote Code Execution (RCE): In some cases, a subdomain takeover can lead to RCE.

Can a Subdomain Takeover Lead to RCE?

Yes, a subdomain takeover can lead to Remote Code Execution (RCE) under certain circumstances. Here are a few scenarios:

  • Code Execution as a Service: If the subdomain was used for a service that involves code execution (e.g., a CI/CD service, a serverless function endpoint), an attacker could take over the service and execute arbitrary code.
  • Script Injection: If the main application includes and executes scripts from the vulnerable subdomain, an attacker can host malicious scripts on the subdomain. When the main application fetches and executes the script, the attacker's code runs in the context of the main application, which could potentially lead to RCE if the application has vulnerabilities that can be exploited by the injected script.
  • API Exploitation: If the subdomain hosts an API that is consumed by the main application, an attacker could take over the API and exploit vulnerabilities in the main application's handling of the API responses to achieve RCE.

Proof of Concept (PoC)

This section should be filled in with the specific steps to demonstrate the subdomain takeover.

  1. Identify the dangling DNS record: The CNAME or A record for brand.base.org points to a service that can be claimed by an attacker.
  2. Claim the resource: Create an account on the third-party service and claim the resource associated with the subdomain.
  3. Demonstrate control: Host a file on the subdomain to prove control (e.g., a simple HTML file with a message).

Remediation

To remediate this vulnerability, the DNS record for brand.base.org should be removed or updated to point to a valid, in-use resource.

  1. Identify the DNS record: Locate the CNAME or A record for brand.base.org in your DNS management console.
  2. Remove or update the record:
    • If the subdomain is no longer in use, remove the DNS record.
    • If the subdomain should point to a different resource, update the DNS record accordingly.
  3. Implement a process for off-boarding subdomains: Create a process to ensure that DNS records are removed when the underlying services are de-provisioned.

About

Subdomain takeover PoC for Base on Coinbase

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published