Abusing Fail2ban misconfiguration to escalate privileges on Linux

Youssef Ichioui
4 min readFeb 11, 2021

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.

System and kernel versions

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.

Fail2ban restarting every minute

Let’s look for enabled services in jail.conf. We find out that the only enabled service is ssh.

ssh configuration in jail.conf

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.

Default service values

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

Changing the actionban variable in 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

Getting reverseshell as root

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.



Youssef Ichioui

I am an IT auditor, and a cyber security engineer. I love information technology, and I would love to give back to the community by writing some fun articles.