#hackthebox

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

Welcome to my Cyber Playground

A little about me: I am a grey-hat hacker, I mainly do bug bounties, but sometimes do a bit of...questionable work albeit never explicitly malicious.

I am a programmer and my primary programming languages are C, C++, and Python 3, Python being my favorite and the language I am most fluent in. 

I build malware and hacking tools, sometimes for fun, sometimes for curiousity, sometimes to sell for... “educational purposes” albeit I hold NO responsibility for what people do with my software.

I am 28 years old and part of a grey-hat hacking group who also has a few black-hats thrown in the mix for good measure. I am not bias against what other people do, but I have a firm belief in not harming anyone unless they harm you first.

Furthermore, most of the stuff I will be posting on here is just programming stuf, maybe some malware sourcecode, and possibly some penetration testing tools that I have developed or am in the process of developing.

My current projects are:

Building a website for my fiance with Flask, HTML5, Boostrap, and Mongo. Building a new ransomware.

Getting more familiar with different types of encryption Learning Tensorflow, Tkinter, PyQt6, and Tensorflow for machine learning. Currently I am enrolled in: Intro to Statistics IBM AI Engineering Certification Classes IBM Deep Learning IBM Cyber Security Analyst Certification Machine Learning with Python FreeCodeCamp’s Machine Learning with Python

Stuff I’ve recently finished or am interested in collaborating on: A phone number grabber that geolocates the origin of the number using Google’s phonenumber python package & geolocate package for python. (Looking to collaborate on this to make it into much more than just a geolocator and more similar to a doxer) A RAT called DEATHSDOOR which is available on my github for study. A keylogger that sends logs to email. A ransomware that needs debugging and finishing called Slenderware (please feel free to inquire about collaboration on this project) An email bomber called Slenderbomber which needs significant improvements to avoid spam ban.

An email client that I finished with my friend Fazal from Instagram, we just created the GUI for it using Tkinter and it is fully functional! Will upload videos later of the basic program pre-GUI. A Discord spammer called Yoshibot that is finished but broken due to ASCII errors and all that fun stuff.

01.23.25. Hacking, hacking and more hacking yeahhh 🤘🏻

Today's machine: HackTheBox - TwoMillion

Such a great machine for learning web hacking and pretty cool privilege escalation techniques

=============================================== A focused fool can accomplish more than a distracted genius ================================================

01.11.25. Getting started with Pivoting, Tunneling, Port Forwarding and what else? Yeah, Lateral Movement.

Something interesting about this:

================================================= Lateral movement is a technique cyber attackers use to navigate through a compromised network or system. Unlike initial access, which involves breaking into a system, lateral movement is about expanding control within the environment. Lateral movement is dangerous because attackers can escalate their attack from an initial compromise to widespread network infiltration. =================================================

But there is something else my friend...

======================================== Lateral Movement needs Lateral Thinking ========================================

So I've been doing some good old HackTheBox machines to refresh a little on my hacking skills and this machine was a very interesting one!

Exploitation itself wasn't particularly difficult; what was, however, was finding information on what I needed to do! Allow me to explain the process. :)

Enumeration

As is standard, I began with an nmap scan on SteamCloud:

Other than OpenSSH being outdated, all that I could really see was the use of various web servers. This led me to believe that there was a larger app running on the server, each service interacting with a different component of the app.

I performed some initial checks on each of these ports and found an API running on port 8443:

I noted the attempt to authenticate a user referred to as 'system:anonymous', originally thinking these could be credentials to another component of the application.

Some directory scans on different ports also revealed the presence of /metrics at port 10249 and /version at port 8443. Other than that, I really couldn't find anything and admittedly I was at a loss for a short while.

This is where I realized I'm an actual moron and didn't think to research the in-use ports. xD A quick search for 'ports 8443, 10250' returns various pages referring to Kubernetes. I can't remember precisely what page I checked but Oracle provides a summary of the components of a Kubernetes deployment.

Now that I had an idea of what was being used on the server, I was in a good place to dig further into what was exploitable.

Seeing What's Accessible

Knowing absolutely nothing about Kubernetes, I spent quite a while researching it and common vulnerabilities found in Kubernetes deployments. Eduardo Baitello provides a very informative article on attacking Kubernetes through the Kubelet API at port 10250.

With help from this article, I discovered that I was able to view pods running on the server, in addition to being able to execute commands on the kube-proxy and nginx pods. The nginx pod is where you'll find the first flag. I also made note of the token I discovered here, in addition to the token from the kube-proxy pod (though this isn't needed):

After finding these tokens, I did discover that the default account had permissions to view pods running in the default namespace through the API running on port 8443 (/api/v1/namespaces/default/pods) but I had no awareness of how this could be exploited.

If I had known Kubernetes and the workings of their APIs, I would have instantly recognised that this is the endpoint used to also add new pods to Kubernetes, but I didn't! Due to this, I wasted more time than I care to admit trying other things such as mounting the host filesystem to one of the pods I can access and establishing a reverse shell to one of the pods.

I did initially look at how to create new pods too; honestly there's very little documentation on using the API on port 8443 directly. Every example I looked at used kubectl, a commandline tool for managing Kubernetes.

Exploitation (Finally!)

After a while of digging, I finally came across a Stack Overflow page on adding a pod through the API on port 8443.

Along with this, I found a usable YAML file from Raesene in an article on Kubernetes security. I then converted this from YAML to JSON and added the pod after some minor tweaks.

My first attempt at adding a pod was unsuccessful- the pod was added, but the containers section was showing as null

However, it didn't take me long to see that this was due to the image I had specified in the original YAML file. I simply copied the image specified in the nginx pod to my YAML file and ended up with the following:

I saved the json output to a file named new-pod2.json and added the second pod.

curl -k -v -X POST -H "Authorization: Bearer <nginx-token>" -H "Content-Type: application/json" https://steamcloud.htb:8443/api/v1/namespaces/default/pods [email protected]

This time, the pod was added successfully and I was able to access the host filesystem through 'le-host'

The Vulnerability

The main issue here that made exploitation possible was the ability to access the Kubelet API on port 10250 without authorization. This should not be possible. AquaSec provide a useful article on recommendations for Kubernetes security.

Conclusion

SteamCloud was a relatively easy machine to exploit; what was difficult was finding information on the Kubernetes APIs and how to perform certain actions. It is one of those that someone with experience in the in-use technologies would have rooted in a matter of minutes; for a noob like me, the process wasn't so straightforward, particularly with information on Kubernetes being a little difficult to find! I've only recently returned to hacking, however, which might have contributed to my potential lack of Google Fu here. ^-^

Another Windows machine down; again, I can’t say this was particularly difficult.

It has a rating of medium but I’m unsure why if I’m honest...Perhaps there’s more resources out on the two attack vectors?

It took me a little longer than I’m happy with but I’m afraid web apps are where I lack at the moment- I spent a considerable amount of time checking for SQL injection, XML-RPC weaknesses and it also doesn’t help that my Kali Linux VM can’t connect to Ruby servers for downloading Ruby libraries (or gems)- after spending some time attempting to solve that issue I simply hopped over to my host to get the bastard rooted. ;P

So, my enum script (since made amendments to this: it wasn’t picking up some files it should have such as robots.txt) and then manual checks:

There are 3 logon forms- one to login, one to register and one for password resets- and some misc web app config files such as CHANGELOG.txt and robots.txt.

CHANGELOG reveals that Drupal is running on version 7.54 while robots shows an array of disallowed URLs.

Firstly, I performed some checks on the present forms and I did discover the existence of user ‘admin’ via the password reset form: existing users can be enumerated as the server will respond with username/email not recognized for non-existent usernames and an error on sending a reset email to valid usernames.

I played around with both this and the login form for a while- tried some classic SQL injection cases and alike; unfortunately for us, we’re temporarily locked out if we enter the incorrect password 5 times.

Now this is a shame for the brute force queen... My first thought with login forms is brute force if there doesn’t seem to be any other vectors present. Taking this as a sign that I was barking up the wrong tree, I moved on to instead seeing if there were any other users on the server by utilizing a username brute force script I have in Bash on the password reset form while I looked around a bit more.

It was around here I ran into drupwn- a Drupal web API enumeration tool written in Python. It’s a bit rubbish to be honest as it has a tendency to hang and requires you to manually stop the running process; it did reveal that my enum script had missed robots.txt and CHANGELOG in it’s execution (since been amended.)

It also revealed the version of Drupal in-use; the script probably just looked through CHANGELOG and grabbed the mentioned version.

I did look into these files but robots had alot of entries that -as an inexperienced web app hacker- would have taken me hours to manually test while CHANGELOG revealed nothing but the version of Drupal in-use.

With the version of Drupal identified, however, this did mean that searching for public exploits was a great deal easier. I took to searchsploit -a native Kali Linux tool- and discovered several Drupal exploits:

Here we see mentioned Drupalgeddon3 and 2; by process of elimination we know 3 wouldn’t work due to a lack of valid credentials. If any, the vulnerability in question is exploited by Drupalg2.

Drupalgeddon2 (https://github.com/dreadlocked/Drupalgeddon2) is a remote-code execution vulnerability resulting from a lack of input validation on form API AJAX requests. This allows users to inject malicious payloads -in the form of renderable arrays- into the create user form.

In the case of the registration form, this applies to the mail parameter- by setting the values of indexes [#post_render][] to exec, [#type] to markup and ][#markup] to our desired system command we gain RCE (I briefly just tried to exploit this manually but I simply used dev tools within FireFox browser, probably would have succeeded if I’d tried through Burp Proxy or similar!)

It was at this point that I had to switch over to my host to finish up; honestly at this point the bulk of enumeration is complete.

drupalgeddon2>> whoami nt authority\iusr

iusr is essentially Window’s version of an ‘anonymous’ user that is utilized by default by IIS servers in order to access the required system files.

We can grab the user flag from Users/dimitris/Desktop instantly; thankfully there’s further privilege escalation needed for complete admin access!

By following any WIndows privesc cheatsheet, you should check out the privileges on the logged in account and see that we have an interesting one named ‘SeImpersonatePrivilege’- the ability to impersonate a client after authentication.

From previous reading I was aware that this Windows privilege basically means we’re system as there is a well known privesc technique for this called Juicy Potato- the last step is simply seeing how we can download files onto the victim and finding the relevant CISID for our Windows version. Bastard is a Windows 2008 server- as revealed by checking systeminfo.

After some trial and error, I managed to utilize CertUtil:

CertUtil was originally intended to be used to display CA (Certificate Authority) config information and to also make any neccessary alterations to CA components (basically an administrative tool for all things CA related :3)

Part of CertUtil’s functionality includes the ability to download files... Don’t ask me why they thought this was safe. I guess it was in the event of needing third party CA templates (basically pre-config of CA via certificate templates)?

With netcat and JuicyPotato now on our victim, we are able to exploit this privilege for a reverse shell.

This vulnerability is famously named Rotten Potato and -at a simple level- involves tricking AUTHORITY/SYSTEM into authenticating via NTLM to a TCP endpoint under our control.

This authentication process is then captured via a local MITM attack utilizing several Windows API calls. Finally -with one of the relevant privileges- we use the captured token for impersonation, thus gaining the ability to execute commands as SYSTEM.

For those who didn’t guess by the screenshot, a reverse shell is established through our run of jp.exe (I was running a nc listener on port 6969 to receive the connection) and we are able to read root.txt from Administrator’s Desktop directory.

The CLSID I used was obtained from https://github.com/ohpe/juicy-potato/tree/master/CLSID/Windows_Server_2008_R2_Enterprise.

DevOops is allegedly more difficult than OSCP but good practice; i actually found it quite easy. Probably because the vulnerabilities to exploit are pointed out.

An nmap scan reveals Gunicorn to be listening on port 5000- this is already a hint at the second attack required for the user flag as this was the same type of server I had to target for root access to Symfonos 4. Basic directory brute force further reveals the presence of three files- upload, the root of the server (index.html) and feed.

Index hints that the server uses Python at the back-end: apparently the root is feed.py while feed simply loads a png image and upload reveals a simple upload file form with reference to XML elements.

With so little to explore, it was quickly obvious that the upload form is probably vulnerable to some form of attack. I started by uploading txt and png files to observe the results- the page is simply reloaded.

This is when I thought to try uploading an XML file to the server- particularly with the hint towards what XML elements to use. 10 minutes research later and I’d put together a simple test.xml file.

I didn’t immediately jump to trying the above file: I firstly confirmed this was a vulnerability by trying to view /etc/passwd which was returned in the content element upon upload of the file.

After this, I spent half an hour or so seeing if RCE was possible through external entity attack; while it could have been if PHP was in use, it isn’t obviously so in the case of Python. This is when I remembered feed.py.

Feed.py revealed the insecure use of pickle on user supplied POST data to /newpost. After facing similar with JSON pickles in the past, I was aware that RCE was possible through this vulnerability and began working towards a reverse shell.

I learned here that things should always be tested locally first before testing them remotely: I was fiddling around with the reverse shell for an hour or two and constantly receiving error 500s. When I tried ti loally and it worked, i knew it was likely that there was something else wrong with my payload.

After 10-20 minutes, I discovered that adding the Content-Type header and setting it to text/html resulted in successful delivery of the payload (I confirmed this with a simple ping at first.)

Now I just needed to get a working payload- netcat was on the victim but a nc reverse shell resulted in immediate disconnection meaning the process was being terminated for some reason on their end. After some trial and error, I uncovered the following working payload:

I created this script from a few I found on Google. The pickle vulnerability arises form the manner in which pickle deserializes data (translating a byte stream to an object in the case of Python, an object being a list or dictionary etc.)

Objects with pickle are serialized using dumps or dump while they are deserialized using load/loads.

To achieve RCE through pickle, however, we must use the __reduce__function:  it requires a callable object and an optional tuple of arguments for the called object, thus providing this to the Pickle process will executable the mentioned callable object along with the provided arguments.

The above revere shell succeeded and I had a foothold on the system as Roosa. I could have probably read the user flag back in the external entity attack; I thought I’d save it for when I had achieved RCE.

The root flag is very easy- simple enumeration of Roosa’s home directory reveals a GitHub project called ‘blogfeed’ and the presence of an RSA private key used for the project’s integration. I had my suspicions this key may be relevant and thus saved it for further use later.

Further basic enumeraton (specifically of .bash_history) shows us that Roosa screwed up at one point and accidentally submitted a relevant private key to the GitHub project. Although not an expert, I use GitHub myself and thus am aware that previous commits can be viewed.

Some research showed that it is possible to view patches (I simply refer to it as changes but hey ho) to a GitHub repo via the git log -p command. Executing this reveals the original key submitted to the repo.

From here I discovered that an RSA private key can be used in place of a password for SSH access... Perhaps we have root’s private key here? I tried this with ssh -i old-key [email protected] and sure enough we have root access.

I enjoyed this machine but I don’t feel it should be of medium difficulty- it actually took me longer on the user flag.