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

• SANS Site Network
  • Current Site
  • SANS 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