Port: TCP 2121
Service: ProFTPD 1.3.1

Vulnerability: Weak password policy. Lack of user account lockout after failed login attempts.

Mitigation: Require users to select strong passwords. Enforce account lockout policy for failed login attempts.

Proof of Concept
1. The victim’s machine is running ProFTP version 1.3.1 on port 2121. The first thing to try is to see if anonymous logins are enabled by entering the following in the terminal:


It appears that we can’t login anonymously, so we’ll see if we can brute force to get usernames and passwords. There is an auxiliary module in Metasploit which will automate this process for us.

2. Open a terminal, and launch Metasploit. Once it’s opened, do a search for “ftp_login”.


3. Now set Metasploit to use this module, and show the options available:


I already have the options set here – RHOSTS, PASS_FILE, RPORT, and USER_FILE. I chose to use the unix based wordlists available in the Metasploit directory shown above, but there are several others you could select.

4. The next thing to do is to run the module, and see if it gathers any username/password combinations. For simplicity, I’ve cropped out the majority of failed login attempts, and focused on the ones recovered.


Notice we have 3 accounts here, each with read/write access.

  • postgres:postgres
  • service:service
  • user:user

5. I’m going to use the “user” account, and see if that will let me login:


6. If we type in the “ls” command, we can see files that are available to this user:


7. Of interest is the “.bash_history” file. This file may contain other information that could help us further compromise the victim machine. We can use the “GET” command to copy this file to our Kali machine, then view the contents.


8. Once the file is copied, we can view its contents by using the “cat” command.


9. From this file, we see that an SSH key was created with this account, and added to another user’s (msfadmin) authorized_keys file. Let’s see if we’re able to SSH in with the “user” account:


10. This was successful, but we are running with limited permissions. This account does not have the ability to view the “/etc/shadow” file, but we can view “/etc/passwd”, and find out what other accounts may be available. Here is a snippet of the “passwd” file:


11. From the “/etc/passwd” file, we do see other accounts, with “msfadmin” being one. Since the accounts we gathered from brute-forcing the FTP login had weak passwords, we will see if this account follows suit. Let’s see if we can SSH in as “msfadmin”, and if so, see if it has a higher level of permissions than the “user” account.


12. Success! This account is also using the same weak password logic as the other accounts. Now, this account itself isn’t running as root, but we can see if it is part of the sudoers group, and see if we can now read the “/etc/shadow” file.


If we look at “/etc/sudoers”, we can see that the group “admin” has been given rights to use sudo, and the “msfadmin” account is a member of the “admin” group. With this access level, we could continue to enumerate the victim’s machine, looking for configuration files, or other data that may be sensitive.