(This is a written supplement to a presentation by George Chen and myself, which we gave at BSides Singapore 2022. Any views expressed herein are solely our own and do not reflect the views of our employers.)

DNS Search Suffixes

The use of DNS search suffixes is not uncommon. One particularly common use-case involves relying on these search suffixes to implement web browsing shortcuts, so that users can simply type go/<shortlink> or even just <shortlink> within their browsers to access intranet resources.

The DNS search suffixes is advertised to network clients via DHCP option codes 15 and/or 119.

The Vulnerability

The security issue arises when:

1. A corporate endpoint is not connected to the internal network (whether physically or over VPN)
2. An application on the endpoint attempts to resolve an unqualified multi-label name (per RFC 1034)
3. The network which the endpoint is connected to advertises a DNS search suffix.

Ordinarily, corporate endpoints remain on-premises and physically connected to the internal network, so the organization remains in control of the endpoints’ network configuration.

With the rise in remote working as a result of the COVID-19 pandemic, however, it is no longer a given that corporate endpoints remain at the office.

We take the example of a remote employee, whose corporate device is connected to a non-corporate LAN that is advertising a DNS search suffix of <suffix>:

1. An application on the device attempts to resolve example.internal-corp.com
2. The system DNS client attempts to resolve the hostname in (1), via public DNS resolvers
3. The public DNS resolver returns an NXDOMAIN
4. Because of (3), the system DNS client fallsback to example.internal-corp.com.<suffix>
5. If an IP address is returned in (4), the system DNS client returns the IP to the application, as if the IP address is a result for (1)
6. The application connects to the IP address in (4), unaware that the IP address is resolved from a completely different domain

Sample packet capture showing the DNS suffix appending behaviour.

If the DNS search suffix is controlled by an attacker, or is an unregistered name on the Internet, the potential for information disclosure/man-in-the-middle attacks arises.

In our limited testing, we identified a few such unregistered suffixes, registered the domains, and listened on HTTP(S), LDAP, and SMB ports. Items we have observed include:

• NTLM hashes
• HTTP requests to internal-only paths
• WebDAV requests
• Sync/enrollment requests for endpoint management/orchestration solutions
• Requests from SCCM clients
• ActiveSync sync attempts
• XMPP over HTTP
• (interestingly) HTTP requests to defunct C2 domains

Am I Vulnerable?

There are many ways to check whether your organization is vulnerable to such a threat scenario. There is one obvious one, however:

If your internal corporate domain name uses a TLD that is assigned by IANA, and is still available for public registration, then your organization is vulnerable and you should take steps to register that domain name at the earliest opportunity.

If you record all DNS query activity from your corporate endpoints (even when they are not connected to your internal network), identifying the vulnerable behavior is relatively simple — all DNS queries originating from the endpoint of the form <your internal domain>.<TLD>.<something else> are candidates for investigation.

Alternatively, Windows endpoints with this vulnerable configuration can also be identified by checking the value(s) of the network adapter’s Connection-specific DNS Suffix. This can be obtained programmatically with the Get-DnsClient PowerShell cmdlet.

The situation becomes a bit more difficult if your DNS logs are recorded from the perspective of your internal resolver, since by definition an endpoint will have to be connected to your internal network to query your internal resolver. Based on our limited tests, however, we observed that in cases where the endpoint is connected to the internal network via a VPN connection (rather than physically connected on-premises), positive log entries may be apparent. This is usually due to the network adapter’s DNS Suffix not being overridden completely (i.e. both the user’s ISP/router’s suffix and the internal corporate domain are listed as suffixes).

Remediation

• In the vast majority of cases we have seen, the DNS suffix query behaviour can be disabled at the system-level on Windows endpoints by setting the following Group Policy object to “Disabled”:

Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Allow DNS Suffix Appending to Unqualified Multi-Label Name Queries

• We saw Chrome on macOS performing these DNS queries due to Chrome’s built-in DNS client. This can be disabled by setting the BuiltInDnsClientEnabled policy to “Disabled”.
  Note: for the Chrome browser specifically, our tests indicated that continued usage of the built-in DNS client will not lead to impersonation of TLS-protected websites. Chrome will continue to display certificate mismatch warnings.

Recommendations

• Disable the DNS suffix query behaviour on endpoints/applications (see above). This will not affect shortlinks (single-label names).
• If your internal corporate domain is still available for registration, it should be registered as soon as possible.
• Do not assume that the “unique” TLD you chose for your internal corporate domain will remain unavailable for registration in future.
• Users/employees should exercise caution when connecting their work devices to an unknown network.