As missing patches are being deployed on time to prevent potential compromise, organizations are improving their security posture to avoid the most common threats from targeting them. However, a trend Packetlabs has noticed is that while exploiting systems directly is becoming more and more uncommon, the protocols in which the systems communicate with are susceptible to different types of attacks.
These vulnerable communication protocols allow attackers to masquerade as legitimate services resulting in the relaying and capture of authentication tokens and are all a result of using legacy or insecure services. Below are the four affected services we most commonly come across.
Insecure IPv6 Configuration
By default, all Windows versions above Windows Vista (including servers) have IPv6 enabled and prefer it over its IPv4 counterpart. On a network packet level, these Windows machines above Vista will request an IPv6 configuration via DHCPv6. This default IPv6 configuration allows an attacker to take over an internal network’s DNS by replying to the DHCPv6 packets.
Since an IPv6 configuration is preferred over an IPv4 configuration, the IPv6 DNS server will be the preferred DNS server. This configuration enables an attacker within the network to act as a rogue DNS server, which effectively acts as a proxy and would be able to redirect traffic. Furthermore, this misconfiguration allows attackers to leverage the Windows Proxy Auto-Discovery (WPAD) feature to relay the NTLM challenge and response and authenticate to various services and servers within the network.
Legacy Protocols: Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS)
Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are two components of Microsoft Windows systems used as a backup when DNS is not able to resolve the user’s query. LLMNR was introduced in Windows Vista and is the successor to NBT-NS.
If one endpoint attempts to resolve a particular host, but DNS resolution fails, the machine will then attempt to ask all endpoints on the local network for the correct address via LLMNR or NBT-NS. Even though this seems harmless in theory, it enables an attacker to poison responses and performs various attacks to obtain unauthorized access to the network.
Insecure Server Message Block (SMB) Configuration
SMB utilized NTLMv1-2 to authenticate users to file shares. NTLM is a challenge/response protocol that can be vulnerable to an attacker inserting themselves into the middle of the exchange. This attack is dangerous as it allows any potential attacker with access to capturing network traffic and then relaying it to get unauthorized access to potential servers or other hosts.
Insecure Kerberos Deployment
Kerberos is a ticket-based authentication protocol. Windows has implemented a Kerberos authentication service that is built into Active Directory. Any domain user possessing a Kerberos ticket-granting ticket (TGT) may request ticket-grant service (TGS) tickets for any accounts with Service Principal Names (SPNs) from a domain controller. When a TGS is requested for an SPN by a user the TGS is granted to the user, as long as they have a valid TGT. This does not allow the user possessing the TGS to access the service; the service determines if the requesting user has authority.
However, the TGS contains some data that is encrypted by the SPN account’s NTLM hash. This data can be used in a password cracking attack to reveal the plain-text password of the service account. Microsoft does not consider this a vulnerability: as a result, special attention and configuration of accounts with SPN values are required.
Remediation for each affected service must under-go testing before deploying to production as some of the services are needed on legacy systems. For example, NetBIOS or LLMNR is required for Windows 2000 and earlier. Below are the quick remediation steps for each of the four affected services.
- IPv6 – If it is not being used, disable IPv6
- Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) – disable LLMNR and NetBIOS where possible
- Server Message Block (SMB) – enable SMB signing on all workstations and servers
- Kerberos – Regularly monitor accounts to ensure only services requiring Kerberos authentication have a non-null SPN value. Use AES encryption instead of RC4 for Kerberos services. For SPN enabled accounts, use a 25 character or greater password
At Packetlabs, we specialize in assessing and exploiting networks using insecure protocols. If you need assistance with evaluating your network for these protocols, contact us for an assessment.