πŸƒβ€β™‚οΈBacktrack

License

The following post by anthonyjsaab is licensed under CC BY 4.0

0 - Introduction

Machine version: Backtrack 2.5

Created by tryhackme, 0utc4st, and YoloSaimo

1 - Port Scans

1a - Discovery

1b - Versions and OS

2 - Aria2 WebUI

2a - Finding the vuln

Port 8888 landing page

The HTTP server on port 8888 returns a WebUI called Aria2 WebUI. Quickly searching for a vuln on Google:

The server on port 8888 may be vulnerable to directory traversal.

2b - Directory Traversal

After clearing the cache on the browser, proxying all requests to Burp and holding the requests for a while without forwarding, we can see how the WebUI behaves and what it sends without having to go through the code. We intercept multiple requests without interacting with the browser, but this is the one we are interested in:

The POST request will be modified in Repeater
Directory Traversal was successful

Amazing! This is a great way to look inside the targets files.

2c - Gathering sensitive info

Trying to brute-force some well-known files using Intruder crashes the Aria server. We have to access files manually in order not to overwhelm and crash the server.

/etc/passwd

/proc/self/environ

/opt/tomcat/conf/tomcat-users.xml

2z - What we know so far

  1. There are 4 accounts that can be considered human based on their ids: root, tomcat, orville and wilbur

  2. We cannot login using tomcat through ssh (/bin/false)

  3. We collected a password from a well-known configuration file for tomcat

  4. The server on port 8888 runs with privileges of the tomcat user

3 - Foothold

3a - Dead-ends

id_rsa

Trying to collect the private key of the users (except tomcat) did not yield anything

authorized_keys

Trying to authorize my own key by writing to the respective .ssh folders did not work because of a lack of adequate permissions for the tomcat user:

Upload succeeds, but cannot be effectively stored in the requested destination location

3b - Tomcat, help!

The tomcat admin credentials we got were great, but the user in question has no useful privileges. This is because its role is only 'manager-script'.

Cannot access host-manager
Cannot access manager

We have to find a way to elevate this tomcat user. This can be done only by editing the /opt/tomcat/conf/tomcat-users.xml file. But how can we do that?

Well, since we already know that the server on port 8888 has the Linux 'tomcat' user's privileges, the server can probably overwrite tomcat-users.xml by downloading a new one!

I will host the following file on my machine, where the roles are significantly higher:

And now using the Aria2 WebUI:

The granular options provided on Aria2 WebUI are very helpful
Fingers crossed
We now have access to the admin panels!

3c - Have I been here before?

If you look closely at the /manager/html panel above, you will notice a path called /reverse_shell!

Requesting it gives us the following:

Why is metasploit mentioned here?!

I am not sure what is happening here, but it is not worth investigating. I do have enough privileges to upload a shell of my own. I will be using a webshell that is bundled in /usr/share/webshells/jsp/jsp-reverse.jsp.

Before uploading, change line 74 to Process proc = rt.exec("/bin/bash");
Form to activate reverse shell

4 - Lateral PrivEsc

4a - LinPEAS

Downloading LinPEAS on target and storing output

Encoding and sending output

Receiving and decoding output

Here is the LinPEAS output:

148KB
Open

4b - Wilbur

The following lead presented itself before I even ran LinPEAS:

The wildcard above gives us great freedom! We can backtrack to a directory where we have stored a revshell command in a custom yml file:

150KB
Open

4c - Orville

Something promising appeared in the LinPEAS output, even before we moved to wilbur:

It seems there is an HTTP server open on port 80, but only on the loopback interface. I wanted to be sure:

There is definitely an HTTP server on this port! I need to open a proxy port to access it easily from Kali:

Using this on the target machine

With socat listening and proxying on the target machine, I am able to do this:

This site seems to indicate it is run by the Orville user

The website does not give us much wiggle room to try and exploit it from the browser. And it seemed like a dead-end. At least when I was tomcat. But now that I am wilbur, I had access to a very important file:

This was the missing puzzle piece! Now I can login and proceed:

Logging in with the newfound credentials stored in /home/wilbur/from_orville.txt
Landing page after login

We can see that there are no images yet. Let us upload as image of our own and see what happens.

The image appeared after uploading

Now the question is: can we upload a shell? I will try to upload my favorite PHP webshell:

It claims to have refused the upload. There is seemingly a whitelisting in place
Indeed, the shell was not stored

We have to bypass these filters:

Adding a 'fake' extension bypasses the filters

However, trying to go to http://backtrack.thm:2345/uploads/shell.gif.php just downloads the file! But we see that in the root directory (above uploads/), where login.php and dashboard.php are stored, the PHP files are rendered instead of sent as is. Dead ends:

  • Apache/2.4.41 does not have a known directory traversal published, so storing it somewhere on the filesystem using wilbur and trying to access it through Apache won't work

  • /var/www/html is not accessible using any of the users we compromised

We can however try to add some backtraces to the filename:

Using a simple backtrace will store the file in uploads/. So it fails. We have to use Intruder to try and store it anywhere above uploads/ (ideally just above it). To do that, we will use a famous repo's wordlist:

Settings for Intruder
Yay! Some payload worked!
Let's gooooooo

5 - ROOT

Last updated

Was this helpful?