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.
Defenses
========
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)