Subdomain Takeover via A Record: A Practical Guide to Organisers
What is Subdomain Takeover?
Subdomain takeover is a type of vulnerability that occurs when a subdomain of a domain points to an external service or IP that has been deleted, misconfigured, or left unclaimed. In this attack, an attacker exploits mismanaged DNS records to gain unauthorized control over the subdomain, often leading to severe security consequences.
Impact of Subdomain Takeover
- Phishing Attacks: Attackers can use the hijacked subdomain to host phishing pages and trick users into revealing sensitive information.
- Malware Distribution: Host malicious payloads and spread malware through trusted domain subdomains.
- Data Exfiltration: The compromised subdomain can be used to siphon off data from unsuspecting visitors.
- Reputation Damage: Hosting malicious or illegal content on a legitimate domain’s subdomain damages the parent organization’s reputation.
- Internal Reconnaissance: Attackers may pivot internally to exploit other vulnerabilities.
Capture the Flag Challenge: Subdomain Takeover
As organizers, we set up a CTF challenge to demonstrate subdomain takeover vulnerabilities by creating a realistic and exploitable environment. Here’s how we configured the setup for the challenge:
Challenge Context
The vulnerable subdomain in this challenge is flag.theuib.local. The goal for participants is to identify the misconfigured DNS A record, hijack the IP associated with the subdomain, and extract the flag by hosting a malicious server that intercepts the callback from the target system.
Challenge Setup Steps
1. Configure the DNS Server
We used a Bind9 DNS server running on a Kali Linux instance to simulate a misconfigured domain.
1. Setup the DNS Zone:
- A zone file was created for theuib.local, defining an A record for flag.theuib.local that points to the IP 192.168.212.68. The zone file configuration:
2. Deploy the DNS Server:
- The Bind9 service was configured to serve DNS queries for theuib.local.
3. Restart the DNS Service:
- After configuration, the DNS server was restarted to apply the changes:
2. Configuring the Flag Sending Machine
To simulate a system communicating with the subdomain, we set up a flag-sending machine with the following behavior:
Flag Sending Mechanism:
- A simple script was deployed to send the flag to flag.theuib.local via HTTP. The machine used the Kali Pi's IP as the DNS server for resolving the subdomain.
3. Participant Exploitation Path
Participants were required to:
- Enumerate the subdomain flag.theuib.local and identify its A record pointing to 192.168.212.68.
- Observe that 192.168.212.68 was unallocated on the network.
- Assign their machine the IP address 192.168.212.68.
- Host a Python HTTP server on port 80 to intercept the flag sent by the flag-sending machine.
Once the flag-sending machine resolved flag.theuib.local to 192.168.212.68, the participant's server intercepted the flag.
Challenge Outcome
The challenge was designed to highlight the risks of:
The participant who correctly hijacked the subdomain received the flag:
FLAG{<flag value in GET parameter of the ping>}
This scenario emphasizes the importance of proper DNS configuration and monitoring, ensuring that unused subdomains and IPs are appropriately managed.
- Misconfigured DNS records.
- Poor IP allocation and monitoring.
The participant who correctly hijacked the subdomain received the flag:
FLAG{<flag value in GET parameter of the ping>}
This scenario emphasizes the importance of proper DNS configuration and monitoring, ensuring that unused subdomains and IPs are appropriately managed.
Enhanced Capture the Flag Setup: Subdomain Takeover
In this advanced CTF setup, we introduced several mechanisms to ensure the challenge remains robust and fault-tolerant, even in the event of a DNS server compromise or downtime. Here's an overview of how these additional safeguards were implemented:
1. Robust Flag Sending Mechanism
The flag-sending machine was designed to dynamically adapt to changes in the environment, ensuring that the flag is only delivered to the correct subdomain while being resilient to potential tampering with the DNS server.
Dynamic IP Discovery and Delivery
1. Dynamic IP Resolution:
2. Flag Sending Script:
1. Dynamic IP Resolution:
- The flag-sending machine continuously queries the DNS server (flag.theuib.local) to resolve the current IP address.
If the DNS server changes the IP associated with the subdomain, the machine automatically adjusts to send the flag to the new IP
2. Flag Sending Script:
- The script intelligently determines the destination IP by querying the DNS server and sends the flag via HTTP. Here's the logic:
2. Monitoring and Automatic Recovery of the DNS Server
The flag-sending machine has an additional role in ensuring the availability of the DNS service by performing periodic health checks and recovery tasks.
Monitoring Bind9 Service
1. Health Check via SSH:
2. Restarting the Service:
Monitoring Bind9 Service
1. Health Check via SSH:
- The flag-sending machine uses SSH to connect to the Bind9 DNS server and check its status. If the service is down, it sends a notification.
2. Restarting the Service:
- To reduce downtime, the script attempts to restart the Bind9 service if it detects any issues.
3. Challenge Integrity
To prevent a compromised DNS server from leaking the flag:
- Dynamic Resolution: The flag-sending machine resolves the IP dynamically, ensuring only the correct subdomain receives the flag.
- Strict Domain Binding: The flag-sending machine strictly binds the destination to flag.theuib.local, even if DNS is tampered with.
- Automatic Recovery: The Bind9 service is monitored and automatically restarted in case of downtime, reducing the impact of service failures.
4. Final Setup Workflow
- DNS Server:
- Bind9 serves the subdomain flag.theuib.local with an A record pointing to 192.168.1.69.
- Monitored and managed by the flag-sending machine for high availability.
- Flag Sending Machine:
- Dynamically resolves the subdomain and sends the flag to the correct IP.
- Monitors and recovers the DNS service in case of downtime.
- Participant's Role:
- Enumerate the subdomain flag.theuib.local.
- Claim the unallocated IP 192.168.1.69.
- Host a Python HTTP server on port 80 to intercept the flag.
As organizers, we designed an enhanced Capture the Flag (CTF) challenge to showcase subdomain takeover vulnerabilities while incorporating a robust monitoring system to ensure a seamless experience for participants. The challenge revolves around hijacking the subdomain flag.theuib.local and dynamically receiving the flag. To ensure high availability and minimize downtime, we implemented automated DNS monitoring and recovery mechanisms, ensuring the challenge would remain unaffected even if the DNS service went down.
Additionally, we integrated a Flask-based monitoring application to track the status of the DNS server in real-time. This app logs each flag interaction, capturing details about who received the flag and when, providing both transparency and accountability.
By combining these elements, we created a challenge that not only teaches DNS exploitation techniques but also demonstrates the importance of resilient systems in real-world scenarios.
Additionally, we integrated a Flask-based monitoring application to track the status of the DNS server in real-time. This app logs each flag interaction, capturing details about who received the flag and when, providing both transparency and accountability.
By combining these elements, we created a challenge that not only teaches DNS exploitation techniques but also demonstrates the importance of resilient systems in real-world scenarios.
