Information Security / A guide to DNS Search Suffix Wi-Fi attacks
A guide to DNS Search Suffix Wi-Fi attacks
3 June 2019
Wicus Ross, Lead Security Researcher, and Lauren Rudman, Junior Security Researcher, SecureData, show us how even the most security-savvy employees can fall foul of DNS Suffix Wi-Fi attacks.
Ever get a feeling that despite your VPN, public Wi-Fi networks could still be a significant risk?
Last year, when two of our employees were connected to the complimentary Wi-Fi at the same hotel, their laptops were assigned a connection-specific DNS Suffix of ‘domain.com’ by the hotel’s Wi-Fi Access Point.
Such DNS suffixes are used when there is a DNS query without a Fully Qualified Domain Name (FQDN). For example, if your computer makes use of a server or service within your private network it can often be configured without specifying its full and complete Internet name.
That ‘short’ name makes no sense on the actual Internet, however, so a ‘search suffix’ is often prescribed by the network as a way of completing the services full, internet name.
When our employee’s laptops attempted to connect automatically to a previously mapped network share, it triggered an alarm in the SecureData Managed Threat Detection System highlighting outbound network traffic on port 445.
This was because the network shares were not using FQDNs, as they belonged to SecureData’s internal network, so the search suffix ‘domain.com’ was prescribed by the Access Point and appended to the end in order to create a FQDN.
Resulting in the new share names being ‘domain.com’ subdomains. For example, ‘sde-file-share’ became ‘share-file-share.domain.com’, which surprisingly translated to an actual IP address on the internet. The reason for this is that ‘domain.com’ is a wild-card resolver and will resolve most sub-domains to a single IP address.
Windows network traffic associated with network shares uses the Server Message Block (SMB) protocol on port 445 and, is usually blocked by organisations firewalls if the connection is going out to the internet. This is due to the fact that attackers can use these connection attempts to gather Windows credentials.
SMB is not blocked by the hotel’s network, however, creating the risk that SMB traffic might actually be sent out the IP address mapped to ‘domain.com’ in the DNS.
Also of interest: It’s time to kill the VPN
Let the DNS Suffix games begin
We conducted research on domain.com itself and found that it is a legitimate business where domain names can be purchased. They also sell hosting plans, virtual private servers (VPS), SSL certificates, and more.
We concluded that there is no easy way to abuse the wildcard resolver for domain.com, as we have no ability to influence the sub-domain resolution process. In other words, we could not get domain.com to resolve a host to an IP that is linked to a host under our control.
To demonstrate how an attacker could take advantage of a Connection-specific DNS Suffix, in order to gather usernames and NTLM password hashes, from computers that have connected to a Wi-Fi network, we set up a lab environment. This consisted of four parts: a Wi-Fi access point, a victim laptop, a remote server, and a domain name.
We were trying to simulate a coffee shop or B&B type scenario, where a Wi-Fi network was configured to give a malicious DNS suffix to users. This could be set up by an owner of the establishment, or anyone with access to the device’s configuration.
When a user connects to the legitimate Wi-Fi network, they will be assigned an IP address and a Connection-specific DNS suffix. If they reboot their laptop and were previously connected to a network share without a FQDN, the victim’s laptop would send their username and password-hash to the attacker’s server without their knowledge.
For the Wi-Fi network, we created an access point on a laptop using software called ‘hostapd’. This is a host access point daemon program that lets you configure and run an access point on a computer.
On the same laptop, we also ran ‘dnsmasq’, which provided the DNS forwarder and more importantly the highly configurable Dynamic Host Configuration Protocol (DHCP) server. The DHCP server was set up to give a DNS search suffix of ‘tikoloshe.net’, a random domain we previously purchased. A screenshot of the configuration file for dnsmasq can be seen below:
For the victim’s laptop, we used Windows 10 that was in a workgroup and connected to a share. Additionally, we used the purchased domain name and created a wildcard subdomain for it that pointed to a remote server under our control. This meant that someone trying to access any subdomain of our domain name, would be directed to our server.
On the remote server, we ran ‘Responder’, a hacking tool with a built-in SMB rogue authentication server, that opens port 445 onto the internet. Port 445 is used for the SMB protocol, which network shares use.
When a computer attempts to connect to a remote share, it tries to authenticate and Responder is able to capture the SMB authentication username and NTLM password hash.
Also of interest: What is the biggest threat to Domain Name System security?
Get ready, get steady, attack!
To start the scenario, the victim laptop authenticated to the Wi-Fi network. Below is a screenshot of when ipconfig was run on the Windows machine. As you can see, the Connection-specific DNS suffix is set to a domain under our control.
Wireshark, a network protocol analyser, was run on the victim’s laptop, to capture network traffic, while a remote share called \\server\share was being accessed manually and it resulted in the DNS requests below. These DNS requests were to ‘server.tikoloshe.net’ because the laptop could not resolve the original short-name… ‘server’.
After the DNS requests, the victim’s laptop started to connect to server.tikoloshe.net, which has resolved to an IP address of our malicious server. As shown below, a TCP connection is set up and then the SMB protocol negotiation is started.
When attempts to connect to server.tikoloshe.net via SMB 445 were made, Responder captured the victim’s username and password hash. From here, the hash would need to be cracked by a cracking program like ‘hashcat’.
A more realistic scenario is shown below, where a user does not have to manually connect to a share in order for an attacker to steal their password hash. All that is needed is to connect to a malicious Wi-Fi network with a laptop that has a previously mapped network share and at some stage, restart their computer.
Also of interest: The five most common social engineering attacks targeting your Wi-Fi
Next time you think about connecting to a public Wi-Fi network, remember:
Users should always be cautious of the risks involved even in the few seconds after they have connected to a network, but before any VPN is connected. Where possible any internal servers should be identified by Fully Qualified Domain Names, to prevent an additional suffix being prescribed.
Additionally, to mitigate the risk it is recommended that network shares/mapped drives are disconnected before attempting to join any untrusted networks.
In Windows, ‘ipconfig’ can be run in the command line to determine if a suspicious Connection-specific DNS suffix has been assigned. If this is the case, the network may not be considered safe.