Linux

Walkthrough of a Linux machine exploitation attacking a CMS Remote File Inclusion vulnerability topping up with tar wildcard privilege escalation.

Deploying and compromising the vulnerable machine

As usual we start with an Nmap scan.

We have a couple of ports to start with, 22, 80, 110, 139, 143, 445. Let us start with the SMB first as the scan reveals that the message signing is disabled which is always a good sign from an attacker perspective.

SMB enumeration

A quick look into the Enum4Linux and a TCP port 139 SMB specific Nmap scan results shows that anonymous access is also allowed.

So, let’s try that out real quick downloading the interesting text file by Mr. Miles which asks the users to change their passwords.

Let’s dig a bit deeper and check the log files in the logs directory as well hoping to see something related to the password change.  There are some potential password variations in the logs.

HTTP enumeration

First of all we need to analyse the file structure of the site. Numerous tools are available for this but we choose Gobuster for now. There are a couple of interesting folders to look into, for example “squirrelmail”

Let’s navigate to the URL and we can see that there is a login page of the mail service.

Let us try a dictionary attack with Hydra on the milesdyson account with the earlier obtained wordlist.

What is Miles password for his emails?

It not only works, but we also manage to find his SMB password.

Login into his SMB account we manage to find his notes in which amongst many important ones an interesting one.

Back to SMB

What is the hidden directory?

Let’s check whether it exists..

Cuppa CMS RFI exploit

We shall do some further fuzzing to check whether something else hidden is under that directory.

Let’s check the admin page found.

Having not much to go on now but to find potential vulnerabilities we check searchsploit.

The description of the exploit says that the /etc/passwd file can be accessed with the [http://TARGET/TARGET/TARGET/alerts/alertConfigField.php?urlConfig=../../../../../../../../../etc/passwd ] payload template on websites built with Cuppa CMS.

And it works..

So, this is the LFI vulnerability on the site, but how would we tweak it to RFI. The answer is not too difficult, all we need to do is to map the vulnerable [/alerts/alertConfigField.php] part to a crafted reverse-shell payload instead of the local [etc/passwd] file. First let’s search for a PHP reverse shell payload on Kali then copy that to our working directory.

Then change the IP-address to yours and if needed the port number as well.

Then let’s spin up our HTTP server from the working directory and also a Netcat listener on the same port which we have in the reverse-shell payload. Let’s also change the target path of the PHP code injection from local to remote pointing to our attacker machine.

Upon inserting and running the tainted link in the browsers address bar first our PHP reverse-shell file gets uploaded to the victim computer and it gets injected into the Cuppa CMS PHP code resulting a reverse shell on our Netcat listener.

Privilege Escalation

Let’s spawn an interactive shell with the python pty import script. After this we should elevate our privileges. This could be achieved by exploiting a cron backup rutin against the tar command-line tool being run as root with the aim of compressing the entire [/var/www/html] folder and saving it to miles’ home directory. We might use a wildcard injection against this tool by forcing it to change 2 checkpoint options and malforming the execution to our needs. First let’s create a bash script to add our current “www-data” user to sudoers then let’s create two checkpoint files which will serve as arguments for the tar utility. A more elaborate explanation can be found on the GTFOBins site. After waiting a couple of minutes and entering “sudo su” we should get an elevated root shell back.

What is the user flag?

What is the root flag?

Thanks for reading and as always, any feedback is most welcome.

Walkthrough of a Linux machine exploitation attacking SQL database, cracking some credentials and gaining root privileges with Metasploit payload.

Deploying the vulnerable machine

What is the name of the large cartoon avatar holding a sniper on the forum?

Obtain access via SQLi

The Nmap scan shows 2 services, SSH and HTTP but not much additional information.

There is an SQL database underneath to abuse via the login page. Our input is put into the SELECT * FROM users WHERE username = :username AND password := password query in the backend. If we put ‘ or 1=1 — – into the user field that authenticates the session as 1=1 is always true, it returns all of the values.

This allows us to bypass the login page.

What page are we get redirected to?

Using SQLMap

First of all we need to intercept a request via this search feature of the site using BurpSuite. 

After catching and saving the whole POST request into a text file we could pass it to SQLMap to use our authenticated user session.

In the users table, what is the hashed password?

What was the username associated with the hashed password?

What was the other table name?

Cracking a password with JohnTheRipper

What is the de-hashed password?

What is the user flag?

Exposing services with reverse SSH tunnels

First of all we have to do some internal enumeration dumping the traffic flowing through the sockets with the tool Ss which is basically a replacement for the Netstat command.

Tcp 10000 is open but blocked by a firewall rule as there was no sign of it during the initial Nmap scan. In a situation like this we can circumvent the block with port forwarding. Local SSH tunneling makes it possible to forward the port from a remote machine back to the local machine.

This means that the same Nmap scan now is able to detect the port and service of the machine via 127.0.0.1.

This can also be confirmed in our webbrowser.

What is the name of the exposed CMS?

What is the CMS version?

Privilege Escalation with Metasploit

Looking for potential exploits we have got a couple Metasploit ones.

Two important things to keep in mind with the tunneling, first of all the SSH port forwarding must be alive during the Metasploit exploit and the second thing is a consequence of this namely that the RHOST will be the local machine, not the victim in the lab.

Thanks for reading and as always, any feedback is most welcome.

Walkthrough of exploiting a Linux machine via Samba shares and a vulnerable version of a proftpd FTP server. Privileges escalation with path variable manipulation afterwards.

Deploy the vulnerable machine

We shall do a quick Nmap scan at first right after spinning up the VM.

How many ports are open?

Enumerating Samba for shares

Samba is a suite of apps using the SMB (Server Message Block) protocol. In the everyday life is mostly about the Windows – Unix communication, file access, printing, shared resources etc. We shall run a dedicated Nmap script against the machine for further enumeration. SMB has generally two open ports, 139 and 445. Port 139 is for communication over NetBIOS on the application layer. Port 445 is utilized by the newer version of SMB (after Windows 2000) and it allows SMB to communicate over the Internet.

Using the nmap command above, how many shares have been found?

Let us connect to the shares with the smbclient tool.

What is the file we can see?

The file can be downloaded with the “get” command. Let’s open the file with the “cat” command. It contains interesting information like:

  • Information generated for Kenobi when generating an SSH key for the user
  • Information about the ProFTPD server.

What port is FTP running on?

Our earlier Nmap port scan showed port 111 running the service rpcbind. This is just a server that converts remote procedure call (RPC) program number into universal addresses. It basically tells rpcbind the address at which it is listening and the RPC program number its prepared to serve. In our case, port 111 is access to a network file system. Let’s use Nmap to enumerate this as well.

What mount can we see?

Gain initial access with ProFtpd

ProFtpd is a free and open-source FTP server, compatible with Unix and Windows systems. Its also been vulnerable in the past software versions. Lets get the version of ProFtpd. Use netcat to connect to the machine on the FTP port.

What is the version?

We can use searchsploit to find exploits for a particular software version. Searchsploit is basically just a command line search tool for exploit-db.com.

How many exploits are there for the ProFTPd running?

There is an exploit for the mod_copy module of ProFTPD. This module implements SITE CPFR and SITE CPTO commands, which can be used to copy files/directories from one place to another on the server. Any unauthenticated client can leverage these commands to copy files from any part of the filesystem to a chosen destination. We know that the FTP service is running as the Kenobi user (from the file on the share) and an ssh key is generated for that user. We’re now going to copy Kenobi’s private key using SITE CPFR and SITE CPTO commands.

As we knew that the /var directory was a mount from above, we could have moved Kenobi’s private key to the /var/tmp directory. As a next step, let’s mount the /var/tmp directory to our machine.

We now have a network mount on our deployed machine. We can go to /var/tmp and get the private key then login to Kenobi’s account.

What is Kenobi’s user flag (/home/kenobi/user.txt)?

Privilege Escalation with Path Variable Manipulation

SUID bits can be dangerous, some binaries such as passwd need to be run with elevated privileges (as it can reset passwords of a system). Let us search the a system for these type of files.

What file looks particularly out of the ordinary?

Running the binary, how many options appear?

Strings is a command on Linux that looks for human readable strings on a binary. This shows us the binary is running without a full path (e.g. not using /usr/bin/curl or /usr/bin/uname). As this file runs with root privileges, we can manipulate our path to gain a root shell.

What is the root flag?

We copied the /bin/sh shell, called curl, gave it the correct permissions and then putting its location in our path. This means when the /usr/bin/menu binary runs, it uses our path variable to find the “curl” binary. As this is actually a version of /usr/sh and runs as root it also runs our shell as root.

Thanks for reading and as always, any feedback is most welcome.