{"id":9449,"date":"2024-01-31T08:00:24","date_gmt":"2024-01-31T16:00:24","guid":{"rendered":"https:\/\/blogs.infoblox.com\/?p=9449"},"modified":"2024-03-19T22:09:01","modified_gmt":"2024-03-20T06:09:01","slug":"securing-dns-and-dhcp-best-practices-to-prevent-spoofing","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/security\/securing-dns-and-dhcp-best-practices-to-prevent-spoofing\/","title":{"rendered":"Securing DNS and DHCP: Best Practices to Prevent Spoofing"},"content":{"rendered":"

Introduction<\/h3>\n

How often do you think about the critical network services DNS, DHCP, and IPAM (DDI)? DDI is a collection of core network services that make the Internet work. From on-premises to hybrid cloud to remote users, DDI touches nearly every facet of\u00a0 network connectivity for a modern business. Without question, secure, reliable DDI is crucial to almost every function in today\u2019s modern world; some might consider it as important as water or electricity in their day-to-day lives. Due to how critical DDI is, a proper security-first DDI solution with proper configuration is key. A correctly configured DDI infrastructure can help avoid attacks, data breaches, and outages, all of which mean lost money and reputation for a business.\u00a0<\/p>\n

DDI is often forgotten about, despite its criticality to business functions. DDI may only be considered when IT professionals update the occasional DHCP range or perhaps create a DNS record for a newly provisioned device. When something goes wrong, that\u2019s when everyone thinks about DDI; not only is it a massive inconvenience, the business is likely losing money.<\/p>\n

Akamai recently put a spotlight on a long-known issue among DDI professionals that can arise when using Microsoft Windows Server as both your Domain Controller and DDI provider. The blog series can be found here<\/a>. Out of curiosity, I wanted to see how easy it was to reproduce their findings, and it was shockingly easy.<\/p>\n

If you\u2019re using Microsoft servers as your primary DDI solution, there are likely vulnerabilities in your DDI infrastructure that you haven\u2019t considered. If you are running DNS and DHCP on Domain Controllers, these vulnerabilities become even more risky, providing a potential opening for attackers to gain complete access to your Active Directory domain. Your chances of having an outage, or even the likelihood of a successful attack on your infrastructure increase dramatically. Unfortunately, insecure default configurations and a \u201cset it and forget it\u201d mentality around DDI are commonplace. In some situations, DDI services may be configured, and left sitting untouched for years. This can be harmful as DDI is dynamic by nature, as clients, and hosts move around your networks. A lack of attention towards the maintenance and security of DDI is dangerous and makes your Microsoft Servers attractive targets for malicious actors.<\/p>\n

In this blog, we\u2019ll take a closer look at a potential attack vector involving DDNS updates via DHCP, and how a secure, modern DDI solution from Infoblox can protect your critical infrastructure against this and many other potential vulnerabilities.<\/p>\n

DDNS and DDNS updates via DHCP<\/h3>\n

Dynamic DNS (DDNS) is used to automatically update DNS records in real time. When properly implemented, DDNS can be a useful tool that saves time for administrators and reduces errors caused by manual processes. DDNS updates can also be sent by DHCP servers on behalf of the DHCP client. DHCP Option 81<\/a>, or the FQDN option, facilitates this process. When a DHCP change occurs, clients can request that a fully qualified domain name (FQDN) be created or updated on their behalf, or the DHCP server can be configured to do this for all clients, regardless of whether they request it. While this appears to be a time-saving feature, with the default configuration, it is inherently insecure. By default, the Microsoft DHCP Server doesn\u2019t verify which<\/i> device is updating which<\/i> record. Furthermore, the Microsoft DHCP Server that is requesting the update to the DNS record uses its own machine account for authentication, giving it access to records that should be outside the scope of DHCP and DDNS.<\/p>\n

Spoofing DHCP Requests and Rewriting DNS Records<\/h3>\n

I\u2019ve deployed a new, unprovisioned, Microsoft Windows Server 2022 in my lab and tested this feature of the Microsoft DHCP Server.\u00a0 It’s shocking how easy it is to rewrite records\u2014any record, whether belonging to a\u00a0 server, random PC, or the Domain Controller itself. Let’s look at a couple common configuration issues found with the default settings on my new Microsoft server. In the screenshot below, we can see an option to configure Name Protection. Enabling Name Protection adds some security, preventing a record for one device from being overwritten by a different device. Unfortunately, it is disabled by default (and often left that way), as in the screenshot below.<\/p>\n

<\/p>\n

Furthermore, in Microsoft Server\u2019s DNS settings, a setting named Dynamic Updates is set to Secure only<\/i> by default.\u00a0 The text below this setting could mislead IT professionals into thinking that setting this setting as Secure only<\/i> would offer name protection of DNS records by other clients, however, this is not the case. When set to Secure only<\/i> this setting only allows authorized clients to make changes to a zone or record; that said, it doesn\u2019t matter which record is being changed. In this case the authorized client is the DHCP Server itself; therefore this setting does nothing to protect records in this use case.<\/p>\n

<\/p>\n

The DHCP server is also using its own account to request DNS updates on the client\u2019s behalf. With DHCP running on the Domain Controller (DC), the DHCP server\u2019s account is in the Enterprise Domain Controllers group, which has full control over all DNS records in the zone (in this case the DNS domain dhcpv.dc). The image below shows a static A Record in our zone. Because our DHCP server is the DC, it can update this record to point wherever it chooses.<\/p>\n

<\/p>\n

So, how can this misconfiguration be used as an opening to attack our infrastructure? There are many tools that can spoof DHCP and DDNS requests. To make it simple, I\u2019ve opted to use the command-line tool DDSpoof<\/a>, which was created by Akamai. This tool automates a lot of the process.<\/p>\n

<\/p>\n

The tool searches for DHCP servers on the local area network via the IPv4 broadcast address, 255.255.255.255. When a server is found, it steps through the DHCP DORA process (Discover, Offer, Request, Acknowledge), which allows for the automatic assignment of IP addresses to clients that request them. When DDSpoof discovers a DHCP server on our network, it asks us what our desired IP address is.\u00a0<\/p>\n

<\/p>\n

To start writing DNS records, we leverage option 81<\/a>. With this tool we request that the server use DDNS\u00a0 to create an FQDN on behalf of the client as part of the DHCP lease request.<\/p>\n

\u00a0<\/p>\n

A quick aside: DHCP options allow clients and servers to specify individual parameters associated with their DHCP lease. A common example: DHCP option 6 provides clients the IP address of a DNS server and option 3 provides a router when a client gets its IP address. <\/i>\u00a0<\/p>\n

By checking the Windows Server DNS Manager, I can see that an A record for the name \u2018testing\u2019 was created as requested.<\/p>\n

<\/p>\n

Of course, this is a new DNS record. What about existing DNS records? What happens if I target the record for a server in our lab? The A record\u00a0 \u2018exampleserver.dhcpv.dc\u2019 is a DNS record for a server in my lab. Let\u2019s see what happens. Warning:\u00a0 Do not try this at home (or anywhere else\u2013except maybe an isolated lab environment).<\/b><\/p>\n

<\/p>\n

Back on the Windows Server, we can see the result.\u00a0<\/p>\n

<\/p>\n

As expected, I was able to overwrite this already-existing record.<\/p>\n

In just a few steps, I was able to successfully spoof a few DHCP transactions, create a new A record, and overwrite an existing A record<\/b>. Again, this is possible on any Microsoft server running DHCP and DNS with their default configurations. Any record could be rewritten, including those of the Domain Controller itself. If malicious actors discover a Microsoft server with this configuration, they could easily perform a man-in-the-middle attack, stealing credentials and potentially gaining the keys to your organization.\u00a0<\/p>\n

There are ways to mitigate some of the risk of these types of attacks by changing defaults to a more secure configuration, but even with those changes, not all risks are eliminated. However, there\u2019s a much better way to harden and secure your DDI infrastructure while simultaneously providing greater resiliency options and advanced feature capabilities.<\/p>\n

Solution<\/h3>\n

So what can you do? As Akamai\u2019s blog states, Microsoft acknowledges some of the risks pointed out here, but doesn\u2019t plan to make any changes<\/a> to the existing state of Microsoft Server on behalf of them. But how does an administrator mitigate them? The first option is to move your DDI services off of the Microsoft Server Domain Controller onto a separate server or servers dedicated to DDI services. This helps alleviate some of the issues discussed in this blog by way of siloing these business critical services. Simply moving DHCP off of the Domain Controller means the DHCP server is no longer a member of the Enterprise Domain Controller group, with its associated permissions.\u00a0<\/p>\n

For some temporary fixes, you should strongly consider configuring non-default options such as name protection. Other protections are available such as DNS dynamic update credentials, which forces the server to utilize the provided credentials in lieu of the machine account. These settings should, however, only be seen as band-aid fixes as there\u2019s ways to get around them either via brute force, or other means. If you\u2019re curious about these settings, and how they can be bypassed, they are covered more extensively in the Akamai blog referenced earlier, and Microsoft\u2019s documentation.\u00a0<\/p>\n

If moving your DDI services off of your Microsoft Server Domain Controllers is at the top of your mind, what other measures should you consider to strengthen your DDI infrastructure? One of the best ways to enhance the security of DDI infrastructure is to use a dedicated DDI solution, such as Infoblox. Infoblox is a secure, purpose-built, modern DDI solution. Infoblox\u00a0 provides additional ways to secure DDNS, such as restricting updates to static records, marking critical records as protected, and restricting allowed names based on FQDN patterns.<\/p>\n

In addition to securing DDNS, Infoblox makes Microsoft better<\/a> by expanding visibility across platforms, providing role-based access control, delivering unparalleled reliability and scalability, and enhancing automation capabilities with a fully-featured API. It provides a non-intrusive overlay of Microsoft servers, providing complete visibility across Microsoft and non-Microsoft domains from a single interface and allowing you to enhance existing Microsoft investments. Designing your infrastructure with Infoblox provides secure and best-in-class DNS, DHCP, and IPAM.\u00a0 If you\u2019re interested in hearing more, contact Infoblox here<\/a>.<\/p>\n