Home > Articles > Security > Network Security

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.2Figure 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.3Figure 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 

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020