Priv Escalation
We are part of the fail2ban group. It basically means that if we make a certain amount of attempts to authenticate and we miss it we get banned for a minute.
I looked up Fail2Ban privilege escalation and this came up. It is a write up of this machine so I do feel a little bit bitter sweet. However, if this were to happen in the exam and I am in a position where i look something up and it is what i need in order to pwn a machine it is fair game.
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.
So fail you failed to fail me.
Last updated
