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. 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:
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:
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 393 Posts ISC Handler Jan 24th 2012 |
Thread locked Subscribe |
Jan 24th 2012 8 years ago |
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. |
Anonymous |
Quote |
Jan 25th 2012 8 years ago |
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.
|
RussM 4 Posts |
Quote |
Jan 25th 2012 8 years ago |
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. |
Povl H. 75 Posts |
Quote |
Jan 25th 2012 8 years ago |
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. |
Bojan 393 Posts ISC Handler |
Quote |
Jan 25th 2012 8 years ago |
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. |
G.Scott H. 48 Posts |
Quote |
Jan 25th 2012 8 years ago |
@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. |
Bojan 393 Posts ISC Handler |
Quote |
Jan 25th 2012 8 years ago |
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.
|
Al of Your Data Center 80 Posts |
Quote |
Jan 25th 2012 8 years ago |
"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) |
Mysid 146 Posts |
Quote |
Jan 25th 2012 8 years ago |
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. |
Mysid 2 Posts |
Quote |
Jan 25th 2012 8 years ago |
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.
|
Mysid 39 Posts |
Quote |
Jan 25th 2012 8 years ago |
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.
|
AndrewB 24 Posts |
Quote |
Jan 25th 2012 8 years ago |
Here is another great netbios spoofing article and tool created by a fellow SANS member.
http://www.mcgrewsecurity.com/tools/nbnspoof/ |
emueller 3 Posts |
Quote |
Jan 26th 2012 8 years ago |
Sign Up for Free or Log In to start participating in the conversation!