Attacking DNS
The Domain Name System (DNS) translates domain names (e.g., hackthebox.com) to the numerical IP addresses (e.g., 104.17.42.72). DNS is mostly UDP/53, but DNS will rely on TCP/53 more heavily as time progresses. DNS has always been designed to use both UDP and TCP port 53 from the start, with UDP being the default, and falls back to using TCP when it cannot communicate on UDP, typically when the packet size is too large to push through in a single UDP packet. Since nearly all network applications use DNS, attacks against DNS servers represent one of the most prevalent and significant threats today.
Enumeration
DNS holds interesting information for an organization. As discussed in the Domain Information section in DNS we can understand how a company operates and the services they provide, as well as third-party service providers like emails.
The Nmap -sC (default scripts) and -sV (version scan) options can be used to perform initial enumeration against the target DNS servers:
$ nmap -p53 -Pn -sV -sC 10.10.110.213
Starting Nmap 7.80 ( https://nmap.org ) at 2020-10-29 03:47 EDT
Nmap scan report for 10.10.110.213
Host is up (0.017s latency).
PORT STATE SERVICE VERSION
53/tcp open domain ISC BIND 9.11.3-1ubuntu1.2 (Ubuntu Linux)DNS Zone Transfer
A DNS zone is a portion of the DNS namespace that a specific organization or administrator manages. Since DNS comprises multiple DNS zones, DNS servers utilize DNS zone transfers to copy a portion of their database to another DNS server. Unless a DNS server is configured correctly (limiting which IPs can perform a DNS zone transfer), anyone can ask a DNS server for a copy of its zone information since DNS zone transfers do not require any authentication. In addition, the DNS service usually runs on a UDP port; however, when performing DNS zone transfer, it uses a TCP port for reliable data transmission.
An attacker could leverage this DNS zone transfer vulnerability to learn more about the target organization's DNS namespace, increasing the attack surface. For exploitation, we can use the dig utility with DNS query type AXFR option to dump the entire DNS namespaces from a vulnerable DNS server:
DIG - AXFR Zone Transfer
$ dig AXFR @ns1.inlanefreight.htb inlanefreight.htb
; <<>> DiG 9.11.5-P1-1-Debian <<>> axfr inlanefrieght.htb @10.129.110.213
;; global options: +cmd
inlanefrieght.htb. 604800 IN SOA localhost. root.localhost. 2 604800 86400 2419200 604800
inlanefrieght.htb. 604800 IN AAAA ::1
inlanefrieght.htb. 604800 IN NS localhost.
inlanefrieght.htb. 604800 IN A 10.129.110.22
admin.inlanefrieght.htb. 604800 IN A 10.129.110.21
hr.inlanefrieght.htb. 604800 IN A 10.129.110.25
support.inlanefrieght.htb. 604800 IN A 10.129.110.28
inlanefrieght.htb. 604800 IN SOA localhost. root.localhost. 2 604800 86400 2419200 604800
;; Query time: 28 msec
;; SERVER: 10.129.110.213#53(10.129.110.213)
;; WHEN: Mon Oct 11 17:20:13 EDT 2020
;; XFR size: 8 records (messages 1, bytes 289)Tools like Fierce can also be used to enumerate all DNS servers of the root domain and scan for a DNS zone transfer:
$ fierce --domain zonetransfer.me
NS: nsztm2.digi.ninja. nsztm1.digi.ninja.
SOA: nsztm1.digi.ninja. (81.4.108.41)
Zone: success
{<DNS name @>: '@ 7200 IN SOA nsztm1.digi.ninja. robin.digi.ninja. 2019100801 '
'172800 900 1209600 3600\n'
'@ 300 IN HINFO "Casio fx-700G" "Windows XP"\n'
'@ 301 IN TXT '
'"google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"\n'
'@ 7200 IN MX 0 ASPMX.L.GOOGLE.COM.\n'
'@ 7200 IN MX 10 ALT1.ASPMX.L.GOOGLE.COM.\n'
'@ 7200 IN MX 10 ALT2.ASPMX.L.GOOGLE.COM.\n'
'@ 7200 IN MX 20 ASPMX2.GOOGLEMAIL.COM.\n'
'@ 7200 IN MX 20 ASPMX3.GOOGLEMAIL.COM.\n'
'@ 7200 IN MX 20 ASPMX4.GOOGLEMAIL.COM.\n'
'@ 7200 IN MX 20 ASPMX5.GOOGLEMAIL.COM.\n'
'@ 7200 IN A 5.196.105.14\n'
'@ 7200 IN NS nsztm1.digi.ninja.\n'
'@ 7200 IN NS nsztm2.digi.ninja.',
<DNS name _acme-challenge>: '_acme-challenge 301 IN TXT '
'"6Oa05hbUJ9xSsvYy7pApQvwCUSSGgxvrbdizjePEsZI"',
<DNS name _sip._tcp>: '_sip._tcp 14000 IN SRV 0 0 5060 www',
<DNS name 14.105.196.5.IN-ADDR.ARPA>: '14.105.196.5.IN-ADDR.ARPA 7200 IN PTR '
'www',
<DNS name asfdbauthdns>: 'asfdbauthdns 7900 IN AFSDB 1 asfdbbox',
<DNS name asfdbbox>: 'asfdbbox 7200 IN A 127.0.0.1',
<DNS name asfdbvolume>: 'asfdbvolume 7800 IN AFSDB 1 asfdbbox',
<DNS name canberra-office>: 'canberra-office 7200 IN A 202.14.81.230',
<DNS name cmdexec>: 'cmdexec 300 IN TXT "; ls"',
<DNS name contact>: 'contact 2592000 IN TXT "Remember to call or email Pippa '
'on +44 123 4567890 or pippa@zonetransfer.me when making '
'DNS changes"',
<DNS name dc-office>: 'dc-office 7200 IN A 143.228.181.132',
<DNS name deadbeef>: 'deadbeef 7201 IN AAAA dead:beaf::',
<DNS name dr>: 'dr 300 IN LOC 53 20 56.558 N 1 38 33.526 W 0.00m',
<DNS name DZC>: 'DZC 7200 IN TXT "AbCdEfG"',
<DNS name email>: 'email 2222 IN NAPTR 1 1 "P" "E2U+email" "" '
'email.zonetransfer.me\n'
'email 7200 IN A 74.125.206.26',
<DNS name Hello>: 'Hello 7200 IN TXT "Hi to Josh and all his class"',
<DNS name home>: 'home 7200 IN A 127.0.0.1',
<DNS name Info>: 'Info 7200 IN TXT "ZoneTransfer.me service provided by Robin '
'Wood - robin@digi.ninja. See '
'http://digi.ninja/projects/zonetransferme.php for more '
'information."',
<DNS name internal>: 'internal 300 IN NS intns1\ninternal 300 IN NS intns2',
<DNS name intns1>: 'intns1 300 IN A 81.4.108.41',
<DNS name intns2>: 'intns2 300 IN A 167.88.42.94',
<DNS name office>: 'office 7200 IN A 4.23.39.254',
<DNS name ipv6actnow.org>: 'ipv6actnow.org 7200 IN AAAA '
'2001:67c:2e8:11::c100:1332',
...SNIP...Domain Takeovers & Subdomain Enumeration
Domain takeover is registering a non-existent domain name to gain control over another domain. If attackers find an expired domain, they can claim that domain to perform further attacks such as hosting malicious content on a website or sending a phishing email leveraging the claimed domain.
Domain takeover is also possible with subdomains called subdomain takeover. A DNS's canonical name (CNAME) record is used to map different domains to a parent domain. Many organizations use third-party services like AWS, GitHub, Akamai, Fastly, and other content delivery networks (CDNs) to host their content. In this case, they usually create a subdomain and make it point to those services. For example,
sub.target.com. 60 IN CNAME anotherdomain.comThe domain name (e.g., sub.target.com) uses a CNAME record to another domain (e.g., anotherdomain.com). Suppose the anotherdomain.com expires and is available for anyone to claim the domain since the target.com's DNS server has the CNAME record. In that case, anyone who registers anotherdomain.com will have complete control over sub.target.com until the DNS record is updated.
Subdomain Enumeration
Before performing a subdomain takeover, we should enumerate subdomains for a target domain using tools like Subfinder. This tool can scrape subdomains from open sources like DNSdumpster. Other tools like Sublist3r can also be used to brute-force subdomains by supplying a pre-generated wordlist:
$ ./subfinder -d inlanefreight.com -v
_ __ _ _
____ _| |__ / _(_)_ _ __| |___ _ _
(_-< || | '_ \ _| | ' \/ _ / -_) '_|
/__/\_,_|_.__/_| |_|_||_\__,_\___|_| v2.4.5
projectdiscovery.io
[WRN] Use with caution. You are responsible for your actions
[WRN] Developers assume no liability and are not responsible for any misuse or damage.
[WRN] By using subfinder, you also agree to the terms of the APIs used.
[INF] Enumerating subdomains for inlanefreight.com
[alienvault] www.inlanefreight.com
[dnsdumpster] ns1.inlanefreight.com
[dnsdumpster] ns2.inlanefreight.com
...snip...
[bufferover] Source took 2.193235338s for enumeration
ns2.inlanefreight.com
www.inlanefreight.com
ns1.inlanefreight.com
support.inlanefreight.com
[INF] Found 4 subdomains for inlanefreight.com in 20 seconds 11 millisecondsAn excellent alternative is a tool called Subbrute. This tool allows us to use self-defined resolvers and perform pure DNS brute-forcing attacks during internal penetration tests on hosts that do not have Internet access.
Subbrute
$ git clone https://github.com/TheRook/subbrute.git >> /dev/null 2>&1
$ cd subbrute
$ echo "ns1.inlanefreight.com" > ./resolvers.txt
$ ./subbrute inlanefreight.com -s ./names.txt -r ./resolvers.txt
Warning: Fewer than 16 resolvers per process, consider adding more nameservers to resolvers.txt.
inlanefreight.com
ns2.inlanefreight.com
www.inlanefreight.com
ms1.inlanefreight.com
support.inlanefreight.com
<SNIP>Sometimes internal physical configurations are poorly secured, which we can exploit to upload our tools from a USB stick. Another scenario would be that we have reached an internal host through pivoting and want to work from there. Of course, there are other alternatives, but it does not hurt to know alternative ways and possibilities.
The tool has found four subdomains associated with inlanefreight.com. Using the nslookup or host command, we can enumerate the CNAME records for those subdomains.
$ host support.inlanefreight.com
support.inlanefreight.com is an alias for inlanefreight.s3.amazonaws.comThe support subdomain has an alias record pointing to an AWS S3 bucket. However, the URL https://support.inlanefreight.com shows a NoSuchBucket error indicating that the subdomain is potentially vulnerable to a subdomain takeover. Now, we can take over the subdomain by creating an AWS S3 bucket with the same subdomain name.
The can-i-take-over-xyz repository is also an excellent reference for a subdomain takeover vulnerability. It shows whether the target services are vulnerable to a subdomain takeover and provides guidelines on assessing the vulnerability.
DNS Spoofing
DNS spoofing is also referred to as DNS Cache Poisoning. This attack involves altering legitimate DNS records with false information so that they can be used to redirect online traffic to a fraudulent website. Example attack paths for the DNS Cache Poisoning are as follows:
An attacker could intercept the communication between a user and a DNS server to route the user to a fraudulent destination instead of a legitimate one by performing a Man-in-the-Middle (
MITM) attack.Exploiting a vulnerability found in a DNS server could yield control over the server by an attacker to modify the DNS records.
Local DNS Cache Poisoning
From a local network perspective, an attacker can also perform DNS Cache Poisoning using MITM tools like Ettercap or Bettercap.
To exploit the DNS cache poisoning via Ettercap, we should first edit the /etc/ettercap/etter.dns file to map the target domain name (e.g., inlanefreight.com) that they want to spoof and the attacker's IP address (e.g., 192.168.225.110) that they want to redirect a user to:
cat /etc/ettercap/etter.dns
inlanefreight.com A 192.168.225.110
*.inlanefreight.com A 192.168.225.110Next, start the Ettercap tool and scan for live hosts within the network by navigating to Hosts > Scan for Hosts. Once completed, add the target IP address (e.g., 192.168.152.129) to Target1 and add a default gateway IP (e.g., 192.168.152.2) to Target2.
Activate dns_spoof attack by navigating to Plugins > Manage Plugins. This sends the target machine with fake DNS responses that will resolve inlanefreight.com to IP address 192.168.225.110:
After a successful DNS spoof attack, if a victim user coming from the target machine 192.168.152.129 visits the inlanefreight.com domain on a web browser, they will be redirected to a Fake page that is hosted on IP address 192.168.225.110:
In addition, a ping coming from the target IP address 192.168.152.129 to inlanefreight.com should be resolved to 192.168.225.110 as well:
Example: Find all available DNS records
Question: Find all available DNS records for the "inlanefreight.htb" domain on the target name server and submit the flag found as a DNS record as the answer.
We have an IP 10.129.203.6
We need to find DNS records of available subdomains
Add the IP to /etc/hosts
Add the IP address to resolve to inlanefreight.htb in /etc/hosts:
Use SubBrute to brute Force Subdomains
Now we need to find subdomains that could be associated with inlanefreight.htb.:
We first add the IP address to resolvers file (because this is an exercise, otherwise we would use the given one for public IPs). Then we use the domain, and supply a wordlist of subdomains and specify the resolver.
python3 subbrute.py inlanefreight.htb -s names.txt -r tempResolve.txt We find that hr.inlanefreight.htb was found:
Using dig
Now that we have a subdomain, we can use dig to check the dns records:
$ dig axfr @10.129.203.6 hr.inlanefreight.htb
; <<>> DiG 9.20.0-Debian <<>> axfr @10.129.203.6 hr.inlanefreight.htb
; (1 server found)
;; global options: +cmd
hr.inlanefreight.htb. 604800 IN SOA inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
hr.inlanefreight.htb. 604800 IN TXT "HTB{LUIHNFAS2871SJK1259991}"
hr.inlanefreight.htb. 604800 IN NS ns.inlanefreight.htb.
ns.hr.inlanefreight.htb. 604800 IN A 127.0.0.1
hr.inlanefreight.htb. 604800 IN SOA inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
;; Query time: 47 msec
;; SERVER: 10.129.203.6#53(10.129.203.6) (TCP)
;; WHEN: Sat Aug 24 17:00:23 EDT 2024
;; XFR size: 5 records (messages 1, bytes 230)
We see the flag in the TXT record for hr.inlanefreight.htb
Latest DNS Vulnerabilities
We can find thousands of subdomains and domains on the web. Often they point to no longer active third-party service providers such as AWS, GitHub, and others and, at best, display an error message as confirmation of a deactivated third-party service. Large companies and corporations are also affected time and again. Companies often cancel services from third-party providers but forget to delete the associated DNS records. This is because no additional costs are incurred for a DNS entry. Many well-known bug bounty platforms, such as HackerOne, already explicitly list Subdomain Takeover as a bounty category. With a simple search, we can find several tools on GitHub, for example, that automate the discovery of vulnerable subdomains or help create Proof of Concepts (PoC) that can then be submitted to the bug bounty program of our choice or the affected company. RedHuntLabs did a study on this in 2020, and they found that over 400,000 subdomains out of 220 million were vulnerable to subdomain takeover. 62% of them belonged to the e-commerce sector.
RedHuntLabs Study
Source: https://redhuntlabs.com/blog/project-resonance-wave-1.html
The Concept of the Attack
One of the biggest dangers of a subdomain takeover is that a phishing campaign can be launched that is considered part of the official domain of the target company. For example, customers would look at the link and see that the domain customer-drive.inlanefreight.com (which points to a nonexisting S3 bucket from AWS) is behind the official domain inlanefreight.com and trust it as a customer. However, the customers do not know that this page has been mirrored or created by an attacker to provoke a login by the company's customers, for example.
Therefore, if an attacker finds a CNAME record in the company's DNS records that points to a subdomain that no longer exists and returns an HTTP 404 error, this subdomain can most likely be taken over by us through the use of the third-party provider. A subdomain takeover occurs when a subdomain points to another domain using the CNAME record that does not currently exist. When an attacker registers this nonexistent domain, the subdomain points to the domain registration by us. By making a single DNS change, we make ourselves the owner of that particular subdomain, and after that, we can manage the subdomain as we choose.
The Concept of Attacks
What happens here is that the existing subdomain no longer points to a third-party provider and is therefore no longer occupied by this provider. Pretty much anyone can register this subdomain as their own. Visiting this subdomain and the presence of the CNAME record in the company's DNS leads, in most cases, to things working as expected. However, the design and function of this subdomain are in the hands of the attacker.
Initiation of Subdomain Takeover
1.
The source, in this case, is the subdomain name that is no longer used by the company that we discovered.
Source
2.
The registration of this subdomain on the third-party provider's site is done by registering and linking to own sources.
Process
3.
Here, the privileges lie with the primary domain owner and its entries in its DNS servers. In most cases, the third-party provider is not responsible for whether this subdomain is accessible via others.
Privileges
4.
The successful registration and linking are done on our server, which is the destination in this case.
Destination
This is when the cycle starts all over again, but this time to trigger the forwarding to the server we control.
Trigger the Forwarding
5.
The visitor of the subdomain enters the URL in his browser, and the outdated DNS record (CNAME) that has not been removed is used as the source.
Source
6.
The DNS server looks in its list to see if it has knowledge about this subdomain and if so, the user is redirected to the corresponding subdomain (which is controlled by us).
Process
7.
The privileges for this already lie with the administrators who manage the domain, as only they are authorized to change the domain and its DNS servers. Since this subdomain is in the list, the DNS server considers the subdomain as trustworthy and forwards the visitor.
Privileges
8.
The destination here is the person who requests the IP address of the subdomain where they want to be forwarded via the network.
Destination
Subdomain takeover can be used not only for phishing but also for many other attacks. These include, for example, stealing cookies, cross-site request forgery (CSRF), abusing CORS, and defeating content security policy (CSP). We can see some examples of subdomain takeovers on the HackerOne website, which have earned the bug bounty hunters considerable payouts.
Last updated