LinkedInExploit ADHackTheBox

DNS - 53

If we cannot axfr, we dnsenum.

You know what it is...

There are several types of DNS servers that are used worldwide:

DNS Root Server

The root servers of the DNS are responsible for the top-level domains (TLD). As the last instance, they are only requested if the name server does not respond. Thus, a root server is a central interface between users and content on the Internet, as it links domain and IP address. The Internet Corporation for Assigned Names and Numbers (ICANN) coordinates the work of the root name servers. There are 13 such root servers around the globe. ( I checked it out, basically they are root server A-M)

Authoritative Nameserver

Authoritative name servers hold authority for a particular zone. They only answer queries from their area of responsibility, and their information is binding. If an authoritative name server cannot answer a client's query, the root name server takes over at that point.

Non-authoritative Nameserver

Non-authoritative name servers are not responsible for a particular DNS zone. Instead, they collect information on specific DNS zones themselves, which is done using recursive or iterative DNS querying.

Caching DNS Server

Caching DNS servers cache information from other name servers for a specified period. The authoritative name server determines the duration of this storage.

Forwarding Server

Forwarding servers perform only one function: they forward DNS queries to another DNS server.

Resolver

Resolvers are not authoritative DNS servers but perform name resolution locally in the computer or router.

DNS is mainly unencrypted. Devices on the local WLAN and Internet providers can therefore hack in and spy on DNS queries. Since this poses a privacy risk, there are now some solutions for DNS encryption. By default, IT security professionals apply DNS over TLS (DoT) or DNS over HTTPS (DoH) here. In addition, the network protocol DNSCrypt also encrypts the traffic between the computer and the name server.

However, the DNS does not only link computer names and IP addresses. It also stores and outputs additional information about the services associated with a domain. A DNS query can therefore also be used, for example, to determine which computer serves as the e-mail server for the domain in question or what the domain's name servers are called.

Different DNS records are used for the DNS queries, which all have various tasks. Moreover, separate entries exist for different functions since we can set up mail servers and other servers for a domain.

A

Returns an IPv4 address of the requested domain as a result.

AAAA

Returns an IPv6 address of the requested domain.

MX

Returns the responsible mail servers as a result.

NS

Returns the DNS servers (nameservers) of the domain.

TXT

This record can contain various information. The all-rounder can be used, e.g., to validate the Google Search Console or validate SSL certificates. In addition, SPF and DMARC entries are set to validate mail traffic and protect it from spam.

CNAME

This record serves as an alias for another domain name. If you want the domain www.hackthebox.eu to point to the same IP as hackthebox.eu, you would create an A record for hackthebox.eu and a CNAME record for www.hackthebox.eu.

PTR

The PTR record works the other way around (reverse lookup). It converts IP addresses into valid domain names.

SOA

Provides information about the corresponding DNS zone and email address of the administrative contact.

The SOA (Start Of Authority) record is located in a domain's zone file and specifies who is responsible for the operation of the domain and how DNS information for the domain is managed.

In the Authority Section - The dot (.) is replaced by an at sign (@) in the email address. In this example, the email address of the administrator is [email protected].

Default Configuration

There are many different configuration types in DNS. Lets discuss about the three most important ones from the administrative point of view:

  1. local DNS configuration files

  2. zone files

  3. reverse name resolution files

Local Configuration File

The DNS server Bind9 is very often used on Linux-based distributions. Its local configuration file (named.conf) is roughly divided into two sections, firstly the options section for general settings and secondly the zone entries for the individual domains. The local configuration files are usually:

  • named.conf.local

  • named.conf.options

  • named.conf.log

It contains the associated RFC where we can customize the server to our needs and our domain structure with the individual zones for different domains. The configuration file named.conf is divided into several options that control the behavior of the name server. A distinction is made between global options and zone options.

Global options are general and affect all zones. A zone option only affects the zone to which it is assigned. Options not listed in named.conf have default values. If an option is both global and zone-specific, then the zone option takes precedence.

Lets look at named.conf.local

In this file, we can define the different zones. These zones are divided into individual files, which in most cases are mainly intended for one domain only. Exceptions are ISP and public DNS servers. In addition, many different options extend or reduce the functionality. We can look these up on the documentation of Bind9.

Zone files

A zone file is a text file that describes a DNS zone with the BIND file format. In other words it is a point of delegation in the DNS tree. The BIND (Berkeley Internet Name Domain) file format is the industry-preferred zone file format and is now well established in DNS server software. A zone file describes a zone completely.

Bind Format: <hostname> IN A <ip_addr>

There must be precisely one SOA record and at least one NS record. The SOA resource record is usually located at the beginning of a zone file. The main goal of these global rules is to improve the readability of zone files. A syntax error usually results in the entire zone file being considered unusable. The name server behaves similarly as if this zone did not exist. It responds to DNS queries with a SERVFAIL error message.

In short, here, all forward records are entered according to the BIND format. This allows the DNS server to identify which domain, hostname, and role the IP addresses belong to. In simple terms, this is the phone book where the DNS server looks up the addresses for the domains it is searching for.

Dangerous Conmfigurations

A list of vulnerabilities targeting the BIND9 server can be found at CVEdetails. In addition, SecurityTrails provides a short list of the most popular attacks on DNS servers.

Some of the settings we can see below lead to these vulnerabilities, among others. Because DNS can get very complicated and it is very easy for errors to creep into this service, forcing an administrator to work around the problem until they find an exact solution. This often leads to elements being released so that parts of the infrastructure function as planned and desired. In such cases, functionality has a higher priority than security, which leads to misconfigurations and vulnerabilities.

allow-query

Defines which hosts are allowed to send requests to the DNS server.

allow-recursion

Defines which hosts are allowed to send recursive requests to the DNS server.

allow-transfer

Defines which hosts are allowed to receive zone transfers from the DNS server.

zone-statistics

Collects statistical data of zones.

Footprinting DNS

The DNS server also holds records that if we query can tell us which other DNS servers are there. We do this using the NS record and the specification of the DNS server we want to query using the @ character.

Sometimes it is also possible to query a DNS server's version using a class CHAOS query and type TXT. However, this entry must exist on the DNS server. For this, we could use the following command:

Dig Version Query:

We can use the option ANY to view all available records. This will cause the server to show us all available entries that it is willing to disclose. It is important to note that not all entries from the zones will be shown.

DNS Zone Transfer

Zone transfer refers to the transfer of zones to another server in DNS, which generally happens over TCP port 53. This procedure is abbreviated Asynchronous Full Transfer Zone (AXFR). Since a DNS failure usually has severe consequences for a company, the zone file is almost invariably kept identical on several name servers. When changes are made, it must be ensured that all servers have the same data. Synchronization between the servers involved is realized by zone transfer. Using a secret key rndc-key, which we have seen initially in the default configuration, the servers make sure that they communicate with their own master or slave.

The slave fetches the SOA record of the relevant zone from the master at certain intervals, the so-called refresh time, usually one hour, and compares the serial numbers. If the serial number of the SOA record of the master is greater than that of the slave, the data sets no longer match.

If the administrator used a subnet for the allow-transfer option for testing purposes or as a workaround solution or set it to any, everyone would query the entire zone file at the DNS server. In addition, other zones can be queried, which may even show internal IP addresses and hostnames.

Many tools can be used to brute-force subdomains in DNS. One of these tools is, for example DNSenum.

More about SOA

The SOA (Start of Authority) record in DNS is a critical component that provides essential information about a DNS zone. It signifies the beginning of a zone and includes administrative details about the zone's configuration. Here's a breakdown of what the SOA record is and what information it contains:

Key Components of an SOA Record

  1. Primary Name Server:

    • This field specifies the primary DNS server for the zone. This server is authoritative for the zone and is where updates to the zone records are made.

  2. Hostmaster Email Address:

    • This field contains the email address of the person responsible for the zone. It is typically formatted with a . instead of the @ symbol. For example, hostmaster.example.com might represent [email protected].

  3. Serial Number:

    • The serial number is a crucial component that indicates the version of the zone file. When changes are made to the DNS records, this number should be incremented. Secondary DNS servers use this number to determine whether they need to update their copies of the zone file.

  4. Refresh Interval:

    • This value specifies how often secondary DNS servers (slaves) should check the primary server for updates to the zone. It is typically expressed in seconds.

  5. Retry Interval:

    • This field defines how long secondary servers should wait before retrying to contact the primary server if the last refresh attempt failed.

  6. Expire Time:

    • This value indicates how long secondary servers should consider their copy of the zone valid if they cannot contact the primary server. After this time, they should stop responding to queries for that zone.

  7. Minimum TTL (Time to Live):

    • This field specifies the default time that DNS records in the zone should be cached by resolvers and other DNS servers. It is expressed in seconds.

Example of an SOA Record

Here’s an example of what an SOA record might look like in a zone file:

Key Points

  • The SOA record is essential for the proper functioning of DNS because it contains critical information regarding the management of the DNS zone.

  • Proper configuration of the SOA record helps ensure that DNS updates propagate correctly and that resolvers have the right information for caching DNS records.

  • The serial number is particularly important for synchronization between primary and secondary DNS servers, as it dictates when changes have been made.

PreviousNFS - 111,2049NextSMTP - 25,465

Last updated