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."
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
server address (127.0.0.1) is likely to be a reasonable mitigation.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
I remember I used to use it in the mid 90s, I actually found it quite useful because it is (was?) an unroutable protocol - IIRC it could be set up so that windows shares were available only through NetBIOS and thus only across one local segment. A couple of other admins were pulling their hair out trying to figure out how to keep those shares from being exploited without cutting them off entirely (and making the users very unhappy) and binding them to NetBIOS only seemed to do the trick nicely. Of course we had control of the local segment and the users who needed the shares were all on it - otherwise it wouldnt have been very useful. But it's been ages since I remember using it for anything at all.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
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
Ermm... don't you mean NetBUI ?
leather-dog muksihs
Blog: @muksihs
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.
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
So a new flow in the Netbios protocol, tell me something new.
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.
Love many, trust a few, do harm to none.
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.
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.
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.
Yep. The difference is that you blame Windows and i blame Samba.
"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.
WHAT IS WRONG WITH YOU?
the security for the horse and buggy was compromised by experts who simply offered the horse a carrot. This allowed full access and control to the vehicle. Experts are at a loss to fix this security hole, and are actively encouraging users to upgrade to a newer technology.
"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 with them, it's that occasionally they get it in their mind to be too secure for the legacy boxes, actually occasionally is the wrong word as it has only happened once.... So to say that Windows WON'T work with Kerberos and LDAP is just plain wrong, could the utilities for it be better, yes... and I won't argue that windows has a long way to go. However nor will I say that Samba's efforts are wasted, although from my perspective as I do mostly windows admin it is a little bit ironic, that as far as I can tell their interaction with the Microsoft AD folks has mostly been a help to the MS guy's to make AD more reliable and secure.
Any and all content posted above may be ignored, considered irrelevant, or otherwise dismissed.
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 independently, with equal access for everyone.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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.
Outside of being completely amused by your rantings at others for criticizing your awful posting style, I am highly amused that you have honestly made the absolute worst mistake an IT security professional can make: believing that you have found a solution that someone can't break. I'm glad you think you are clever, and I encourage you to keep a healthy level of confidence. However, your solution isn't exactly flawless, and rather than showing healthy confidence, you're over posting, becoming belligerent toward others, and generally being a prick.
Mod me down for honesty, I won't care.
On the topic of securing your network, everyone alive knows that this is the only way to do it with certainty:
http://www.thirdeyeconcept.com/demotivationals/tec66_demotivational.jpg
Randimal: AT-CG-CG-AT-CG-AT-AT-CG-CG-AT-AT-CG-AT-CG-CG-AT-CG-AT-AT-CG-AT-CG-CG-AT-AT-CG-CG-AT-CG-AT-AT-CG