NetBIOS Design Allows Traffic Redirection
iago-vL writes "Security researchers at SkullSecurity have demonstrated how the NetBIOS protocol allows trivial hijacking due to its design, through the use of a tool called 'nbpoison' (in the package 'nbtool'). If a DNS lookup fails on Windows, the operating system will broadcast a NetBIOS lookup request that anybody can respond to. One vector of attack is against business workstations on an untrusted network, like a hotel; all DNS requests for internal resources can be redirected (Exchange, proxy, WPAD, etc). Other attack vectors are discussed in a related blog post. Although similar attacks exist against DHCP, ARP and many other LAN-based protocols, we all know that untrusted systems on a LAN means game over. NetBIOS poisoning is much quieter and less likely to break other things."
Disable NetBIOS via DHCP and/or GPO ?!?
leather-dog muksihs
Blog: @muksihs
Appletalk Name Binding Protocol (NBP) is also likely to be vulernable, as is Novell's Service Advertising Protocol (SAP), was well as Multicast DNS (sort-of-aka Avahi, Zeroconf, Bonjour). At the end of the day, you can't completely trust what somebody else says unless you already explicitly trust them.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
as per RFCs 1001 and 1002 for TCP/IP and somewhere else for IPX (IPX packet type 20 IIRC). However, if you ran it over "NetBEUI" or NetBIOS Extended User Interface, rather than IPX or TCP/IP, NetBIOS was running directly over 802.2/LLC i.e. no layer 3 protocol in there, so no routing. I think Microsoft removed this option a number of years ago, which is a shame, because that was a way of ensuring that there was no chance your NetBIOS file and print shares were accessible over the Internet.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
This attack would easily be prevented by the use of Private VLANs on your network. With PVLANs Clients connected to the LAN can only send Layer 2 frames to the default gateway and other pre-defined shared services such as printing, ad, mail, internet... Typically Private VLANs are very handy in shared/public environments such as hotels, public desktops.
Howto configure PVLANs on a Cisco Cat 3750 switch:
http://www.cisco.com/en/US/tech/tk389/tk814/technologies_configuration_example09186a008017acad.shtml
Many other techniques are available to protect a L2 LAN environemnt:
* DHCP snooping (DHCP trusted/untrusted ports)
* Dynamic ARP inspection
* IP Source Guard
* Port security (stickies) and MAC acls
The fact is as long as Samba 3.x exists we will have NetBios. There are alot of Samba 3.x Domain Controllers that manage "Mutant" NT Domains. What I mean is this. The optimal situation for Linux Samba Domain Controllers is this:
You have an OpenLDAP, Kerberos, and Samba. OpenLDAP is the directory service, Heimdal Kerberos is Single Sign on, and Samba is Legacy NT Domain Compatibility and CIFS File sharing. Between two Linux machines, Samba can DNS to look up shares, and use Kerberos to authenticate to shares. This is all well and good. It is very secure, it doesn't use NTLM or NetBios. In the event of a Windows machine accessing a Share, The Windows machine can use DNS to lookup a share, but can't use Kerberos. It has to use NTLM, because in "NT Domain Mode" everything from 2000 on disables Kerberos and you can't turn it back on without the third party MIT Kerberos for Windows Client. (which most people won't do.)
Now, the problem comes when Windows machines try and log in to a Samba Domain. This is where things get a little weird.
Samba backended with LDAP can have multiple PDCs because OpenLDAP has multi-master support. Samba is not limited to PDCs and BDCs the way NT4 is. You can have multiple layers of Trusting Domains, and all of your Domain Controllers being writable PDCs. in fact, the only real difference between Active Directory and "Open Directory" is: Windows Won't negotiate with it.
(this also applies to Kerberos. Multimaster Kerberos KDC is possible only with OpenLDAP support but thats outside the scope of this discussion.)
Because of this, you can haave multiple PDCs, and multiple NetBios scopes. This is important, because Windows clients always broadcast for their Domain Controller. Unlike with Active Directory, (and other Linux Clients) which uses SRV records to find the Directory services using DNS, Windows clients always broadcast and have a "Browser Election" to find out who the PDC is.
This means that Windows' Boneheadedness about not wanting to talk to anything that is not a "Pure AD" is the problem here.
you're talking to the person who implemented samba's 2nd nmbd improvements, back in 1996, and demonstrated the world's first multi-workgroup / multi-PDC server on microsoft's campus, in about 1998.
NetBIOS is NOT an "API". or - it is, but only in the sense that most early implementations were user-space (in the same way that WINSOCK.DLL was userspace), and RFC 1001/1002 showed how to _proxy_ what is effectively its own transport (equivalent to TCP/IP) and naming service (equivalent to DNS) over other transports at the same ISO layer.
it's very unfortunate and particularly sad that the robustness of the NetBIOS naming / registration service (in the face of absolute ignorance and total misconfiguration) is not respected, studied, improved and modernised.
it's also rather unfortunate that the "scope" field, which was what the DNS "zone" field was renamed as, was not respected by early windows implementations. this _could_ have been re-used for its original purpose: the DNS "zone". in this way, NetBIOS _could_ have been extended out onto the Internet, could have been extended with DNSSEC, and thus turned into something very very useful and very exciting.
but - as i mentioned in an earlier post, we're relying on microsoft engineers to implement it, and all the ones who understand this stuff retired as millionaires quite some time ago, now.
"Appletalk Name Binding Protocol (NBP) is also likely to be vulernable, as is Novell's Service Advertising Protocol (SAP), was well as Multicast DNS (sort-of-aka Avahi, Zeroconf, Bonjour). At the end of the day, you can't completely trust what somebody else says unless you already explicitly trust them." - by anti-NAT (709310) on Saturday December 26, @05:47AM (#30555096) Homepage
Here is a VERY OLD 'something' that can fix this problem in BOTH NetBIOS and yes, DNS itself, in the meantime - for the end user: A CUSTOM HOSTS FILE!
Specifically, the "DOMAINNAME/HOSTNAME-to-IP ADDRESS" equation in them, & "hardcoding" it there (so you do NOT get "misdirected" by an attacker of DNS or NetBIOS). That's fairly DEEP into this post, so, if you are interested? Read on:
I use a custom HOSTS file, in addition to the tools others here in this thread have noted (which MANY like FF addons only really function for FireFox/Mozilla products, but don't extend globally to all other webbound applications, & that is part of what HOSTS files give you above the methods you extoll + utilize: "GLOBAL COVERAGE", & of ALL webbound apps, not just FireFox/Mozilla ones via the addons you most likely use yourself...).
HOSTS files can be used to blockout KNOWN "bad" adserves, maliciously coded sites or adbanners, and "botnet C&C servers" too!
You can obtain reliable HOSTS files from reputable lists for more security online, but also for speed!
(More on that later & WHY/HOW (I use reliable lists for that, such as these HOSTS @ Wikipedia.com -> http://en.wikipedia.org/wiki/Hosts_file or those from mvps.org (a good one this one))
I also further populate & keep current my custom HOSTS file with up to date information in regards to all of those threats, via:
----
A.) Spybot "Search & Destroy" updates (populates HOSTS and browser block lists)
B.) Sites like ZDNet's Mr. Dancho Danchev's blog -> http://ddanchev.blogspot.com/
C.) Sites like FireEye -> http://blog.fireeye.com/
D.) SRI -> http://mtc.sri.com/
----
My HOSTS file incorporates ALL of the entries from the HOSTS files shown @ wikipedia as well... gaining me speed online (by blocking adbanners, which have been compromised many times the past few years now by malscripted exploits (examples below)).
(I combined ALL reputable HOSTS files with one of my own (30,000 entries), & I removed duplicates removed via a Borland Delphi app I wrote to do so called "APK HOSTS File Grinder 4.0++". That program also functions to change the default larger & SLOWER 127.0.0.1 blocking 'loopback adapter' IP address to either 0.0.0.0 (for VISTA/Windows Server 2008/Windows 7, smaller & thus faster than 127.0.0.1 default) or the smallest & fastest 0 "blocking 'IP ADDRESS'" (for Windows 2000/XP/Server 2003 which can STILL use it (& it was added in a service pack on Windows 2000, only on 12/09/2008 MS patch tuesday was it removed for VISTA onwards (& now all these "phunny little bugs" are showing up as FLAWS in this new NDIS6 approach via WFP as well in the firewall, which ROOTKIT.COM has stated (with code too no less on how it is done) -> http://www.rootkit.com/newsread.php?newsid=952 [rootkit.com] [rootkit.com] that it is EASIER TO UNHOOK (than was the design used in Windows 2000/XP/Server 2003))
Another EXCELLENT benefit of HOSTS file usage? More speed online, & also more security + reliability (especially in the case of DNS servers today, per folks like Dan Kaminsky &/or Moxie Marlinspike finding various security vulnerabilities in them the past couple years now)...
SO, to "CIRCUMVENT" THAT WHICH YOU NOTE & to get more speed online (besides/above potentially h
The registry tweaks to prevent any Windows operating system from broadcasting for NB queries has been around for a very long time. (as in, since at least Windows 95)
It is entirely possible to change the behavior to WINS/Unicast only, or turn it off entirely.
Enlightenment is only a click away: http://support.microsoft.com/kb/160177
What you want is to make your host a "P Node".
If you don't want to do that, you can always go here: http://support.microsoft.com/kb/314053
Go to the NBT section. Note the entry for BcastNameQueryCount , change it to zero.
If you do this as part of your corporate build strategy, you could even isolate rogue "Windows" hosts by noting -any- nbquery broadcasts and shutting down those ports a rogues on your client VLANs.