πββοΈBacktrack
License
The following post by anthonyjsaab is licensed under CC BY 4.0
0 - Introduction
Created by tryhackme, 0utc4st, and YoloSaimo
1 - Port Scans
1a - Discovery
1b - Versions and OS
2 - Aria2 WebUI
2a - Finding the vuln

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

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:


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
There are 4 accounts that can be considered human based on their ids: root, tomcat, orville and wilbur
We cannot login using tomcat through ssh (/bin/false)
We collected a password from a well-known configuration file for tomcat
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:

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'.


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:



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:

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.


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:
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:
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:
With socat listening and proxying on the target machine, I am able to do this:

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:


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

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


We have to bypass these 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:



5 - ROOT
Last updated
Was this helpful?

