The Most Frequent DNS Management Errors and How to Fix Them

As an integral part of our job, we have the opportunity to look into the network communication of many different types of companies. During audits, we have come across all sorts of different misconfigurations and malicious activities. Today, we will look at what to look out for in the area of DNS.

When you type www.greycortex.com into your web browser, you assume that you are accessing our GREYCORTEX website.

What you see depends, among other things, on the DNS translation, which translates the name www.greycortex.com into the numeric form of the IP address: 91.239.201.14.

The DNS server that controls this translation also controls the destination IP address and the server to which the user is redirected. Whoever sees the DNS queries for a particular device can see what servers the device connects to – what services it uses or what it does.

The following are the most common problems we see in DNS management:

• An open port 53 without any restrictions allows the transmission of any of your data. It can be misused not only by attackers but also by legitimate applications.
• You’re not the administrator of your own domain – your network can then become the target of a Man-in-the-Middle attack.
• Misspellings in DNS server IP addresses – devices that are manually configured are particularly vulnerable, for example, the prevention of security updates.

An Unlimited Open Port 53

In many networks, we see an open port 53 from the internal network to the Internet without any restrictions. This means that any device on the internal network can connect to any other device on the Internet. This is used by both attackers and legitimate applications, which can be a problem from a security perspective.

Attackers can use an open port 53 to the Internet to create a DNS tunnel. They can then send any data through it. For example, using Iodine software, they can create an IP layer on top of the application’s DNS protocol and then use port 53 to transmit arbitrary data or create a reverse SSH tunnel from the Internet to the internal network. This creates permanent access, which allows an attacker to return to the internal network at any time.

Specifically, in the case of Iodine software, the created IP layer is transmitted hidden in strings that represent a third-order domain. From the perspective of a network communications analyst, the client is communicating with a legitimate DNS server on the internal network, but a closer look at the transmitted data will show that this is not the case.

Let’s have a look at this data in GREYCORTEX Mendel. As an example, there’s a device with the IP address 10.0.2.30 that is sending DNS queries to an internal DNS server with the IP address 10.0.2.20. In the figure below, you can see an example of several queries in the application’s log data itself that query the domain name pirate.sea. The third-order domain name changes in each query and also looks very strange at first glance. Note also that the rrtype attribute contains an unusual NULL value.

When to Have an Open Port 53?

An example of a legitimate use of an open port 53 is some antivirus products. For example, one of Avast’s products has a DNS secure (now Real Site) feature. This is designed to prevent DNS hijacking attacks in which an attacker spoofs a DNS record of a user, which then leads the user to a malicious server. When the DNS secure feature is enabled, the antivirus sends DNS requests to its own DNS servers, thereby preventing DNS record spoofing.

Thus, the client device bypasses the internal DNS server and sends DNS queries to the server directly via the Internet. From a network traffic perspective, you then see outbound traffic to the external server on port 53. Since the communication is encrypted, you will not see the DNS name that the client requested resolving.

This functionality may be desirable when connecting devices to public wi-fi networks, but in a corporate environment, it can pose a problem when tracking and monitoring DNS traffic.

For auditing DNS communication and the long-term monitoring and data collection needed to address security events, we recommend you:

• Block all outbound traffic to the destination port 53 to the Internet from networks that contain critical information systems that need to be monitored. Only create exceptions for legitimate internal DNS servers.
• Audit devices that attempt to resolve DNS names directly against DNS servers on the Internet. The communication is either generated by specific applications or by malware trying to communicate directly to the Internet.

You Do Not Really Own Your Own Domain

During audits, we encountered a situation where two domains were being used on the internal network. This happened when it was not possible to migrate the old domain to the new systems. So, the administrators decided to create a new domain. The old domain was company.com, then the new version was created with a 2v extension: company2v.com.

At first glance, this may seem like a harmless change. However, the problem was that the administrators did not register the new domain with the domain administrator, then another entity registered it.

What implications might this case have?

One day, the administrator decides they want to see the web traffic going out to the Internet. They use a proxy server and set it up automatically using a Windows GPO (Group Policy Object). In this case, the stations start trying to connect to a server named wpad.company2v.com for their new domain. Devices with an external DNS server set up, which the firewall lets onto the Internet, redirect the device to a DNS server that is authorized for the company2v.com domain. These servers are on the Internet and are not owned by the customer.

The problem is that the actual owner of the company2v.com domain manages all DNS records for that domain. Therefore, they can ensure that devices from the internal network connect to a proxy server on the Internet when trying to obtain a proxy configuration. It is then possible to carry out, for example, a MITM attack. Now, the attacker is only one step away from delivering ransomware to this client. And the ransomware can look like an executable file that the user originally wanted to download, for example, firefox.exe.

During an audit, we recommend looking into:

• Which domains are present on the network.
• Whom these domains are registered to.
• How they are used on the network.

Misspellings in DNS Server IP Addresses

We frequently encounter typos in these DNS server IP addresses:

• Google’s publicly available servers with addresses 8.8.8.8 and 8.8.4.4 are often written as 4.4.4.4 or 8.8.6.6.
• Addresses like 192.168.X.X usually omit the number 1 at the beginning of the IP address.

If the DNS server is configured incorrectly, the device cannot perform a DNS translation. For devices that are used daily, the problem will be quickly detected. But the problem can occur with devices where the DNS is configured manually, like cameras or sensor systems. Such a configuration error can prevent security updates of the device.

In the figure below, you can see an example from the Mendel system where it detected thirteen devices trying to send DNS queries to the IP address 8.8.6.6. However, there is no DNS server at this IP address and, therefore, the translations are unsuccessful.

It could also happen that an administrator or user manages to hit an IP address that is used on the Internet and provides a DNS service. Then internal DNS names can also be sent to a public server on the Internet.

These misconfigurations can occur at random. Therefore, constantly monitor and record the DNS traffic going through your network.

Look For Any Anomalies in Your Traffic

A DNS system is one of the cornerstones of any computer network. Only a regular audit can ensure that the network is secure.

For auditing purposes,  communication needs to be recorded and stored for some period (Mendel stores data for up to several years). Since a DNS system is capable of generating a large amount of data in a single day, we recommend using a system that can look for deviations from normal traffic in this vast volume of data or is able to answer basic questions about the traffic in your infrastructure.