# HackTheBox-Catch
## NMAP
```bash
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.4 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
3000/tcp open ppp?
| fingerprint-strings:
| FourOhFourRequest:
| HTTP/1.0 404 Not Found
| Content-Type: text/html; charset=UTF-8
| Set-Cookie: i_like_gitea=0eb9e22f84769b34; Path=/; HttpOnly
| Set-Cookie: _csrf=qeeMQU6Ir6U9YV6qRlnEuGDw_qQ6MTY0NzExMTgwNDEyODk2NTc1Nw; Path=/; Expires=Sun, 13 Mar 2022 19:03:24 GMT; HttpOnly; SameS
ite=Lax
| Set-Cookie: macaron_flash=; Path=/; Max-Age=0; HttpOnly
| X-Frame-Options: SAMEORIGIN
| Date: Sat, 12 Mar 2022 19:03:24 GMT
|
|
|
|
|
|
| Page Not Found - Catch Repositories
|
On visiting this port we can see an options to download and click the button we get an android application, the login and signup buttons are just for show, doesn't really take us anywhere on clicking them
## PORT 3000 (Gitea)
On this port we can see an instance of `gitea` running
## PORT 5000 (Let's Chat)
On port 5000 there's a `let's chat` application hosted which is taken from this github repoistory which is a small team chat application https://github.com/sdelements/lets-chat
## PORT 8000 (Cachet)
On port 8000 there's `Cachet` running which is an opensource status page system which tells about the status of the web application's components like website functional or is there any problem with the api being used
## Analyzing the apk
We can do some static analysis on the apk through `MobSF`
We can find some tokens from this app as they are hardcoded in the application
I spend so much time to make the git_tea token then moved to lets_chat_token at first when I looked at and thought that there isn't any api as the let's chat only display us a login page so I googled for let's chat token which led me to this that there's an api for this web app
https://github.com/sdelements/lets-chat/wiki/API
This shows us that how we can authenticate to access these api end points
So making a request using `curl` with the header `'Authorization: Bearer NjFiODZhZWFkOTg0ZTI0NTEwMzZlYjE2OmQ1ODg0NjhmZjhiYWU0NDYzNzlhNTdmYTJiNGU2M2EyMzY4MjI0MzM2YjU5NDljNQ=='` we can access the endpoints
```bash
curl -X GET http://10.10.11.150:5000/account -H 'Authorization: Bearer NjFiODZhZWFkOTg0ZTI0NTEwMzZlYjE2OmQ1ODg0NjhmZjhiYWU0NDYzNzlhNTdmYTJiNGU2M2EyMzY4MjI0MzM2YjU5NDljNQ=='
```
I checked the `messages` and `files` endpoint but it didn't reutrn any data
Using the `rooms` end point it should us that there are three rooms , `Status` ,`Android Development` and `Employees`
So first checking the messages in `android_dev`
```bash
curl -X GET http://10.10.11.150:5000/rooms/android_dev/messages -H 'Authorization: Bearer NjFiODZhZWFkOTg0ZTI0NTEwMzZlYjE2OmQ1ODg0NjhmZjhiYWU0NDYzNzlhNTdmYTJiNGU2M2EyMzY4MjI0MzM2YjU5NDljNQ==' | jq
```
Nothing really in there moving onto `employees`
This shows that a new employee is hired, so maybe now we'll get something juicy from last room we have left
```bash
curl -X GET http://10.10.11.150:5000/rooms/status/messages -H 'Authorization: Bearer NjFiODZhZWFk
OTg0ZTI0NTEwMzZlYjE2OmQ1ODg0NjhmZjhiYWU0NDYzNzlhNTdmYTJiNGU2M2EyMzY4MjI0MzM2YjU5NDljNQ==' | jq
```
Using these creds on catchet login page
And we are logged in as john
After logging we can see catchet version which is `2.4.0-dev`
Searching for vulnerabilites on catchet we can find a blog post talking about the three CVEs
https://blog.sonarsource.com/cachet-code-execution-via-laravel-configuration-injection
The first one `CVE-2021-39172 - Remote Code Execution` requires a poc and the redis service to be reachable which in this case doesn't fit in our scenario and the third one which is `CVE-2021-39173 - Forced Reinstall` didn't worked as well so this leads us to `CVE-2021-39174 - Configuration Leak` which can leak the variables in `.evn` file, so checking out what the env file would have
https://docs.cachethq.io/docs/installing-cachet
## Foothold
We can leak variables `APP_KEY` which can be useful for getting a reverse shell but since there wasn't any straight forward way or proof of concept in the blog to either leak the env variables or to get a reverse shell with this but anyways here's how we were able to leak the env variables (after a lot trial, error and swearing )
First we need to intercept the request when saving the values in mail configuration
Here we can see post parameter `mail_driver` so we need to change this parameter's value to `${APP_KEY}` and after that hit the `test` button which will get tested and the APP_KEY value will get stored in the logs
After this we will be shown a 500 status code but it's okay, after checking the logs we'll see that it has leaked the value of APP_KEY
But I wasn't able to figure out how would I use this to get a reverse shell so going back to see the default env file we can try leaking the password vairable, `DB_PASSWORD` is the one which seems promising
We can try using this password for the usernames we got from the /users endpoint from let's chat api
From which the password from DB_PASSWORD worked on `will`
Running `sudo -l` to see what we can run as root user
## Privilege Escalation
There wasn't anything else I could think of other than running `pspy` to see what cron jobs or processes was running as root user, so after transferring pspy we can see a script being ran `/opt/mdm/verify.sh` as root user
Starting with this script first it will check for apk file in `/opt/mdm/apk_bin` and will run a for loop to read all apk files in this directory and generate a 12 character long hex value using `openssl` so the filename becomes unique, after renaming it will move the apk file to `/root/mdm/apk_bin`
After moving the apk file, it will perform three checks on the apk file
The first check `sig_check` will check if apk is signed or not using `jarsigner`, if it isn't will ignore the apk by running the cleanup function which will remove the apk and the folder created for that apk
The second function `comp_check` ,will run `apktool` to decompile the apk with `d` and with `-s` will decode file resources to read the `AndroidManifest.xml` file to check the sdk version which should be greater then 18 meaning should be compatible with android version 4 and above it fails this check then it would run cleanup function and delete the file.
The third function `app_check`, it will check application name from `strings.xml` that it must have "Catch" in it doesn't matter what contains before or after it and will run shell command after piping it to `xargs`
```bash
echo -n $APP_NAME|xargs -I {} sh -c 'mkdir {}'
```
Which means that we can do command injection in the application name, so what we need do here is modify the catch1.0.apk that we got from the website, decompile it using apktool and change the application name, make sure to use the updated apktool which is 2.6.1 because buldiing the application after decompiling the resources wouldn't work with apktool 2.5.0
https://github.com/iBotPeaches/Apktool/releases/tag/v2.6.1
And to make apktool 2.6.1 to execute directly, remove the one from /usr/bin/, since this is a jar file we can convert it to executable by following this
https://stackoverflow.com/questions/44427355/how-to-convert-jar-to-linux-executable-file
This step isn't really needed it's just what I found useful for future purpose
After decompiling the apk, we can find strings.xml in `./res/values`
Here we have placed a simple command injection to make bash a SUID binary, after that we need to compile the apk by using `apktool b ./folder`
The apk file will be saved in `dist` folder
We still need to sign it, jarsigner will show that this apk file is unsigned as we have modified this apk
Following this post from stackoverflow
https://stackoverflow.com/questions/10930331/how-to-sign-an-already-compiled-apk
```bash
keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
```
After generating keystore file, we can use jarsigner to sign the apk
```bash
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore catchv2.0.apk alias_name
```
Running jarsigner again to check if the apk is signed
Transferring the apk file on the machine
Within a minute we'll see that bash has a SUID and we can then become root user by running bash with `bash -p`
## References
- https://github.com/sdelements/lets-chat/wiki/API
- https://blog.sonarsource.com/cachet-code-execution-via-laravel-configuration-injection
- https://docs.cachethq.io/docs/installing-cachet
- https://github.com/iBotPeaches/Apktool/releases/tag/v2.6.1
- https://stackoverflow.com/questions/44427355/how-to-convert-jar-to-linux-executable-file
- https://stackoverflow.com/questions/10930331/how-to-sign-an-already-compiled-apk
## PORT 3000 (Gitea)
On this port we can see an instance of `gitea` running
## PORT 5000 (Let's Chat)
On port 5000 there's a `let's chat` application hosted which is taken from this github repoistory which is a small team chat application https://github.com/sdelements/lets-chat
## PORT 8000 (Cachet)
On port 8000 there's `Cachet` running which is an opensource status page system which tells about the status of the web application's components like website functional or is there any problem with the api being used
## Analyzing the apk
We can do some static analysis on the apk through `MobSF`
We can find some tokens from this app as they are hardcoded in the application
I spend so much time to make the git_tea token then moved to lets_chat_token at first when I looked at and thought that there isn't any api as the let's chat only display us a login page so I googled for let's chat token which led me to this that there's an api for this web app
https://github.com/sdelements/lets-chat/wiki/API
This shows us that how we can authenticate to access these api end points
So making a request using `curl` with the header `'Authorization: Bearer NjFiODZhZWFkOTg0ZTI0NTEwMzZlYjE2OmQ1ODg0NjhmZjhiYWU0NDYzNzlhNTdmYTJiNGU2M2EyMzY4MjI0MzM2YjU5NDljNQ=='` we can access the endpoints
```bash
curl -X GET http://10.10.11.150:5000/account -H 'Authorization: Bearer NjFiODZhZWFkOTg0ZTI0NTEwMzZlYjE2OmQ1ODg0NjhmZjhiYWU0NDYzNzlhNTdmYTJiNGU2M2EyMzY4MjI0MzM2YjU5NDljNQ=='
```
I checked the `messages` and `files` endpoint but it didn't reutrn any data
Using the `rooms` end point it should us that there are three rooms , `Status` ,`Android Development` and `Employees`
So first checking the messages in `android_dev`
```bash
curl -X GET http://10.10.11.150:5000/rooms/android_dev/messages -H 'Authorization: Bearer NjFiODZhZWFkOTg0ZTI0NTEwMzZlYjE2OmQ1ODg0NjhmZjhiYWU0NDYzNzlhNTdmYTJiNGU2M2EyMzY4MjI0MzM2YjU5NDljNQ==' | jq
```
Nothing really in there moving onto `employees`
This shows that a new employee is hired, so maybe now we'll get something juicy from last room we have left
```bash
curl -X GET http://10.10.11.150:5000/rooms/status/messages -H 'Authorization: Bearer NjFiODZhZWFk
OTg0ZTI0NTEwMzZlYjE2OmQ1ODg0NjhmZjhiYWU0NDYzNzlhNTdmYTJiNGU2M2EyMzY4MjI0MzM2YjU5NDljNQ==' | jq
```
Using these creds on catchet login page
And we are logged in as john
After logging we can see catchet version which is `2.4.0-dev`
Searching for vulnerabilites on catchet we can find a blog post talking about the three CVEs
https://blog.sonarsource.com/cachet-code-execution-via-laravel-configuration-injection
The first one `CVE-2021-39172 - Remote Code Execution` requires a poc and the redis service to be reachable which in this case doesn't fit in our scenario and the third one which is `CVE-2021-39173 - Forced Reinstall` didn't worked as well so this leads us to `CVE-2021-39174 - Configuration Leak` which can leak the variables in `.evn` file, so checking out what the env file would have
https://docs.cachethq.io/docs/installing-cachet
## Foothold
We can leak variables `APP_KEY` which can be useful for getting a reverse shell but since there wasn't any straight forward way or proof of concept in the blog to either leak the env variables or to get a reverse shell with this but anyways here's how we were able to leak the env variables (after a lot trial, error and swearing )
First we need to intercept the request when saving the values in mail configuration
Here we can see post parameter `mail_driver` so we need to change this parameter's value to `${APP_KEY}` and after that hit the `test` button which will get tested and the APP_KEY value will get stored in the logs
After this we will be shown a 500 status code but it's okay, after checking the logs we'll see that it has leaked the value of APP_KEY
But I wasn't able to figure out how would I use this to get a reverse shell so going back to see the default env file we can try leaking the password vairable, `DB_PASSWORD` is the one which seems promising
We can try using this password for the usernames we got from the /users endpoint from let's chat api
From which the password from DB_PASSWORD worked on `will`
Running `sudo -l` to see what we can run as root user
## Privilege Escalation
There wasn't anything else I could think of other than running `pspy` to see what cron jobs or processes was running as root user, so after transferring pspy we can see a script being ran `/opt/mdm/verify.sh` as root user
Starting with this script first it will check for apk file in `/opt/mdm/apk_bin` and will run a for loop to read all apk files in this directory and generate a 12 character long hex value using `openssl` so the filename becomes unique, after renaming it will move the apk file to `/root/mdm/apk_bin`
After moving the apk file, it will perform three checks on the apk file
The first check `sig_check` will check if apk is signed or not using `jarsigner`, if it isn't will ignore the apk by running the cleanup function which will remove the apk and the folder created for that apk
The second function `comp_check` ,will run `apktool` to decompile the apk with `d` and with `-s` will decode file resources to read the `AndroidManifest.xml` file to check the sdk version which should be greater then 18 meaning should be compatible with android version 4 and above it fails this check then it would run cleanup function and delete the file.
The third function `app_check`, it will check application name from `strings.xml` that it must have "Catch" in it doesn't matter what contains before or after it and will run shell command after piping it to `xargs`
```bash
echo -n $APP_NAME|xargs -I {} sh -c 'mkdir {}'
```
Which means that we can do command injection in the application name, so what we need do here is modify the catch1.0.apk that we got from the website, decompile it using apktool and change the application name, make sure to use the updated apktool which is 2.6.1 because buldiing the application after decompiling the resources wouldn't work with apktool 2.5.0
https://github.com/iBotPeaches/Apktool/releases/tag/v2.6.1
And to make apktool 2.6.1 to execute directly, remove the one from /usr/bin/, since this is a jar file we can convert it to executable by following this
https://stackoverflow.com/questions/44427355/how-to-convert-jar-to-linux-executable-file
This step isn't really needed it's just what I found useful for future purpose
After decompiling the apk, we can find strings.xml in `./res/values`
Here we have placed a simple command injection to make bash a SUID binary, after that we need to compile the apk by using `apktool b ./folder`
The apk file will be saved in `dist` folder
We still need to sign it, jarsigner will show that this apk file is unsigned as we have modified this apk
Following this post from stackoverflow
https://stackoverflow.com/questions/10930331/how-to-sign-an-already-compiled-apk
```bash
keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
```
After generating keystore file, we can use jarsigner to sign the apk
```bash
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore catchv2.0.apk alias_name
```
Running jarsigner again to check if the apk is signed
Transferring the apk file on the machine
Within a minute we'll see that bash has a SUID and we can then become root user by running bash with `bash -p`
## References
- https://github.com/sdelements/lets-chat/wiki/API
- https://blog.sonarsource.com/cachet-code-execution-via-laravel-configuration-injection
- https://docs.cachethq.io/docs/installing-cachet
- https://github.com/iBotPeaches/Apktool/releases/tag/v2.6.1
- https://stackoverflow.com/questions/44427355/how-to-convert-jar-to-linux-executable-file
- https://stackoverflow.com/questions/10930331/how-to-sign-an-already-compiled-apk