Abusing Fail2ban misconfiguration to escalate privileges on Linux
This is the second part of a two-part article. In the first part, I showed how you can gain access to a Linux system by abusing a misconfigured rsync.
In this part, I will be demonstrating how to abuse misconfiguration in Fail2ban to escalate privileges to root.
Once I get in a system I like to see what kind of operating system it’s, what groups I am a member of, processes running as root, SUIDs, SGIDS, Crons, what services are running on the localhost, plaintext passwords in files, and so on.
In this particular box the system was debian with 4.19.0–12-amd64 kernel and x64 bits architecture.
For time purposes I will go straight to the vulnerable part. Looking at what groups I am a member of, I find out that I am a member of the Fail2ban group that was running as root, also I have writing permissions over the configuration files located in /etc/fail2ban/action.d
The way File2ban works is that you have a configuration file called jail.conf located in /etc/fail2ban, this configuration file has different services and determines whether fail2ban for a specific service is enabled or not, what ban action to take in case of three fail auth attempts(in /etc/fail2ban/action.d), how much time someone will be banned for, etc. In case these variables are not determined for a specific service, fail2ban will take the value of the [default] service. For more details on how fail2ban works, check out this awesome article from digital ocean.
The first instinct that comes to mind is looking for enabled services in jail2conf, and hijack the ban action in action.d folder since we have writing access to it. The problem is, for a configuration file’s modification to take effect, we first have to restart the fail2ban service. Luckily for us this was the case by running pspy we find out that fail2ban was restarting every minute. Also, there was a note confirming that.
Let’s look for enabled services in jail.conf. We find out that the only enabled service is ssh.
However, there’s no variable for ban action nor the ban time, so as explained above ssh will take the values of the default service.
In this capture, we can see that if we make 3 failed login attempts in a 10 minutes interval, we will be banned for 1 minute, and the ban action is determined in iptables-multiport configuration file which is located in action.d folder and we have writing permissions to it.
So the attack scenario will be to change the configuration file of iptables-multiport.conf file in /etc/fail2ban/action.d/ and instead of blocking the IP with iptables we will put our netcat reverse shell. Then, we will wait 1 minute for the fail2ban service to restart, and then make 3 failed login attempts to ssh purposely so that the ban action kicks of and we get the reverse shell.
Let’s start by modifying /etc/fail2ban/action.d/iptables-multiport.conf
Once I did that, I waited one minute for the service to restart and then made 3 ssh failed login attempts and got the reverse shell
we got a reverse shell as root. However, the shell dies after one minute since the policy determines that the ban process will die after exactly one minute as seen above. So, we can copy bash to tmp directory and give it suid permissions to have persistent access.
That was the two-part article, I hope you enjoyed it. If you have any questions or remarks, let me know. Stay safe, take care.
