DNS Security, Maybe?

17-01-2025

As we know, DNS is a service responsible for converting hostnames into IP addresses. It sounds simple, but some people do not realize that this DNS service can also cause security vulnerabilities. The following are several events I have experienced related to DNS and its security. Keep in mind this does not cover all vulnerabilities that exist in DNS, such as DNS Spoofing, DNS Amplification, DNS Hijacking, DNS Rebinding Attack, and other attacks, only several events that I have personally experienced.

Information Leakage

Sometimes the DNS records owned by a domain can provide information to a Threat Actor, such as TXT Records which are generally used to perform domain validation for a service, and MX records which are used to determine the email service/server being used.

The most common example is when there is an IP address information in MX records. When we perform scanning on that IP segment (/24), it turns out that neighboring IPs are used for other applications, while the DNS records used for the application point to Cloudflare or a Firewall server. As a result, a Threat Actor can unintentionally bypass Cloudflare/Firewall servers and access the application directly. Sometimes there are also other applications that are not listed in DNS records but can be accessed using neighboring IPs from the MX record by adding records to etc/hosts or by directly accessing the IP.

Subdomain Takeover

Subdomain Takeover or DNS Takeover is a technique where a Threat Actor can take control of a subdomain. With this technique, a Threat Actor can redirect traffic from that domain to a server owned by the Threat Actor. This generally occurs on cloud platforms such as AWS, Azure, Github, Heroku, and others.

This attack occurs due to a misconfiguration in the cloud platform configuration and DNS records that are not properly monitored by the domain owner. As a result, there are DNS records pointing to third-party servers (Cloud Platforms), but on the third-party platform the DNS records are not claimed by the domain owner. Therefore, a Threat Actor can claim the DNS and redirect the traffic to a Cloud Platform controlled by the Threat Actor. Of course, this can cause losses for the domain owner because data sent by users can be captured by the Threat Actor.

Generally, cloud platforms already have additional protection to prevent DNS Takeover from occurring, but not all cloud platforms have such protection. Therefore, domain owners must always monitor the DNS records they own. You can also see which services can be taken over via DNS in the following Github Repo

Old DNS Record

In this case, I once found a vulnerability in an application. After it was reported to the asset owner, they confirmed the vulnerability and performed mitigation using a web firewall. However, the application was not patched, so the vulnerability still existed. Then the PoC I created did not work because it was detected by the firewall. A few days later when I checked again, it turned out that only the DNS record had been changed to point to the firewall. When trying to access the domain using the old IP, the application and the vulnerability could still be exploited again.

Of course, the fix made by the asset owner was not effective because they only redirected traffic to the firewall server without patching the vulnerable application. Therefore, the asset owner must patch the application so that the vulnerability cannot be exploited by a Threat Actor, and also restrict access to the server so that not all IPs can access the server except those allowed by the asset owner and the firewall server IP.

AXFR Attack

An AXFR query is a query used to retrieve all DNS records from a domain. AXFR queries are usually used by a master DNS server to send all DNS records owned by the domain to a slave DNS server. However, AXFR queries can also be used by a Threat Actor to retrieve all DNS records from a domain if the DNS server is not configured properly. With this technique, a Threat Actor can find out all subdomains owned by a domain without having to brute force the subdomains. This vulnerability is commonly referred to as DNS Zone Transfer Vulnerability.

Interestingly, a few years ago the North Korean ccTLD .kp was vulnerable to an AXFR Attack, where a Threat Actor could perform an AXFR query on that domain and obtain the entire list of registered domains in North Korea.

In addition, there are also local hosting providers vulnerable to this AXFR Attack. I have reported it before, but it was considered an invalid finding, so until now domains using DNS Management from that hosting provider remain vulnerable to this attack.

DNS Zone Walking

DNS Zone Walking is a technique where a Threat Actor can discover all subdomains owned by a domain without brute forcing. This technique utilizes DNS Query NSEC which is used

Interestingly, the Indonesian ccTLD .id is vulnerable to DNS Zone Walking, where we can perform an NSEC query on the .id domain and obtain neighboring domains from that domain. Of course, this allows a Threat Actor to discover registered .id domains without brute forcing.

The following are Github repositories that collect registered .id domains caused by DNS Zone Walking and a combination of DNS Zone Transfer Vulnerability across all TLDs on the internet:

Lesson Learned

From several events I have experienced related to DNS, we can learn that DNS is a very important service and must be monitored properly, because DNS can cause security vulnerabilities that we may not realize and can certainly be exploited by Threat Actors. Therefore, as domain owners we must always monitor and manage the DNS records we own, ~~we can use services such as~~ ads should go here lol.