This chapter is from the book
This chapter is from the book
This chapter is from the book
3.4 File Transfer Protocols
3.4.1 TFTP
The Trivial File Transfer Protocol (TFTP) is a simple UDP-based file transfer mechanism [Sollins, 1992]. It has no authentication in the protocol. It is often used to boot routers, diskless workstations, and X11 terminals.
A properly configured TFTP daemon restricts file transfers to one or two directories, typically /usr/local/bootand the X11 font library. In the old days, most manufacturers released their software with TFTP accesses unrestricted. This made a hacker's job easy:
$ tftp target.cs.boofhead.edu tftp> get /etc/passwd /tmp/passwd Received 1205 bytes in 0.5 seconds tftp> quit $ crack </tmp/passwd 0.5 seconds tftp> quit $ crack </tmp/passwd
This is
too easy. Given a typical dictionary password hit rate of about 25%, this machine
and its trusted mates are goners. We recommend that no machine run TFTP unless
it really needs to. If it does, make sure it is configured correctly, to deliver
only the proper files, and only to the proper clients.
Far too may routers (especially low-end ones) use TFTP to load either executable images or configuration files. The latter is especially risky, not so much because a sophisticated hacker could generate a bogus file (in general, that would be quite difficult), but because configuration files often contain passwords. A TFTP daemon used to supply such files should be set up so that only the router can talk to it. (On occasion, we have noticed that our gateway router—owned and operated by our Internet service provider—has tried to boot via broadcast TFTP on our LAN. If we had been so inclined, we could have changed its configuration, and that of any other routers of theirs that used the same passwords. Fortunately, we're honest, right?)
3.4.2 FTP
The File Transfer Protocol (FTP) [Postel and Reynolds, 1985] supports the transmission and character set translation of text and binary files. In a typical session (see Figure 3.2), the user's ftp command opens a control channel to the target machine. Various commands and responses are sent over this channel. The server's responses include a three-digit return code at the beginning of each line.
)
Figure 3.2: A sample FTP session using the PORT command. The lines
starting with ---> show the commands that are actually sent over the wire;
responses are preceded by a three-digit code.
A second data channel is opened for a file transfer or the listing from a directory command. The FTP protocol specification suggests that a single channel be created and kept open for all data transfers during the session. In practice, real-world FTP implementations open a new channel for each file transferred.
The data channel can be opened from the server to the client, or the client to the server. This choice can have important security implications, discussed below. In the older server-to-client connection, the client listens on a random port number and informs the server of this via the PORT command. In turn, the server makes the data connection by calling the given port, usually from port 20. By default, the client uses the same port number that is used for the control channel. However, due to one of the more obscure properties of TCP (the TIMEWAITstate, for the knowledgeably curious), a different port number must be used each time.
The data channel can be opened from the client to the server—in the same direction as the original control connection. The client sends the PASVcommand to the server [Bellovin, 1994]. The server listens on a random port and informs the client of the port selection in the response to the PASVcommand. (The intent of this feature was to support third-party transfers—a clever FTP client could talk to two servers simultaneously, have one do a passive open request, and the other talk to that machine and port, rather than the client's—but we can use this feature for our own ends.)
The vast majority of the FTP servers on the Internet now support the PASVcommand. Most FTP clients have been modified to use it (it's an easy modification: about ten lines of code), and all the major browsers support it, though it needs to be enabled explicitly on some versions of Internet Explorer. The reason is because the old PORT command's method of reversing the call made security policy a lot more difficult, adding complications to firewall design and safety. It is easy, and often reasonable, to have a firewall policy that allows outgoing TCP connections, but no incoming connections. If FTP uses PASV, no change is needed to this policy. If PORT is supported, we need a mechanism to permit these incoming calls.
A Java applet impersonating an FTP client can do nasty things here [Martin et al., 1997]. Suppose, for example, that the attacker wishes to connect to the telnet port on a machine behind a firewall. When someone on the victim's site runs that applet, it open an FTP connection back to the originating site, in proper obedience to the Java security model. It then sends a PORT command specifying port 23—telnet—on the target host. The firewall obediently opens up that port.
For many years we unilaterally stopped supporting the PORTcommand through our firewall. Most users did not notice the change. A few, who were running old PC or Macintosh versions of FTP, could no longer use FTP outside the company. They must make their transfers in two stages (to a PASV-equipped internal host, and then to their PC), or use a Web browser on their PC. Aside from occasional confusion, this did not cause problems. If you don't want to go this far, make sure that your firewall will not open privileged or otherwise sensitive ports. Also ensure that the address specified on PORTcommands is that of the originating machine.
The problem with PORTis not just the difficulty of handling incoming calls through the fire-wall. There's a more serious issue: the FTP Bounce attack (CERT Advisory CA-1997-27, Decem-ber 10, 1997). There are a number of things the attacker can do here; they all rely on the fact that the attacker can tell some other machine to open a connection to an arbitrary port on an arbitrary machine. In fact, the attacker can even supply input lines for some other protocol. Details of the exploits are available on the Net.
By default, FTP transfers are in ASCII mode. Before sending or receiving a file that has nonprintable ASCII characters arranged in (system-dependent) lines, both sides must enter image (also known as binary) mode via a TYPE Icommand. In the example shown earlier, at startup time the client program asks the server if it, too, is a UNIX system; if so, the TYPE Icommand is generated automatically. (The failure to switch into binary mode when using FTP used to be a source of a lot of Internet traffic when FTP was run by hand: binary files got transferred twice, first with inappropriate character translation, and then without. Now browsers tend to do the right thing automatically.) Though PASVis preferable, it appears that the PORT command is making a comeback. Most firewalls support it, and it is the default behavior of new Microsoft software.
Anonymous FTP is a major program and data distribution mechanism. Sites that so wish can configure their FTP servers to allow outsiders to retrieve files from a restricted area of the system without prearrangement or authorization. By convention, users log in with the name anonymous to use this service. Some sites request that the user's real electronic mail address be used as the password, a request more honored in the breach; however, some FTP servers are attempting to enforce the rule. Many servers insist on obtaining a reverse-lookup of the caller's IP address, and will deny service if a name is not forthcoming.
Both FTP and the programs that implement it have been a real problem for Internet gatekeepers. Here is a partial list of complaints:
The service, running unimpeded, can drain a company of its vital files in short order.
Anonymous FTP requires access by users to feed it new files.
This access can rely on passwords, which are easily sniffed or guessed.
The ftpd daemon runs as root initially because it normally processes a login to some account, including the password processing. Worse yet, it cannot shed its privileged identity after login; some of the fine points of the protocol require that it be able to bind connection endpoints to port 20, which is in the "privileged" range.
Historically, there have been several bugs in the daemon, which have opened disastrous security holes.
World-writable directories in anonymous FTP services are often used to store and distribute warez (stolen copyrighted software) or other illicit data.
On the other hand, anonymous FTP has become an important standard on the Internet for publishing software, papers, pictures, and so on. Many sites need to have a publicly accessible anonymous FTP repository somewhere. Though these uses have been largely supplanted by the Web, FTP is still the best way to support file uploads. There is no doubt that anonymous FTP is a valuable service, but a fair amount of care must be exercised in administering it.
The first
and most important rule is that no file or directory in the anonymous FTP area
be writable or owned by the ftp login, because anonymous FTP runs with
that user-id.
Consider the following attack: Write a file named .rhoststo ftp's home directory. Then use that file to authorize an rsh connection as ftp to the target machine. If the ftp directory is not writable but is owned by ftp, caution is still indicated: Some servers allow the remote client to change file permissions. (The existence of permission-changing commands in an anonymous server is a misfeature in any event. If possible, we strongly recommend that you delete any such code. Unidentified guests have no business setting any sort of security policy.) The next rule is to avoid leaving a real /etc/passwdfile in the anonymous FTP area.
A real
/etc/passwdfile is a valuable find for an attacker. If your utilities won't
choke, delete the file altogether; if you must create one, make it a dummy file,
with no real accounts or (especially) hashed passwords.
Ours is shown in Figure 3.3. (Our fake passwdfile has a set of apparently guessable passwords. They resolve to "why are you wasting your time?" Some hackers have even tried to use those passwords to log in. We once received a call from our corporate security folks. They very somberly announced that the root password for our gateway machines had found its way to a hacker's bulletin board they were watching. With some concern, we asked what the password was. Their answer: why.) Whether or not one should create a publicly writable directory for incoming files is quite controversial. Although such a directory is an undoubted convenience, denizens of the Internet demimonde have found ways to abuse them. You may find that your machine has become a repository for pirated software ("warez") or digital erotica. This repository may be permanent or transitory; in the latter case, individuals desiring anonymity from one another use your machine as an electronic interchange track. One deposits the desired files and informs the other of their location; the second picks them up and deletes them. (Resist the temptation to infect pirated software with viruses. Such actions are not ethical. However, after paying due regard to copyright law, it is proper to replace such programs with versions that print out homilies on theft, and to replace the images with pictures of convicted politicians or CEOs.)
)
Figure 3.3: The bogus /etc/passwdfile in our old anonymous FTP area.
Our users occasionally need to import a file from a colleague in the outside world. Our anonymous FTP server1 is read-only. Outsiders can leave their files in their outgoing FTP directory, or e-mail the file. (Our e-mail permits transfers of many megabytes.) If the file is proprietary, encrypt it with something like PGP.
If you must have a writable directory, use an FTP server that understands the notions of "inside" and "outside." Files created by an outsider should be tagged so that they are not readable by other outsiders. Alternatively, create a directory with search (x) but not read (r) permission, and create oddly named writable directories underneath it. Authorized senders—those who have been informed that they should send to /private/32-frobozz#$—can deposit files in there, for your users to retrieve at their leisure.
Note that the Bad Guys can still arrange to store their files on your host. They can create a new subdirectory under your unsearchable one with a known name, and publish that path. The defense, of course, is to ensure that only insiders can create such directories.
There are better ways to feed an FTP directory than making directories writable. We like to use rsync running over ssh.
A final caution is to regard anything in the FTP area as potentially contaminated. This is especially true with respect to executable commands there, notably the copy of ls that many servers require. To guard your site against changes to this command, make it executable by the group that ftp is in, but not by ordinary users of your machine. (This is a defense against compromise of the FTP area itself. The question of whether or not you should trust files imported from the outside—you probably shouldn't—is a separate one.)
3.4.3 SMB Protocol
The Server Message Block (SMB) protocols have been used by Microsoft and IBM PC operating systems since the mid-1980s. The protocols have evolved slowly, and now appear to be drifting toward the Common Internet File System (CIFS), a new open file-sharing protocol promoted by Microsoft. SMB is transported on various network services; these days, TCP/IP-based mechanisms are the most interesting [NetBIOS Working Group in the Defense Advanced Research Projects Agency et al., 1987a, 1987b].
These services are used whenever a Microsoft Windows system shares its files and printers. The most common security error is sharing file systems with no authentication at all. Programs are available (such as nbaudit) that scan for active ports in the range 135–139, and sometimes port 445, and extract system and file access information. Open file systems can be raided for secrets, or have viruses written to them (CERT Incident Note IN-2000-02). NetBIOS commands can be used for denial-of-service attacks (CERT Vulnerability Note VU#32650 - DOS). It is difficult to judge if there are fundamental bugs in the way Microsoft servers implement these services.
For UNIX systems, these protocols are supported by the popular package samba (see http://www.samba.org/.). Alas, this full-featured package is too complex for our tastes. We show how to put it in a jail in Section 8.10.
The various NetBIOS TCP ports should be accessible only to the community that needs access. It is asking for trouble to give the public access to them. These days, even Windows will caution you about the dangers.
Still not persuaded? Consider a new spamming technique based on services running on these ports—it pops up windows and delivers ads. You can test it yourself; from a Windows command prompt, type
net send WINSname 'your message here'
or, from UNIX systems with Samba installed, type
smbclient -M WINSname your message here ˆD