FTP Vulnerabilities | Maximum Mac OS X Security

As you may already have guessed, FTP's largest vulnerability is essentially the design of the protocol. Having been created in a day when today's constant network security threats simply didn't exist, it wasn't designed with the requisite paranoid mindset to be secure. In fact, so trusting was the nature of its designers that it supports a number of features that allow it to be made explicitly insecure . The security concerns range from vulnerability, to denial-of-service attacks, to the ability to configure it to execute arbitrary system commands for remote users. And these are in addition to the vulnerabilities that are due to bugs in the code. The primary flaws about which you must concern yourself are as follows :

FTP is a cleartext protocol. User IDs and passwords are carried over a cleartext connection, enabling nefarious individuals to snoop your users' names and passwords off the wire. Even if you don't allow remote logins of any form, if your users connect via FTP in an unprotected manner (and it's very difficult to force them to use a protected method ”more on this later in this chapter), they're giving away the information necessary to log in with their ID at the console.
FTP is a two-channel protocol, with "commands" being carried over one network connection and "data" being carried over another. Protecting the command channel isn't too difficult, and doing so protects user IDs and passwords, but because of the design, protecting the data channel is more difficult. Consequently, the data channel is not protected, and the contents of file transfers are seen.
The flexibility designed into the protocol is overly optimistic. The protocol's two-channel design is intended to allow a command channel from machine A to machine B, to invoke a data transfer from machine B to machine C (or vice versa). While conceptually interesting, and quite useful for allowing FTP connections to work from behind firewalls, this flexibility also allows a renegade machine A to access data on machine C from any other machine on the Internet (any machine running an insecure FTP server, that is), even if machine C has explicitly blocked all access from machine A.
The FTP server is frequently run from inetd or xinetd (Chapter 11, "Introduction to Mac OS X Network Services"), requiring a process to be spawned for every incoming connection, whether it's a valid/successful connection or not. You can throttle connections or limit the number of connections to your FTP server by using xinetd rather than inetd , but the design consumes resources for any connection, thereby allowing DoS attacks and inappropriate consumption of resources.
An additional design feature available in some server implementations enables you to configure the server to accept new, site-specific commands. This allows FTP site administrators to put the protocol to flexible uses in very site-specific contexts, but less-than -careful configuration can allow the remote user to execute arbitrary commands with the permissions of the FTP server.
If the server is configured to allow access by users with accounts on the server machine, the server must be configured to initially run as root, so that it can switch user IDs to run as the appropriate valid user after the user is authenticated. Unfortunately, this means that the server must run as root prior to authentication, and that it therefore can be the source of root compromises if bugs are discovered that allow attacks prior to authentication or outside of the authenticated session.

Each of these areas has been the subject of numerous attacks over the years . CERT's database contains over a thousand entries regarding FTP, and CVE lists almost 200 specific FTP vulnerabilities and exposures. For example:

A bug in versions 2.4.1 and earlier of the very popular FTP server wu- ftpd allows the use of a liberally configured SITE EXEC to spawn shells and other system commands, potentially with root privileges (CVE-1999-0080). To find out whether your machine is vulnerable, FTP to your own account, log in, and enter site exec csh -c id . If your machine responds with a line that starts uid=0(root)... , you've just executed a command as root, without the root password, and your ftpd is vulnerable.
As a convenience, many FTP servers provide for data-type conversion between what's actually stored and what the user wishes to retrieve. Most frequently, this allows the retrieval of both compressed and uncompressed versions of files when only one or the other version is actually stored. wu-ftpd 2.4.2 to 2.6.0 have a buffer boundary-checking error in the routine that allows convenience conversions on-server from one data type to another. The overflow allows users to fool the server into executing arbitrary commands rather than the conversion software. To test this exploit (CVE-1999-0997), search the Net for "SUID advisory 001"; currently this can be found at http://packetstormsecurity.nl/advisories/suid/001.txt.
The "Pizza Thief" exploit (CVE-1999-0351), on the other hand, relies on an inherent feature of the FTP design. This attack utilizes the dual-channel nature of FTP to allow the attacker access to the server outside the intended scope of his authenticated FTP session. The attacker can fake a command channel, or break a data channel, and then use an unauthorized client to access the server through the open data channel connection. More information can be found at http://www.kb.cert.org/vuls/id/2558 and http://www.attrition.org/security/advisory/misc/ infowar /iw_sec_01.txt.
More recently (wu-ftpd 2.6.1), the autowu rootkit provides the script kiddie with one-stop root shopping by exploit of the CA-2001-33 (CVE-2001-0550) vulnerabilities, which are a combination of design and buffer bounds-checking problems. For a particularly amusing examination of the exploit (and the skillset of those most likely to use it), see http://www.nardware.co.uk/honeys/honey1/NardHoney1.htm.

None of these specific problems are immediate concerns for your server because Apple provides an FTP server with no published vulnerabilities as of November 2002. The design of FTP, however, lends itself to ongoing problems of a similar nature, as well as to administrator-induced vulnerabilities due to misconfiguration. The best defense against bugs is to keep up with all software updates: We recommend (and cover later in this chapter) installing wu-ftpd as a replacement for what Apple provides because problems with wu-ftpd will be addressed nearly instantly. To protect against design issues, the only defense is to thoroughly understand the options available. Although it's not always possible to create the exact configuration desired, carefully studying the options, how they interact, and how to apply them is the only way to produce an FTP environment with the features that you want without introducing too many problems that you don't.

Top