Remote code execution by fail2ban

In this article we will discuss a recently published vulnerability in quite popular software – fail2ban (CVE-2021-32749). Under the right conditions, this bug could be exploited to achieve code execution with root privileges. Luckily, it is difficult for a “normal” attacker to achieve. This vulnerability is rooted in a way the mail command from the mailutils package works. Furthermore, I have to admit, I figured it out by a total accident!

fail2ban analyzes logs (or other data sources) for brute-force attacks and blocks the source IP addresses if detected. There are a number of rules for specific services (SSH, SMTP, HTTP, etc.). Moreover, there are specific actions performed when an attack is detected – one of them is sending an email to the administrator with a notification that a given IP address has been blocked. If we search the Internet for a way to send an email from the command line, we can often find such a solution:

This is exactly how the action of sending an email to fail2ban is defined – a fragment of the file below ./config/action.d/mail-whois.conf:

There is nothing suspicious about the snippet above that would draw our attention. However, if we look at the mailutils documentation, we can find information about the so-called tilde escape sequences:

The ‘~!’ escape executes specified command and returns you to mail compose mode without altering your message. When used without arguments, it starts your login shell. The ‘~|’ escape pipes the message composed so far through the given shell command and replaces the message with the output the command produced. If the command produced no output, mail assumes that something went wrong and retains the old contents of your message.

Here’s the above in action: 

If we look again at the fail2ban action definitions, we can see that the result of the whois command is attached to the email. If the attacker was able to add a tilde escape sequence as part of the whois response for the IP address of their choice – after sending the email to the administrator, it would end up executing the code – most likely as an administrator (root).

From the attackers’ perspective, what are our options?

The first thing that came to mind was trying to ask my ISP to contact RIPE and just add a specific entry for my IP address 😉 Unfortunately – it doesn’t work that way. RIPE/ARIAN/APNIC and others modify entries for whole classes of IP addresses. Additionally, it is unlikely that anyone would agree to add any suspicious string to the WHOIS response without asking any questions about it.

Then, maybe the option would be to run your own WHOIS server? Surprisingly – it is possible and you can come across several “private” WHOIS servers. All thanks to the mechanism that has been described in more detail in the RFC: namely, if in the WHOIS response we find the ReferralServer attribute, the client will try to connect to the server set as the value of this attribute. An example operation can be seen by verifying the WHOIS response for the IP address 157.5.7.5:

Theoretically, if we were the owners of a large enough network – we could try to ask our Regional Internet Registries to add an appropriate entry. Then, from the level of our own RWhois server, we would be able to freely control the responses sent.

Nevertheless – it is quite easy to imagine a scenario where an attacker / black hat – simply compromises the network or server on which the RWHOIS service is running, and then performs the attack from that network. This seems to be an easier and cheaper task than becoming a large enough company to legally run your own working whois server.

Of course, you can be a government of a large country and simply control that country’s network traffic. If we look closely at the WHOIS protocol, we can notice several things:

• it’s an extremely old protocol (origins date back to 1977)
• very easy to implement (question/answer)
• absolutely unencrypted 😉

Given the above – by carrying out a MITM attack on this unencrypted protocol – the attacker (in this case, the government) could simply insert the appropriate, malicious string in the responses.

What is worth noting is that the problem is not so much with fail2ban itself, but with mailutils – where the mentioned functionality is not a bug, but a planned outcome. Hence, it is worth paying attention to your own, proprietary scripts that use the mail command, and to other software that could also be vulnerable.

History has shown time and time again that security is difficult and complex. Sometimes an innocent, seemingly harmless functionality can turn out to be quite a threat.

Author: Jakub Żoczek