Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: Windows Firewall Bypass Vulnerability and NetBIOS NS SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Windows Firewall Bypass Vulnerability and NetBIOS NS

One of the attacks I always perform when doing internal penetration tests is NetBIOS Name Spoofing. NetBIOS has been a golden mine for penetration testers for years – many good articles about how to use NBNS spoofing have been written, and Metasploit comes with a module that allows you to easily abuse NBNS in order to collect LM and NT hashes from victim machines (of course, depending if LANMAN has been disabled or not).

I wrote a diary about this back in January so if you want to see details on how to abuse this I’d suggest that you read first.

However, attacking clients, retrieving their LM/NT hashes and cracking them, as fun as it is, is only half of the job a penetration tester has to do. Besides capturing the flag, the report you produce must also include recommendations on how to mitigate the detected vulnerability otherwise it is really useless for your client (no matter how cool it is for us penetration testers to pwn something).

So after seeing NBNS being abused in many internal penetration tests (all?) I started checking what potential security controls we have at our disposal to prevent such attacks, or at least to make them less effective.

Obviously, the best way to prevent NBNS spoofing attacks is to completely disable NetBIOS name resolution. However, this maybe be easier said than done – from the diary I posted before (link above) it appears that there are many other services that still depend on NBNS.

Since Windows operating systems now come with a firewall (“Windows firewall” with Windows XP SP2 and “Windows Firewall with Advanced Security” with Vista and newer OSes) that can have multiple policies, depending on the current location of the machine (home, work or public networks), this sounded like a perfect idea for preventing NBNS attacks. In this scenario, an administrator that controls client machines through group policies could allow NBNS in home and work networks and disable it completely in public networks. While not perfect, this still offers a certain (and I’d say decent) amount of protection.

However, while testing this I noticed that the Windows firewall has a nasty bypass vulnerability (the now patched CVE-2012-0174 vulnerability).

In order to test it I turned on both inbound and outbound firewalls – remember that the Windows built-in firewall does not stop outbound connections by default:

Windows Firewall profile settings
Besides this, NBNS rules had to be disabled manually, in order to prevent NB-Name-Out network traffic. By stopping this traffic we would make sure that an attacker cannot abuse NBNS spoofing attacks, since the built-in firewall would stop all such outgoing requests. You can see the rules, with their respective profiles in the following picture:

Windows Firewall settings
After setting this, I expected that my NBNS spoofing attacks will fail. However, that did not happen – the attacks were still successful, and I was able to see NBNS queries on my local network. After setting up logging in the Windows firewall as well, I confirmed that Windows was happily letting this traffic leave, despite all the rules that have been set above:

2012-01-29 11:07:21 ALLOW UDP 137 137 0 - - - - - - - SEND

This log shows a NBNS query destined to the local network’s broadcast address.

The issue here is pretty clear – this means that an organization’s administrator who set such rules to protect his clients when they leave the organization’s network cannot rely on the built-in Windows firewall!

And, if you take a look at the attack scenarios I mentioned in the first diary, this can be particularly nasty for browsers configured in organizations. For example, a lot of organizations configure browsers on client machines to automatically open intranet portals, which are typically hosted on machines with names “intranet”, “portal” or similar.

When a user with such a machine connects to an open wireless network and opens a browser, the browser will first try to resolve such a name via DNS. When that fails, the machine will try to resolve this name via NBNS and this is where an attacker can fake the response and start collecting LM/NT hashes.

Another very nasty scenario includes machines looking for WPAD (Web Proxy Auto-Discovery). By spoofing this request, an attacker can “push” his own machine as the web proxy and the client’s web browser will happily use it, allowing the attacker to analyze network traffic and at least try to launch Man-in-the-Middle attacks (hopefully, we’ve trained our users not to click on certificate warnings, right?).

So, I got in touch with Microsoft and the MSRC guys verified that this is indeed an issue with the firewall. The conversations with the MSRC guys were great and, as you can see, the patch has been released that fixes this vulnerability.

As with other security patches, you should definitely install it as part of your monthly patch install cycles. The whole exercise also shows how one should always test security controls that you put in place – just the fact that you added a rule to block certain network traffic does not have to mean that the traffic is really blocked.

More information and the patch is available at the Microsoft’s web site:

Advisory details at



391 Posts
ISC Handler
May 8th 2012
"just the fact that you added a rule to block certain network traffic does not have to mean that the traffic is really blocked."
Wow. It's scary that it is accepted in the Windows world that that is OK. It's really like saying "Yes, you've saved that file, but you better examine the disk block-by-block to ensure it really is saved.".
The firewall has a job to do, and it it can't do it, why is that considered acceptable?!

Sign Up for Free or Log In to start participating in the conversation!