HTB - Feline

Zweilosec's writeup on the hard-difficulty Linux machine Feline from https://hackthebox.eu

Overview

Short description to include any strange things to be dealt with - Hard Linux

Useful Skills and Tools

Useful thing 1

  • description with generic example

Useful thing 2

  • description with generic example

Enumeration

Nmap scan

I started my enumeration with an nmap scan of 10.10.10.205. The options I regularly use are: -p-, which is a shortcut which tells nmap to scan all ports, -sC is the equivalent to --script=default and runs a collection of nmap enumeration scripts against the target, -sV does a service scan, and -oA <name> saves the output with a filename of <name>.

only two ports open, 22- SSH and 8080 - HTTP

HTTP had a website, VirusBucket for uploading and testing files for malware.

I tried uploading a PHP webshell, but got File Upload failed errors. Burp told me that it was an invalid filename.

Next, I tried uploading a cmd.jsp simple webshell from https://github.com/tennc/webshell/blob/master/fuzzdb-webshell/jsp/cmd.jsp

and got a success message

Note: renaming the PHP files uploaded fixed the invalid filename error. After some testing I found that filenames could not have - or _ in them.

Unfortunately neither of these webshells gave me code execution as I hoped.

Uploading a PNG file made it spit out a very verbose error message. I could see in the output the location the files were being uploaded to: /opt/tomcat/temp/upload_d4070743_9738_4ba0_94f9_f5544ed1c26d_00000027.tmp. This gave me a chance to try to execute code if directory traversal was not blocked

CVE-2020-9484

Googling the version of apache Apache Tomcat 9.0.27 and "file upload" lead to pages that gave instructions for deploying a web app through a .war file....

according to https://tomcat.apache.org/tomcat-9.0-doc/changelog.html 9.0.41 is the newest version, so I thought that perhaps 9.0.27 had vulnerabilities.

Found a vulnerability that had been fixed in version 9.0.35 that sounded very useful for getting remote code execution, which was given CVE number CVE-2020-9484.

Apache Tomcat is affected by a Java deserialization vulnerability if the PersistentManager is configured as session manager. Successful exploitation requires the attacker to be able to upload an arbitrary file to the server.

Downloaded the latest release of ysoserial and created my simple reverse shell script payload

Then followed the instructions to use ysoserial to create my malicious session file to deserialize

The next malicious session file was used to give execute permissions to the first payload

The final malicious session file was used to execute my payload.sh reverse shell

Finally I wrote a script to automate uploading all of these files to the server. Next I ran python3 -m http.server so that the final payload could be downloaded, started a netcat listener, and then I ran the script and hoped that everything would work!

Each of the files were uploaded successfully, though they each threw a HTTP Status 500 – Internal Server Error, probably after deserializing the "session" it expected.

Initial Foothold

Got a connection to my http.server, sending my payload on its way

I started logging output with the script command, started a bash shell (since zsh seems to have problems with stty raw -echo), then started my netcat listener. After running my exploit.sh I got a shell!

Enumeration as tomcat

Netstat showed that there were a few more ports open internally that I didn't see from my machine. 53, 4505, 4506, 8000, and 8005

There was a docker container hosted

user.txt

The user tomcat ended up being the user with the user.txt flag!

Path to Power (Gaining Administrator Access)

Further enumeration as tomcat

only tomcat and root could log in with a shell

linpeas.sh showed that the socket /run/snapd.socket could be communicated with, so I validated it. Since this socket was owned by root this could be a possible privesc method

https://book.hacktricks.xyz/linux-unix/privilege-escalation/socket-command-injection

This socket did not seem to be vulnerable to this kind of injection

CVE-2020-16846

Next I looked closer at the ports that were open internally. SaltStack uses ports 4505 and 4506 for its Salt master

Publisher (port 4505) All Salt minions establish a persistent connection to the publisher port where they listen for messages. Commands are sent asynchronously to all connections over this port, which enables commands to be executed over large numbers of systems simultaniously.

Request Server (port 4506) Salt minions connect to the request server as needed to send results to the Salt master, and to securely request files and minion-specific data values (called Salt pillar). Connections to this port are 1:1 between the Salt master and Salt minion (not asynchronous).

I did not see a salt user so it was possible that this might be running as root

CVE-2020-16846:

Impact: This CVE affects any users running the Salt API. An unauthenticated user with network access to the Salt API can use shell injections to run code on the Salt-API using the SSH client.

links to metasploit module: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/http/saltstack_salt_api_cmd_exec.rb

This module would require the port to be open from the outside, so I decided to make an SSH tunnel to give it a target to connect to. Unfortunately, tomcat's user folder was owned by root so I could not create a .ssh folder to inject my key. Instead, I uploaded chisel and made a tunnel with that.

Getting a shell

First I created a server on my machine listening for reverse connections

Then on the victim machine I downloaded chisel, made it executable, then created a reverse connection linking port 8000 on both machines (this was the port the msfconsole exploit wanted)

for some reason executing some commands caused my connection to drop so I had to keep recreated the session

There was no root.txt in the /root folder, but there was a todo.txt

switching the payload to cmd/unix/python//// made it much more stable

AFter trying a number of times to put my ssh key into the authorized_keys file and failing to log in, I realized that I was not on the host victim machine. I must be inside a VM or container...

the interface eth0 had an ip of 172.. which was a docker IP...I felt like this had been a bit too easy!

the root user had a bash_history file that hadn't been set to /dev/null, and contained a few interesting commands

I mimicked a few of the commands that were in the history to see if there were any clues

from the command history I could see that root had set a password, so I copied the hash to my computer and tried to crack it...unsuccessfully

the docker command was not installed in the container, but since it was in the host, I copied it over from other shell

https://docs.docker.com/storage/bind-mounts/ using this I could mount the /root directory of the host machine to the container and then copy my ssh key over to enable login

docker command not availble inside container

Hosted python3 http.server from tomcat user in the /usr/bin folder

downloaded the docker program to the container

after some enumeration I was ready to craft my command to mount the filesystem

I mounted /root from the host machine to /tmp in the container

I changed directories to /tmp in the container, which now mirrored /root on the host machine. I echoed my ssh key to root's authorized_keys file, then tried to login with ssh

Root.txt

I was in, and got my root proof!

Thanks to MinatoTW & MrR3boot for... [something interesting or useful about this machine.]

If you like this content and would like to see more, please consider buying me a coffee!

PreviousHTB - UnbalancedNextHTB - Compromised

Last updated

Was this helpful?