Slashdot Mirror
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."
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.