Sandworm

Gaining Access

Nmap scan:

nmap -p- --min-rate 5000 10.129.34.16
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-20 09:54 +08
Warning: 10.129.34.16 giving up on port because retransmission cap hit (10).
Nmap scan report for 10.129.34.16
Host is up (0.25s latency).
Not shown: 56079 closed tcp ports (conn-refused), 9453 filtered tcp ports (no-response)
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

We have to add ssa.htb to our /etc/hosts file to visit the HTTPS site.

Secret Spy Agency -> SSTI

The website promotes an agency for spies:

The contact page allows us to send messages that are encrypted with a key:

If we check out their guide. we would find that the website allows us to view encrypt and decrypt messages using our own key:

At the bottom of the page, we can also see some indication of a user:

So we can import our own keys into the system, and encrypt our own messages. I don't think these messages are being used in any way or sent anywhere, so the decrypting and encrypting messages part is not that interesting.

The most interesting is the function verifying keys using a public key and signed text:

Since there is a user associated with the GPG key, we can try to generate one with a different UID:

Afterwards, we can input some encrypted message to verify that it has been signed properly.

Afterwards, we can take both texts and use the website to verify our signature:

When we click "Verify", it would show that it worked:

This website also seems to print out the username test123 that I have supplied. This parameter might be unsanitised, and vulnerable to OS command injection or something. We can use the --edit-key flag to edit the UID we have specified in the key:

I tried a few payloads for different vulnerabilities, and found that SSTI worked:

A bit more testing revealed that {{7*'7'}} works as well:

I tested both Twig and Jinja2 payloads, and got RCE using this payload:

I tried to execute this, but it didn't work:

What works is a base64 encoded bash reverse shell command since the UID of the key cannot have > or < characters.

Privilege Escalation

Silentobserver Creds

When trying to write some files, I kept getting this error:

Something is blocking us on the machine. There are some other users present on the machine:

Viewing the user's directory reveals a firejail file:

Firejail is a security sandbox which restricts a lot of features, thus explaining why we cannot create files. When looking at the files within this directory, we can find some credentials for the next user:

With this, we can ssh into the next user and grab the user flag:

Tipnet + Cargo

I ran a pspy64 on the machine to view the processes that were running, and found the root user was executing this weird binary:

The source code for this application is in /opt/tipnet/src/main.rs.

It's a pretty long file, but it does nothing of interest. I noticed that this uses an external library called logger, which is located in the same directory as tipnet.

The weird thing is, it seems that we are given write access over this directory. However, the sudo command runs sudo -u atlas before running the command, meaning that we don't get a root shell.

I still did it anyways because there was literally nothing else I could so. Append this code at the top of the function in lib.rs.

This would give us another reverse shell as atlas, but with a different group!

Now we are part of the Jailer group.

Firejail SUID

We now can run firejail as an SUID binary on the machine:

There are firejail SUID binary exploits online. Using this script, we can easily escalate privileges. Just run the script:

Then in another shell:

Rooted!

PreviousRegistryTwoNextSau

Last updated