Her0in 2015/12/01 12:30
As a popular science article, this paper expounds the name resolution mechanism in Windows system, and also mentions several ways to use the defects of name resolution mechanism to attack Intranet.
0x00 Introduction to Windows Name Resolution
TCP communication is based on IP addresses. Name resolution is the process of resolving the name of the computer to be accessed into an IP address.
Name types in Windows
In Windows, the host name and NetBIOS name are available.
The host name
In a narrow sense, a host name is literally the name of a host. Broadly speaking, it includes not only the name of the computer, but also the domain name on the Internet.
A domain name is A tree and A type of host name. Therefore, A host name is hierarchical and contains A maximum of 255 characters, including A to Z, A to Z, and hyphens (-). In the domain name system, a domain name that identifies the DNS name of a host is called a fully qualified domain name (FQDN). The FQDN for seclab.her0in.org, for example, is seclab.
NetBIOS name
In The Windows system, another name is the NetBIOS name. Accurately speaking, the NetBIOS name is not a name system, but a programming interface of the Windows operating system network, allowing hosts to communicate with each other using the NetBIOS name. The communication process is based on NetBIOS protocol. After the Windows OS is installed, the system uses the computer name as the NetBIOS name of the host by default. It contains a maximum of 16 characters. The last bit is unconfigurable and is used to specify the NetBIOS service type. If the computer name is less than 15 digits, Spaces are used to complete to 15 digits; otherwise, if the computer name is more than 15 digits, the first 15 digits are intercepted. Common NetBIOS suffixes are 0x20 (file and print services), 0x00 (workstation services), 0x03 (messenger services), and so on.
Run the nbtstat -n command to view the NetBIOS name of the local host.
Run the nbtstat -a ipaddress command to view the NetBIOS name of the specified IP host.
0x01 Protocols related to Windows Name Resolution
There are three protocols related to name resolution in Windows systems.
DNS protocol for Windows name resolution
The DNS protocol is the most important and preferred name resolution protocol for operating systems. Almost every operating system supports the DNS protocol, and the DNS protocol supports IP V4 and IP V6. During DNS name resolution, there is no local database file on the client. It is completely dependent on the DNS server and listens to UDP/53. On the client, you can run the ipconfig /displaydns command to check the LOCAL DNS cache, and run the ipconfig /flushdns command to clear the local DNS cache.
The DNS name resolution process is as follows:
- Read the local DNS cache (already containing the local hosts file contents)
- If not in the cache, the DNS server configured in the network configuration is requested
- If the DNS server does not respond, the request fails. Conversely, the DNS server processes user requests.
NetBIOS protocol for Windows name resolution
In addition to DNS, NetBIOS (Network Basic Input/Output System) was also used for name resolution in earlier versions of Windows. The NetBIOS protocol name resolution described in this document is the NetBIOS over TCP/IP name resolution type defined by Microsoft later.
The NBT service listens to port UDP/137 and sends broadcast packets to the subnet domain where the host resides. Therefore, when you use the packet capture tool to capture packets in the LAN, you will always receive a lot of NBNS packets.
Since NetBIOS protocol for name resolution is sent UDP broadcast packets. Although this is fast and requires no additional configuration, broadcast packets cannot cross the network domain and increase some network traffic. Therefore, Microsoft later introduced Windows Internet Name Service (WINS) server. When a computer is configured to use the WINS server for Name resolution, The client communicates directly with the WINS server unicast, which makes up for NetBIOS name resolution using broadcast.
In summary, the NetBIOS name resolution process is as follows:
- Check the local NetBIOS cache
- If the request name is not in the cache and WINS servers are configured, the request is then made to the WINS server
- If no WINS server is configured or the WINS server does not respond, the system sends broadcasts to the current subnet domain
- If there is no response from the host, the local LMhosts file is read
The lmhosts file is located in the C:\Windows\System32\drivers\etc\ directory.
Run the nbtstat -c command to check the NetBIOS cache on the local PC
Run the nbtstat -r command to clear the local NetBIOS cache
LLMNR protocol for Windows name resolution
DNS name resolution is efficient but requires an independent DNS server on the LAN. NetBIOS name resolution requires an independent WINS server in some cases, and NetBIOS does not support IP V6. Therefore, to compensate for these shortcomings, Microsoft introduced an end-to-end Name Resolution protocol, link-Local Multicast Name Resolution (LLMNR), after Windows Vista.
LLMNR is also called multicast DNS because its packet format is similar to DNS packets. The listening port is UDP/5355, supports IP V4 and IP v6, and also implements this protocol on Linux. The resolved name is end-to-end. The IPv4 broadcast address is 224.0.0.252, and the IPv6 broadcast address is FF02: 0:0:0:1:1-3 or FF02::1:3.
LLMNR performs name resolution as follows:
- Check the local NetBIOS cache
- If not in the cache, a broadcast is sent to the current subnet domain
- Other hosts in the current subnet domain receive and check the broadcast packet. If no host responds, the request fails
0x02 Order of Name Resolution in Windows
Two factors affecting name resolution in Windows system
Operating System Version
As you can see from the above section, not all operating system versions support all three protocols.
Windows 2K, XP, and 2K3 support only DNS and NetBIOS. Therefore, Windows versions of this type resolve the DNS name first. If the DNS name fails to be resolved, the NetBIOS name is resolved.
Windows Vista (including 2K8, Windows 7, Windows 8. X, Windows 10) supports the above three protocols. If the DNS name fails to be resolved, LLMNR is used for name resolution, and NetBIOS is used for name resolution.
Network node mode
Another factor that affects name resolution on Windows systems is the network node mode of the current host. You can use the ipconfig /all command to view the local network node mode, as shown in the following figure:
Figure 1 Viewing the local network node mode
The network node mode mainly affects the NetBIOS name resolution process, such as whether to query the WINS server first or broadcast in the subnet domain first. The specific and node modes are described as follows:
- B-节点(broadcast，广播)
Windows uses broadcast for name registration and name resolution, and depending on the gateway configuration, a b-node client cannot send packets outside the LAN. However, node B is not suitable for large networks. In fact, Microsoft has modified the standard type of node B. When Windows attempts to resolve a name, it first checks the LMHOSTS name cache. Then Windows will check the actual LMHOSTS file.
- P-node (per-to-per, peer)
This approach does not use broadcasts, but registers their names with the WINS servers in the network when the computer starts up, and when the computer needs to resolve the names, it sends a resolution request to the WINS servers. This method only works when the WINS server is running properly. If the WINS server fails, name resolution cannot be performed.
- M-node (mixed, mixed)
Windows uses both B and P nodes together and uses B by default. If M node cannot use broadcast for name resolution, it uses WINS server of P node to do the job.
- H-节点(hybrid，混合)
B node and P node are also used jointly, but the work mode is opposite. If the WINS server mode fails, the work of B node is used to complete the work. This node mode is also the default node mode used by Windows.
0x03 An Intranet Attack Exploits a Defect in the Windows Name resolution mechanism
Common attacks using Windows name resolution mechanism defects include DNS Spoof, NBNS Poison, LLMNR Poison, ICMP Redirection.
This can be done using Responder from SpiderLabs, or the ZARP toolkit.
LLMNR Poison attacks the following environment:
- The attacker host (Linux) IP address 192.168.237.133
- Victim host (Windows 8.1) IP 192.168.237.129
- The two hosts are on the same LAN
LLMNR Poison attack is triggered when the victim accesses a host that does not exist on the current LAN.
Figure 1: The victim host pings a host that does not exist on the LAN
Figure 2: Responder responds to LLMNR’s broadcast packet and launches a Poison attack
Figure 3: The host IP records of the Poison attack have been added to the NetBIOS cache on the victim’s host
LLMNR Poison attacks can be executed using a share that allows the victim to access a host that does not exist, so that the HASH of the victim’s host can be used for brute force cracking. If the password is weak, You can blast the code. It is also possible to use the victim to access a non-existent HTTP server for 401 authentication to get the client HASH, as shown below:
Figure 4: Victim accessing a share on a non-existent host
Figure 5: LLMNR Poison attacks get the HASH during SMB validation
Figure 6: Brute force cracking of the HASH using John
0x04 References and references
Support.microsoft.com/en-us/kb/11… En.wikipedia.org/wiki/Link-L… Support.microsoft.com/en-us/kb/16… Support.microsoft.com/en-us/kb/16… Read.newbooks.com.cn/info/132528…