OSCP Practice: Insecure Configuration Rsync

High Level Summary

This machine provided a small attack surface with only two open ports. SSH and Rsync (Ports 22 and 873) were open. Enumeration of the Rsync service identified, that it was not restricted to specific remote hosts, nor was it using a secrets file for password protection.

With access to the Rsync service, we were able to review contents of a user home directory. Testing showed, that we also had write access to the home directory. With write access available, an SSH public key was uploaded to the user “/.ssh/authorized_keys" file. Once this file was in place, it was possible to use SSH to gain access as the user.

The server had a well known vulnerability with fail2ban software. The user we could access was a member of the fail2ban group, and could write to the service configuration files. This allowed us to modify the actions taken, when a host is blocked from SSH access to provide a callback to our attacker box.

The callback provides root level privileges.

Recommendations

• The Rsync service can be set up with both IP Address restrictions, and this should be done at a minimum.
• Additionally, the service can be protected with a secrets file for password like protection.
• Implementing either of these would have prevented our initial access and compromise of the system.

Initial NMAP Scan

Enumeration of Rsync

Starting out, NMAP was used to to run a script and identify Rsync modules.

We can then use Rsync to see what is available.

Initial Access

Not shown here, a SSH key pair was generated for uploading to the remote system. We then used Rsync to upload the file to the remote system. Note that we created a sub-direction “/.ssh”, and placed the public key in this as the file authorized_keys.

After uploading the file, we were able to log in using the private key we created.

Escalation of Privilege with fail2ban

The user had membership to the fail2ban group, and knowing that this application has a known escalation exploit, we took a look at the configuration file permissions.

As a group member, we see that we had read/write access to the iptables-multiport.conf file.

With that access we can implement a new action to take place when a host is banned from access.

Here, a nc reverse shell is inserted into the actionban section.

To get ourselves banned, we just launched an attack from our box with hydra, while having a nc listener waiting for a callback.

When the ban action kicked in, we received our callback as root.