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:
2012-01-29 11:07:21 ALLOW UDP 192.168.161.137 192.168.161.255 137 137 0 - - - - - - - SEND
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.
Advisory details at http://www.infigo.hr/en/in_focus/advisories/INFIGO-2012-05-01
May 8th 2012
7 years ago
"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?!
May 9th 2012
7 years ago