Is it time to get rid of NetBIOS?
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:
- 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).
- 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!
- 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:
- 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.
- 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 | Munich | Oct 14th - Oct 19th 2024 |
Comments
Doesn't matter much, I just thought I'd point that out.
Seth
Jan 25th 2012
1 decade ago
RWM
Jan 25th 2012
1 decade ago
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.
PHP
Jan 25th 2012
1 decade ago
@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
Jan 25th 2012
1 decade ago
Adding network and sharing center research to the todo list.
Scott H.
Jan 25th 2012
1 decade ago
I will do more testing (and possibly another diary documenting what I found) but so far it indeed looks bad.
Bojan
Jan 25th 2012
1 decade ago
Al of Your Data Center
Jan 25th 2012
1 decade ago
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
Jan 25th 2012
1 decade ago
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.
David C.
Jan 25th 2012
1 decade ago
Joshua
Jan 25th 2012
1 decade ago