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 http://isc.sans.edu/diary.html?storyid=12454 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:

 
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:

 
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 192.168.161.137 192.168.161.255 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: http://technet.microsoft.com/en-us/security/bulletin/ms12-032

Advisory details at http://www.infigo.hr/en/in_focus/advisories/INFIGO-2012-05-01


--
Bojan
INFIGO IS