Now what?

Where do we go from here? If administrator-level access is gained the possibilities are endless -- an account cracked during an attack is the same credential needed for remote maintenance and registry editing, to install hacked web pages and DLLs and drivers, modify startup files to run backdoor daemons, or just wreak havoc. Access as a regular user or even guest may permit such games as well. If the NT GUEST login is enabled, on most servers it gets more privileges than needed unless configured otherwise. Even read/write guest access to /tmp on a Samba server may be dangerous if its shell users run any of hundreds of utilities that bounce critical data in and out of /tmp files. This document does not address problems in other services such as FTP and Web since they are exhaustively explored in other documents, but one should still consider the potential effects of concerted attacks on those services *and* SMB together.

Intruders are already scanning routinely across the customer networks of large ISPs, looking for vulnerable home PCs with technically illiterate owners and factory-default setups. The notoriously weak .PWL files are a popular target, and woe betide those who use them to store working passwords for other services. The cable-TV modem systems now coming online function just like bridged ethernets, freely allowing local broadcasts and other shenanigans, which can turn your next door neighbor into an unintentional intruder as his '95 box literally explores its "network neighborhood". If you aren't scared yet, consider this scenario: You spend a day at home doing work via telecommuting. Your company is both frugal and security-aware, and has provided secure connectivity tools that you can use with your regular personal ISP account to access corporate files behind the firewalls. You inadvertantly left filesharing "temporarily" turned on from something you were doing two days ago. While you are happily SSH'ing away, someone breaks into your machine via SMB and without your knowledge, sensitive company files and your personal finance records are stolen, viruses planted, and your secure connection apps compromised. Next time you use your SSH client, it quietly spills its internal beans over the net to a stolen AOL account and within ten minutes your internal corporate network is overrun. Since it appears that your access credentials were involved, YOU may be held accountable. But you didn't do anything, and were always careful with your passwords! A similar scenario could easily occur with corporate laptops used to "get home" from conferences and trade shows, which could still be a problem even if your laptop is reasonably secure but the one belonging to the guy *next* to you is compromised! Think about it...

The rest of this section wanders into a large area of blue-sky loose ends that in large part outlines the limits of the author's current knowledge. Answers to many of these may already be known, and if not then much is certainly left for those with the time and inclination to explore and think over. Anyone is free to send information concerning any of these, as well as the inevitably needed corrections to other parts of this document.

Windows cracking tools are already starting to appear. At least one password- snarfing DLL is in the works for NT, as are security-targeted registry editors and NTFS tools. Daemons to listen on network ports and start backdoor command shells probably exist already, and if nothing else there are shareware "inetd" and telnet-server equivalents available now. Do not ask me where to get these things, because I have no clue. Pointers, on the other hand, are always welcome.

The \PIPE\LANMAN service is only one of several named-pipe services. The remote registry editor starts up a new IPC TCon and opens "\PIPE\winreg" to do its dirty. Another service type seems to be called \MAILSLOT\{various-things} and shows up in browsing-related UDP traffic. Domain logons try to locate services such as \NET\NETLOGON and \NET\GETDC450, mostly via broadcast UDP. There may be many undocumented services and API calls within either class, reminding us that Microsoft historically likes to hide ill-considered or insecure functionality there and count on obscurity to resist attack. There are also the fledgling DCE/RPC services which apparently are intended to phase out named pipes as the recommended transaction backend and clearly present a whole 'nother swamp to explore. If it is running, some part of RPC is reachable via TCP port 135. It seems likely that some of these services can be accessed even if the file/printer sharing checkbox is NOT enabled.

Anyone who runs vanilla SMB over the open Internet is crazy, no matter how good their backend server security is. The protocol runs in the clear, and is thus just as vulnerable to TCP spoofing and hijacking as any other cleartext session. All it takes is one properly constructed SMB packet to make an existing authenticated session do something nasty or blow open a big hole that an attacker can enter through, and it doesn't even matter what the server response is or how the real client handles it -- the damage is done. There are already known man-in-the-middle attacks against the authentication protocol. Various SMB header fields are only 16 bits, and in addition have been observed to be *very* predictable especially from relatively inactive servers. For instance, Samba uses the user's own UID for its SMB UID, and TIDs from a quiet server vary little if at all. NT seems to rather consistently assign 2048 for both initial UIDs and TIDs, and increments by either 1 or 2048 for new connections. This suggests that blind TCP spoofing attacks may nonetheless be effective even if an attacker cannot observe an existing session.

One type of TCP attack involves "desynchronizing" an existing session between two hosts and taking over the connection. As Laurent Joncheray's paper on the subject points out, such an attack is aided by the application protocol in question having some element that sends data through the TCP stream but causes no change in the state of the application itself. An example is telnet options -- a telnet client can send any number of "do echo" commands and the end user would never be the wiser. An attacker uses this type of "null data" to push the TCP sequences out of each endpoint's windows, with the only side effect being an "ack war" between the hosts as they desperately try to resync, and eventually the attacker controls the whole connection. SMB has both an echo and a session keepalive message, and it is likely that these could also be used in a user-undetectable desync attack.

While separate TCP SMB sessions are supposed to be completely isolated from each other, there is always a possibility that a server implementation could "leak" or get them confused somehow. Servers generally run as a single process and manage several client connections internally, but how exactly does a given one internally reference the parameters associated with each? The concept of "UID scanning" has been suggested, and while I personally have my doubts about it there are still other various SMB fields to consider. We should not discount for one moment a server giving too much credence to client-settable header parameters like UID, TID, PID, MID, and maybe even source TCP ports. The twelve filler bytes in TCP SMBs become relevant in connectionless UDP mode for sorting out session IDs, and it would be no surprise at all if the right combination of data there was able to, say, reference an already existing TCP session. Most server platforms seem able to talk concurrently via either transport type.

There may be some magic hidden in the calling client name and/or the username that the client passes in. Special user accounts of the form OTHERDOMAIN$ are used in domain trust relationships, and recent Samba servers that at least partially support domain logins have a small hook to not turn on the "guest" bit for this type of user login. A few remaining bits worth poking at could include weaknesses in the Microsoft IP stack itself, as well as how well various ill-formed service requests are handled. Sending random data to the listening ports of various NT services such as RPC and DNS can apparently cause them to wack out or crash, implying that genuine security holes may lurk there as well. Snowing a site with bogus NMB name-registration and master browser election traffic could have many interesting effects on local workstations. SMB clients must conform with a rather rigid request structure, but what happens if one does not? Well-known vulnerabilities such as buffer overflows and trust of user-modifiable data keep recurring in recent network code under numerous operating systems, and something as large and complex as NT or '95 is undoubtedly no exception.

Besides the oft-belabored network level denial-of-service attacks possible, there is also a potential attack written right into the CIFS spec. It states that if a server receives a new session transport connection from a given client, it MAY assume that a reboot occurred and summarily drop any old existing connections with that client. Precisely what a "client" is in this case is not well-defined, but implies that it is simply based on the claimed client name. Only a lunatic would write a server conformant with this, as it would allow anyone to remotely knock down SMB sessions all day, and sensibly enough, none of the platforms mentioned herein allow this sort of nonsense. Most servers rely on keepalive timeouts and network-level errors to ferret out dead client connections.


It is entirely reasonable to mentally lump CIFS in the same class as NFS, and view the security aspects of both with equal skepticism. It should be fairly evident by now that this stuff is a real danger, and the happy kids in Redmond aren't going to be much help here. To their credit, they have provided a few interesting bricks you can use when building your own walls and some of these are covered in detail in numerous books and FAQs. The transport protocol is also fairly easy to handle with familiar IP-level defense mechanisms, making construction of that "layered defense" more feasible. It is hoped that the preceding bulk of this document has increased understanding how to probe networks for remaining NetBIOS-related weak spots.

Any text or FAQ on Windows or NT security is a good starting point for things to change, particularly on servers. These will detail basics like disabling or removing privileges from GUEST accounts, changing ADMINISTRATOR account names and barring them from network logins, preventing remote registry editing, turning off useless information-leaking services like messaging, reassigning user and group privileges, configuring failed-login lockouts, and dinking ACLs/ownerships on files and registry entries. Servers can be equipped with batch files to invoke "net share ??? /DELETE" and disable unnecessary default fileshares after a reboot. Centralized user management via domain controllers may help mitigate some administrative nightmares, and strong user passwords are a must although often difficult to enforce.

An obvious perimeter defense is packet filter rules in border routers to drop traffic to TCP *and* UDP ports 135 thru 139. This prevents direct NetBIOS and RPC attacks from the outside, but may not block a relayed proxy connection or a curious insider. Policy may dictate that a few filtering "holes" be left open for remote collaborators; such things should be configured as narrowly as possible, perhaps even down to specific host addresses, and policymakers should understand that the data in these allowed connections can be stolen or corrupted. Better would be an encrypting proxy relay or VPN of some sort.

If packet filtering is not an option, as at many policy-impaired sites, there are still several worthwhile measures available that can help make your machines "invisible" from the outside. One is to use a scope ID. These are additional components of computernames that Microsoft incomprehensibly recommends NOT using but provides anyway. The stated purpose is to isolate groups of machines from each other in a more complete way than using different workgroups. Similarly to using an obscure "domainname" under Unix YP, setting all the machines at a site to use a non-obvious scope ID and keeping it a secret within a site effectively provides a "site password." Any NetBIOS traffic, name queries and session setup alike, must contain the exact same case-sensitive scope ID or name responses aren't sent and sessions are rejected. Scopes are by no means a panacea since they can leak out via human vectors, and an astute attacker who observes active listeners on TCP 139 but cannot obtain name info or sessions may conclude that a non-null scope ID is in use and start trying to guess or social engineer for it. The scope is easily viewed by doing "nbtstat -n" on a local console, so beware of wandering outsiders with itchy fingers. If a site's machines are set up with scope IDs by a small core group of maintainers who keep it to themselves, the end users are unlikely to even notice anything different unless they specifically look in the settings or spot them in packet dumps.

Where to set the scope name is often hidden in an obscure place. This is a rough outline of where to find it on various platforms; RTFM for others:

        WFWG [requires restart, and happily craps into various .INI files]:
          run WINSETUP; Network settings / Drivers / MS TCP/IP / Setup /
          Advanced / Scope ID text-box

        WFWG alternate, less frustrating:
          edit SYSTEM.INI and find [NBT] section
          add a line with "ScopeID = XYZ"
          note: can also add "LMHostFile = {path}" here to enable LMHOSTS

        W95 and NT [also requires restart]:
          Control panel / Network / Protocols / TCP/IP / Properties /
          WINS Addresses / Scope ID text-box near bottom

        Samba [takes effect during server run]:
          start "smbd" with "-i XYZ" to set the scope ID
Microsoft clients and servers use the scope ID exactly as given, but Samba always upper-cases it and must be patched if a mixed-case one is to be used. For compatibility, "nmblookup" in the attack kit needs a similar patch, although "smbclient" itself for some reason doesn't mess with the -i argument. It is definitely weird that all the scope-handling hooks are already there in Samba, but not very clearly documented or listed in usage() messages.

Another easy network-level sleaze is to not supply internal servers with a default IP route to the internet, and make sure they ignore ICMP redirects and routing protocols. There is little reason a dedicated local fileserver would ever need to interact with anything offsite, and public services such as web servers should exist on different machines anyway. Packets may still reach such "nonrouted" machines from the outside, but they cannot send back and TCP connection attempts to them simply time out. NT also seems to have some rudimentary concept of its own IP packet filtering, said to offer little versatility but may be worth investigating anyway [and TESTING if configured!] Depending on local policy, end-user machines will probably still need to talk to the internet so employees can waste time surfing; a wise policy is that their machines strictly remain clients and never offer any inbound services. Turning off the file and printer sharing checkboxes is the obvious first step, although Microsoft stacks seem to always listen on the NetBIOS ports regardless of these settings.

The internal protections on server shares are important, on both Microsoft platforms and Samba alike. Placing public shares on separate drive partitions reduces the potential damage from ".." bugs, since Microsoft servers are reasonably good about not letting shares cross filesystem boundaries. If file ACLs and modes are available, USE THEM so that any normal user [or a virus she inadvertantly runs] would never be able to write to, say, directories full of common system utilities. Making entire shares read-only if possible is sound, or if *someone* needs to write to them, separate and closely-held mainenance accounts should only own the files and not have any administrative privileges. While the magic homes Samba feature may be useful in some environments, consider carefully if the arguably free-n-easy way it works may be too lax for yours. A strategy worth considering is building a Samba server with custom getpwent() routines that dig base user entries out of a file other than /etc/passwd, which makes a cracked filesharing password considerably less useful against other daemons on the server machine.

The logging problem is a pain in the butt. Most servers that log anything just save the calling client's name, which is hardly useful since it can be arbitrarily set. Running a separate network monitor on an unswitched DMZ segment and looking for certain inbound traffic is one way to centrally cover a motley assortment of problematic machines. Stock Microsoft platforms simply cannot log client IP addresses at all, a possible albeit lame rationale being that CIFS runs over several different kind of transports and they'd all have to be accomodated somehow. Some kind of batch job to periodically wake up and snapshot a "netstat -a" to a logfile may help detect attacks, or by now there may be some third-party DLLs available that provide better logging and alarms. Samba deals more closely with IP addresses but still makes the administrator jump through hoops to usefully log things. Under the default debug level of 1 only successful non-IPC tree connects are logged. The code also includes an IP-based access control module ripped right out of Wietse Venema's tcp wrappers, and can be set up to deny tree connects from all but known hosts and subnets. The allow/deny access control entries reside in lib/smb.conf, configured globally and/or per share entry, but they only apply to TCons and have no effect on the underlying TCP connection itself. Using them may nevertheless gain some peace of mind; see the documentation for serving suggestions. Supplying an "allow" entry and cranking the debug level up to at least 2 will cause all TCon attempts to be logged, along with a certain quantity of other noise. A small saving grace here is that Samba by default runs in *share* level, so an attack would take the form of repeated TCon attempts and cause lots of logging. This is still not sufficient with user level security. User logins are also logged at debug level 2 but only with the client computername, and one would have to group together many log entries to reconstruct an attack footprint. The best way to deal with Samba would be some minimal changes to the server code, perhaps to getpeername() on the current network socket any time a login *or* TCon is attempted and concisely log success or failure along with the client name *and* IP address. Nmbd could be changed to log status queries at debug level 0 instead of 3, to help warn about UDP name-gathering probes even if the "no default route" sleaze or scopes are in use. Sending security-critical logging to the syslog instead of Samba's default logfiles would bring it more in line with other daemons and maybe cause administrators to pay more attention to it.

Snide comments

Although a primary goal has been to point out weakness in the CIFS protocol and specific implementations, backhanded comments have so far with some difficulty been kept to a minimum. Readers who are easily upset by a certain amount of vendor-bashing or other no-holds-barred dissing are encouraged to skip this section, where we bump up the nasty level. Why? Because it needs to be stated, partially with the hope of getting certain people to WAKE UP. Some of this is certainly conjecture, but guesses made here are reasonably educated.

Experienced Unix people are likely to already understand many of these issues, and know the "been there, done that, fixed the code" feeling. It is sadly evident that many people running all-Microsoft shops are way behind the curve where overall network security is concerned, and still struggling with a lot of the basics. Some sites don't know or care, as long as they can get their electronic ad agencies connected and sell lots of that web-slum real estate with the spiffy pictures and no content. We hear of things like complete trust placed in obscurity measures such as "inside" RAS dialups. Those who are starting to play with firewalls often pull such classic stunts as connecting one in parallel with a regular router and relying on default routing entries on individual hosts to send traffic to the firewall first. Blocking relevant IP traffic is often met with managerial resistance or confusion. Standard IP-level attacks work against such sites because most of them do not really understand TCP/IP, and do not have any useful network monitoring gear available. Unix is just foreign and scary, particularly to these so-called experts who are now popping out of the woodwork and mindlessly repeating that laughable lie about NT's C2 rating. These same people will tell you how no-brainer bugs like ".." and wide-open registry permissions are new and hot, but fall right over when asked about crypto algorithms or wire-level packet structure. Try mentioning how NetBIOS is just a load of CACA to such an expert, and expect a blank look in return.

(prev page - top - next page)

Log in or register to write something here or to contact authors.