The Salmon Fishing Bear Attack OR Grabbing password hashes off the network via NetBIOS

A bit of background

NetBIOS is an old protocol developed by IBM to facilitate the task of finding a hosts on networks, which at the time were not based on today’s common TCP/IP protocol stack. It is comparable to a distributed mix of ARP and DNS where broadcast is used as the means to propagate registration and query messages.

Microsoft implemented a modified version of NetBIOS with additional features and used it as a core protocol on its TCP/IP based networks until Windows NT 4.0. Together with the introduction of Active Directory they moved to DNS to perform NetBIOS’s duties. However since then NetBIOS has been carried forward through all operating system versions for compatibility reasons. Presently NetBIOS over TCP/IP is enabled by default on all Windows versions and operates on ports UDP/137 and (rarely) on TCP/137.

In one of the common modes of operation of NetBIOS, client workstations and servers broadcast name resolution requests that are responded by the target host with its address in a unicast response. The client then connects directly to the intended service using the IP address provided on the response.

When this distributed model of NetBIOS name resolution is in use in a given network, it is possible to conduct a spoofing attack which allows the attacker to obtain encrypted cached credential hashes that are susceptible to dictionary and brute force attacks.

The Salmon Fishing Bear

This attack consists of listening to broadcast NetBIOS name resolution queries from hosts on the network and responding with the attacker’s own IP address as the query’s response, causing the victim’s host to connect to the intended service on the attacker’s host rather than on the real target server. Subsequently an authentication protocol is initiated from the client station which involves sending the connecting user’s encrypted cached credential string, which can be collected by the attacker’s host.

After a while the attacker collects a list of usernames and cached password hashes that cannot be reused directly but can be cracked by applying dictionary or brute force methods. The success rate of small scale password attacks is inversely proportional to the strength of passwords encrypted in the captured hashes – the stronger the passwords, the less likely it is that they’re cracked. This is often controlled and influenced by local and domain security policies, in particular password complexity policies.

…it’s as easy as a bear swiping salmon from a river full of fish.

This is a simple and effective attack that relies on a legacy protocol that usually goes unnoticed.

In an Active Domain environment, it is expected (by design) that each user authenticated to services on the network using its own domain account. Therefore this scenario is particularly useful for the attacker to gather a set of valid domain accounts and encrypted passwords. Some of these could be privileged enough to access sensitive information on network services, be it file shares, web applications, databases, CCTV, door management, etc.

Remediation

The flaw being exploited is the fact that by default NetBIOS is enabled and on Windows operating systems up to and including Windows XP sets the host to a ‘b-node’ type meaning ‘broadcast’. Disabling NetBIOS over TCP/IP mitigates both flaws but could lead to operatonal limitations (if any service depends on netbios to operate).

Alternatively it is possible to control the behaviour of the protocol to make it use a query server (Windows Internet Name Service – a centralised implementation of the NetBIOS Name Service module) rather than broadcasting queries. This makes it more secure and less susceptible to the attack discussed.

In the NetBIOS protocol, hosts are known as nodes and can be of several
types: B, P, M and H. The only type that does not resort to broadcast for name resolution and registration is P-node which will instead unicast requests to a dedicated Windows Internet Name Service (WINS).

Forcing NetBIOS hosts into being P-nodes is the most secure setting for Windows hosts because it eliminates the use of broadcast for NetBIOS messaging.

Controlling NetBIOS locally or centrally

NetBIOS can be completely disabled by setting the system service ‘TCP/IP NetBIOS helper’ to ‘disabled’.

The protocol can be controlled locally and individually on each network interface by editing the interface’s properties (using the GUI) or by changing registry options related to those interfaces.

In particular, the keys
HKLM\System\CurrentControlSet\services\NetBT\Parameters\Interfaces\\NetbiosOptions
(REG_DWORD) can be set with one of three values:

• 0x0: Use NetBIOS settings from DHCP or enable if IP is statically set;
• 0x1: Enable NetBIOS over TCP/IP;
• 0x2: Disable NetBIOS over TCP/IP;

Setting node types locally can be done by modifying the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters\NodeType (REG_DWORD)

• 0x1: b-node – broadcast;
• 0x2: p-node – peer to peer;
• 0x4: m-node – mixed mode: broadcast, then peer to peer;
• 0x8: h-node – hybrid mode: peer to peer, then broadcast;

The option ‘Use NetBIOS setting from the DHCP server’ in network interface properties (enabled by default and controlled by the above mentioned registry key) allows NetBIOS configuration to be influenced by DHCP options, in particular WINS location and node type selection, respectively DHCP options 44 and 46 (translated to ISC DHCP daemon options netbios-name-server and netbios-node-type).

References

• technet.microsoft.com/en-us/library/cc940063.aspx – Description of NetBIOS over TCP/IP
• support.microsoft.com/kb/313314 – Disable NetBIOS via DHCP options (useful when hosts are setup with the default netbios setting)
• technet.microsoft.com/en-us/library/cc775874%28WS.10%29.aspx – NetBIOS configuration parameters
• support.microsoft.com/kb/158474 – Windows TCP/IP registry entries