NetBIOS Design Allows Traffic Redirection 68
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 ?!? (Score:2, Informative)
Setting the Node type to P with a bogus WINS (Score:2)
server address (127.0.0.1) is likely to be a reasonable mitigation.
Any protocol that can be spoofed can suffer. (Score:3, Informative)
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.
Re:Any protocol that can be spoofed can suffer. (Score:4, Informative)
Except I haven't hear of anybody actually using NBP recently, and your machine shouldn't fail over to using zeroconf resolution by default. If you don't ask for an address in a zeroconf domain then your computer shouldn't respond when someone helpfully pipes up "oh, I know where that is!"
I didn't think anyone used netbios anymore either, but it is on by default still, isn't it?
ANY OF THEM ARE FIXABLE, this way... apk (Score:2, Informative)
"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 re
Re: (Score:1, Informative)
As a CS student, I have to fix this for you:
At the end of the day, you can't completely trust what somebody else says unless there is prior knowledge.
Such as a installed certificate/key.
Does anyone use NetBIOS anymore? (Score:3, Interesting)
NetBIOS is routable when run over TCP/IP or IPX (Score:5, Informative)
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.
Re: (Score:2)
Ahh yes that would have been the trick I was remembering. It has been a few years.
Re: (Score:2)
IPX routing is severely limited compared to IP routing, of course. RIP style route distribution, 15 hop limit, etc. I suppose that could have all been fixed if IPX had taken over the world instead of TCP/IP. In some ways IPX is more like IPv6 than IPv4 is. Too bad IPX had to be weighted down with a number of chatty, broadcast heavy higher level protocols. IPX networks got the equivalent of DNS, what, ten years later?
Ermm... don't you mean NetBUI ? (Score:1)
Re: (Score:2)
nooo, congratulations, you've made the exact same mistake that everyone makes. NetBEUI is the equivalent of Ethernet (MAC addresses). NetBIOS is the equivalent of TCP/IP, IPX/SPX etc.
Re: (Score:2)
Not quite. NetBEUI is a transport like TCP/IP or SPX. NetBIOS is an API. Like all APIs, it describes a set of semantics on how the underlying networking protocol behaves and because of that it can be layered on top of any protocol.
RFC 1001/1002 describe how to implement the API semantics required by the NetBIOS API on top of TCP/IP.
Re:Ermm... don't you mean NetBUI ? (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:1, Funny)
"...and all the ones who understand this stuff retired as millionaires quite some time ago, now."
yes, and overpaid way too much, do I think
- yoda
DEAR GOD (Score:1, Insightful)
WHAT IS WRONG WITH YOU?
Re: (Score:2)
NetBIOS is NOT an "API"
Once upon a time, there was a standard INT 5C [cs.vsb.cz] interface that was used by DOS programs to control the the NetBIOS functions built into some LAN adapter cards or other add on NetBIOS software. That no doubt is why the functionality was called "NetBIOS", because it was intended as a networking oriented parallel with the regular ROM BIOS.
"NetBIOS" is an awfully funny name for a network protocol, and of course originally it wasn't a network protocol at all, it was a higher level interfac
Re: (Score:2)
Actually, not even close. You have made a mistake rarely anyone makes. Ethernet is layer 2. TCP/IP and IPX/SPX and NetBEUI is layer 3(even though NetBEUI isn't routable). NetBIOS is a layer 5 up protocol, but really doesn't fit will in the OSI model at all because technically it isn't a network protocol.
And I don't know what the hell everyone is talking about "quit using" NetBIOS or whatever, practically every modern MS application uses it extensively.
This hack falls firmly within the "duh" category. Th
NetBIOS is DNS with enhancements (Score:3, Interesting)
examination of RFC1001 shows that the NetBIOS protocol is actually DNS with enhancements and a few different meanings of some of the bits. there is therefore absolutely no reason why NetBIOS should not have the DNSSEC security system added to it. ... except, that would mean that microsoft had to do some work, on some code that was written well over twenty years ago. so the trouble is that microsoft doesn't actually have anyone left at the company who understands what was written, let alone why it was written.
and neither really does anyone else. incredibly, comparison of NetBIOS to the Mobile IPv6 protocols developed a few years ago showed the *Mobile IPv6* protocols to be severely lacking.
the entire NetBIOS protocol, apart from the obvious lack of security (because it was designed for LAN use) is incredibly far-sighted.
Re: (Score:2)
Nobody should be using NetBIOS any more. Autoconfiguration with IP is more than good enough. Anyone with a crappy $20 router can sit back and let DHCP handle configuration, and we all have TCP/IP. Microsoft has been telling people to blow NetBIOS out their ass for years now, but they provided it for backwards compatibility. There's no way to make it safe while retaining that feature, and there's no reason to make it safer when no one should be using it.
Re: (Score:2)
Well, just try disabling NetBIOS in a large enterprise. See how much stuff breaks...your first big-time IT job just became your last.
Re: (Score:2)
Re: (Score:2)
Protocols requiring authentication just make things more interesting, you can hijack the connection and then steal or man in the middle the authentication details when the client sends them.
Re: (Score:2)
That could have been true had NetBIOS commonly been run over a routable protocol and had NetBIOS name servers supported a recursive name resolution scheme. Most NetBIOS networks in the early days were far from it. If you don't have a routable protocol and a means to configure what address the name server lives on, and you don't have an inter-name server name query resolution protocol, you end up with the much more typical broadcast and election scheme on small networks and perhaps a handful of name servers
Layer 2 Separation (Score:5, Informative)
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 [cisco.com]
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
Re: (Score:2)
Howto configure PVLANs on a Cisco Cat 3750 switch:
Can you tell all the small-time hotel owners out there how to do that with a dlink or netgear device... ;)
I would bet that most of the hotel owners out there aren't the Hilton, Ritz, or Embassy. And possibly even those big guys wouldn't want to spend a butt-load of money on *all* their hotels for pvlan capable switches when a netgear device would work well. Maybe they would for hundred or thousand room hotels in NY, Vegas, etc...but we have one down the road that's ~20 rooms...
Re: (Score:1)
If you are able to hook up all the rooms to a single switch (eg 24 or 48 ports) it's easier! You only need Private Vlan Edge functionality to seperate Layer 2 between rooms. Private VLAN Edge functionality can already be found on the pure Layer2 switches like 2960 or ESW series.
Netbios = epic fail (Score:2)
Once we had a rogue router plugged in the network who was happily changing the DNS setting on the Windows workstations. Nothing else, just DNS settings.
This case alone should give nightmares to any Netbios administrator.
Re: (Score:2)
Re: (Score:2)
Couldn't they just as easily run a DHCP server and do the same thing?
That is, assuming addresses are being set via DHCP.
Samba 3 Domain Controllers and Mutant NT Domains (Score:5, Informative)
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.
Re: (Score:1, Insightful)
Samba is still stuck in NT4 times. That's why everyone should get rid of it. The hacks needed to make it work with Windows 7 alone show the age of the software.
I'm aware that the development to get Samba up to the level of WS08R2 is in the work, but it's nowhere near where Microsoft is right now.
Re: (Score:2)
Were you just not paying attention? I just said Samba had a whole slew of LDAP and Kerberos functionality that Windows won't work with. Most of what I talked about only takes place when two Linux boxen are together.
Re: (Score:2, Insightful)
Yep. The difference is that you blame Windows and i blame Samba.
Re: (Score:1)
"Won't Work With" ....
I'm running Server 2008 with the domain and forest at 2008 level, ALL of my machines are set up to use KerberosV5 and LDAP, the only ones that even occasionally give me trouble about it are some legacy Server 2003 boxes (XP seems to work fine or maybe I'm just deluding myself, which is what I would think too, if I hadn't checked the logs) and the ONLY reason they give me trouble about it is because they were originally connected to an SBS2003 domain. Vista and 7, if I have a problem wi
Re: (Score:2)
You are using Samba in a Client Capacity, not a Domain Control Capacity. Apples and Oranges.
What I was refering to is when Samba 3.x Domain Controllers are all that is present. i.e. no Windows Servers. Windows Clients will not negotiate Kerberos with Samba. They treat Samba like NT4. And if you try to switch on Kerberos Realm mode using k5setup, it disables NT Domain support. The only thing you can do is install MIT KfW.
Re: (Score:3, Insightful)
The problem is that MS implement something, and samba has to play catch up... If samba would implement something first, MS would simply ignore it and do their own thing instead.
Also if MS implements something, they keep it as secret and obfuscated as possible - making it difficult for someone else to reverse engineer and implement, groups like samba openly document what they do making it easy for third parties to create their own implementations.
What we really need are standards which are decided independen
Trivially Preventable (Score:2, Informative)
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 [microsoft.com]
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 [microsoft.com]
Go to the NBT section. Note the entry for
Re: (Score:3, Insightful)
Re: (Score:2)
And people complain that using a commandline on linux is difficult...
well all know what now? (Score:1)
"we all know that untrusted systems on a LAN means game over"
Quick, someone inform the Kerberos team at MIT that their software doesn't work, and never has!
In other news... (Score:4, Insightful)