SANS ISC: Is it time to get rid of NetBIOS? - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

NetBIOS, and its weaknesses that allow extremely easy spoofing have been well known all the way since 2005. I recently discussed NetBIOS with a colleague of mine, Arcel, and this discussion prompted me to see if anything changed with NetBIOS and recent Windows releases.

While I was almost certain that the old NetBIOS spoofing attacks do not work any more, I was stunned to see that even the latest and greatest Windows 7 still enable NetBIOS over TCP/IP by default.

In today’s interconnected world, where we jump from one (wireless) network to another, this might have serious impacts on our security. The question is it time to get rid of NetBIOS sounds logical. Let’s see what’s happening here.
Starting with Windows 2000, all Windows operating systems (XP, 2003, Vista, 7, 2008) depend mainly on DNS to resolve network names. However, if DNS is not working, or the name cannot be resolved, Windows will try to use NetBIOS to resolve such network name.

Now, if a WINS server has been configured this should not be a problem, but in case when a WINS server is not present (or available), Windows will still try to use NetBIOS to resolve a network name. In such cases, Windows will send a NetBIOS Name Query packet, which is an UDP packet sent to a broadcast address. You can see one such packet in the screenshot below:

You can probably guess what an attacker can do – since this is a broadcast packet, the attacker does not even need to perform other initial attacks such as ARP poisoning. He can simply send a NetBIOS Name Query Response with any contents he wants! As a matter of fact, even a Metasploit module exists that does this automatically (see auxiliary/spoof/nbns/nbns_response).

Now, the question that we have to think about is what attack scenarios are we dealing with here? Here come a few, judge for yourself how serious they are:

1. Whenever a user mistypes a network name, the attacker can spoof the response. Depending on what the user tries to access (i.e. a SMB share or a web page), the attacker can use another Metasploit module in order to catch exchanged credentials. Keep in mind, though, that only hashes are exchanged here so the attacker still needs to crack the original user’s password (or try to perform some relaying attacks).
    
2. One of the names that is particularly sensitive is WPAD. It is used by web browsers for automatic retrieval of proxy settings. In a scenario where we connect to an open wireless network, where the local DNS server does not have this name registered, an attacker can spoof the WPAD’s entry’s IP address and further even serve a fake wpad.dat file. This would allow him to inspect the victim’s web traffic!
    
3. A lot of companies like to set their user’s home page in browsers (i.e. Internet Explorer’s home page). Now, when the user opens Internet Explorer on a malicious network, Internet Explorer will try to resolve that name. Since that name is usually something like “intranet” or “intranetweb” DNS will , of course, fail to resolve it. This gives the attacker an opportunity to fake this name. And what’s even worse, Internet Explorer will automatically send user’s credentials to the resolved web page, since it will consider it to be in the Local Intranet zone. The picture below shows my fully patched Windows 7 machine falling prey for this attack and trying to retrieve wpad.dat as well as giving my test account’s credentials when I opened http://intranet:

As you can see from the scenarios mentioned above, this “vulnerability” can be extremely serious. To make things even worse, if you use an older operating system such as Windows XP, and you haven’t disabled LANMAN (LM) hashes, cracking them in such a case is trivial. Luckily, as you can see in the picture above, Windows Vista and above disable LANMAN hashes by default, so only much stronger NTLMv2 is used. Still, if your password policy is inadequate, an attacker can crack such passwords.

So what can we do to protect ourselves and our users against this? This is one of those times when auditors that bug you about settings and configuration are really right:

1. Unless you moved everything to Windows Vista or newer, make sure you disable LANMAN hashes. They are insecure and should not be used under any circumstances.
    
2. Disable NetBIOS over TCP/IP. I don’t think that anything really uses this any more (if I’m wrong let us know please!)

If you want to learn more about this attack, read the excellent post at http://www.packetstan.com/2011/03/nbns-spoofing-on-your-way-to-world.html and, once you get scared enough, take care of your network and users.

--
Bojan
INFIGO IS

Web App Penetration Testing and Ethical Hacking - SANS London September 2018

You may want to change the article title since you are really talking about the NetBIOS naming service. Not all of NetBIOS. SMB and SMB2 messages both use NetBIOS session service headers as framing.

Doesn't matter much, I just thought I'd point that out.

I have 7 networked devices just at home, all <3 years old, which use NBNS to locate the device... 2 aquarium controllers (of different brands), an irrigation controller, 2 AIO printers, a NAS, and a WiFi digital picture frame. NBNS ain't dead! Nor can the average non-technical home/small business user get away with disabling NB over TCP/IP.

At work I have been running with NetBIOS disabled for a few years by now. Here everything works by DNS; our network is segmented into lots of server and user IP nets, so broadcast traffic will only see other devices of the same type. But things has been working flawlessly.

At home, I have more problems. There I do not have an updated DNS of my devices, so I used IPs for everything. But OpenWRT can handle that, playing nameserver for DHCP devices. But I have not got around to that yet. DDWRT does not seem to support this.

The official way to make announcement these days are mDNS (avahi on unix), and the Microsoft SSDP. All using multicast rather than broadcast.

Good comments, please keep them coming :)

@Seth - thanks, you are correct, will leave it like this unless an update happens.

@RWM - it is indeed difficult for a home user to disable NB. That makes me wonder if they are even more exposed when visiting foreign networks, since they will typically lack strong password policies as well.

@PHP: Thanks for comment, mDNS and SSDP certainly seem like a way to go, although they have their own share of potential problems as well.

Is the new wizard called the network and sharing center part of the solution here? Are new connections placed in the restrictive public network category (network discovery off) by default? I haven't read technet on the features but the Win7 help states: "Network discovery requires that the DNS Client, Function Discovery Resource Publication, SSDP Discovery, and UPnP Device Host services are started, that network discovery is allowed to communicate through Windows Firewall, and that other firewalls are not interfering with network discovery. If some but not all of these are true, the network discovery state will be shown as Custom."

Adding network and sharing center research to the todo list.

@Scott - From my testing no matter which network profile settings I had active (home, domain, public), Windows 7 always tried to use NBNS to resolve names. First packets are even sent before the user logs in.

I will do more testing (and possibly another diary documenting what I found) but so far it indeed looks bad.

In Windows 7 if you allow remote desktop connections inbound and allow weak encryption, you've opened the door.. but in order to work in a mixed network with XP you would have to do this. Basically damned by design. Hard coding your hosts file solves most problems with the exception of network file sharing when you choose a work network, not a home network. Home networks have many other issues but file shares are encrypted at least. Work networks do not use the same security, have minimal encryption and accept different login security. It is actually less than a home network. Got to laugh at that one. When sharing files across a netowrk you turn on network discovery though. Boom, NBNS all over again.

"Disable NetBIOS over TCP/IP. I don’t think that anything really uses this any more (if I’m wrong let us know please!)"

The database browsing functionality of the SQL Server 2005 client library, and installation process of some database driven applications that require you select a Database server and SQL instance from a drop down list.

(With NetBIOS disabled, the drop down list of database server instances may be empty)

NBNS is still very active on public networks.

I once packet captured my connection to a college network, and before I had even had time to confirm the network as "Public" Windows 7 had already spouted out the name of every computer on my home network in NetBIOS Name Queries.

I think OpenWRT with DNS is going to be the best answer for me, but there is currently no solution for the non-techie home users.

At work, for some reason the DNS server resolution doesn't always work for who-knows-what reason, leaving the NetBIOS fallbacks the only thing working.

I heard that certain banking software applications (the back-end part of banking) still use NetBIOS as a way to determine which workstation PC is talking to them.

Here is another great netbios spoofing article and tool created by a fellow SANS member.
http://www.mcgrewsecurity.com/tools/nbnspoof/