GitHub
Page cover

Week 1. Resource

TL;DR

This is an Ubuntu 22.04 machine used by an IT team. The host runs a web server where the users can open IT tickets and upload ZIP files. This functionality is vulnerable to PHAR deserialization and this allows us to gain a foothold in the system. Then we move laterally to another user with credentials found in the file system, and move laterally again to collect the user flag with an old CA key pair found in the system. Regarding escalation, we have to move laterally between users. First we use a local API that signs key pairs for different roles (principals). Eventually, we land in an user environment whose sudo configuration permits running an script vulnerable to wildcard injection. Abusing this we finally get a root shell.

KEYWORDS

PHAR deserialization, RSA key pairs, Certification Authority, ssh-keygen.

REFERENCES

https://pentest-tools.com/blog/exploit-phar-deserialization-vulnerability

ENUMERATION

Port scan.

> nmap $target -p- --min-rate=5000 -Pn --open --reason
Starting Nmap 7.93 ( https://nmap.org ) at 2024-08-10 08:19 EDT
Nmap scan report for 10.10.11.27
Host is up, received user-set (0.044s latency).
Not shown: 65221 closed tcp ports (conn-refused), 311 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE      REASON
22/tcp   open  ssh          syn-ack
80/tcp   open  http         syn-ack
2222/tcp open  EtherNetIP-1 syn-ack
 
Nmap done: 1 IP address (1 host up) scanned in 12.31 seconds

Enumerate the open ports.

Add to hosts file and inspect the site with Firefox. An IT ticket management site appears, you can register a new user and login.

The application allows users to create tickets, and offers the possibility of uploading ZIP files.

Let's prepare a PHP reverse shell, compress as ZIP and upload using the application. Take note of the name of the PHP file (shell.php), it will be needed later. Once it is uploaded, you can open the ticket and check the ZIP file upload path by hovering the mouse over the ZIP file.

USER

We will make the backend render the PHP reverse shell by means of phar:// stream wrapper. More info about PHAR deserialization here: https://pentest-tools.com/blog/exploit-phar-deserialization-vulnerability

Start a listener on port 1919 and exploit the PHAR deserialization vulnerability by entering this URL.

http://itrc.ssg.htb/?page=phar://uploads/754e02cda5cec4129027294f3a8f7e52bccfaa80.zip/shell

The payload must include the path to the ZIP file plus the name of the PHP reverse shell file without extension. In this case, shell file is called shell.php, so we just append shell at the end of the payload.

A reverse shell for user www-data is received on port 1919.

Navigate to /var/www/itrc/uploads, there is a bunch of ZIP files there. Unzip the file c2f4813259cc57fab36b311c5058cf031cb6eb51.zip there is a .har file inside.

It is in the HTTP server root folder, so you can browse it with Firefox here: http://itrc.ssg.htb/uploads/itrc.ssg.htb.har

Inside the file there are credentials for user msainristil:82yards2closeit

Use them to SSH into the host.

This shell is not valid for the user flag, so next step is to find another user to move laterally. Enumerate the system users with an associated shell.

The only option left is to move laterally to user zzinter

In the home folder there is an old certification authority key pair.

Let's create a new key pair for user zzinter and sign them with the CA private key.

First, exfiltrate the CA key pair to Kali with scp

Now then create a new key pair in Kali.

Now sign the public key for zzinter (flag -n) using the CA private key (-s flag). An additional flag -I is needed and indicates user's identity, typically an email address, but anything can be specified in this field.

Now you can open an SSH session as zzinter

And retrieve the user flag.

ROOT

Start from the low-priv zzinter shell and take the opportunity to enumerate the system.

Let's have a look at the sign_key_api.sh script in the home directory.

Looks like a script to sign public keys with an internal API assigning then certain allowed roles (principals).

The syntax is: ./sign_key_api.sh <key.pub> <username> <principal>

Where the values allowed for <principal> are: webserver, analytics, support or security

One interesting thing is that this script is owned by root, so we cannot run it in the host.

So we have 2 options, first option would be to exfiltrate the script with scp so we can sign our own public keys locally in Kali.

The second one would be to take note of the curl command at the end, add signserv.ssg.htb to hosts file and sign our public keys remotely with curl

Let's test the script, first generate a key pair in the host.

Exfiltrate the key pair to Kali.

Now sign the keys remotely using the API with curl choosing support principal and inspect the output.

It seems the API outputs a signed certificate containing the public key. Copy the certificate as support.cert and use it to connect to the host as user support (use port 2222).

Notice the hostname has changed, so let's enumerate again the user and the system.

In the new shell, move to /etc/ssh/auth_principals, there we see all the possible principals we can use to sign certificates.

It seems we can request also root_user and zzinter_temp principals, so let's follow the same procedure as used for support principal.

Generate a key pair in the host, transfer to Kali and sign the certificate using the API.

This time it didn't work, it seems generating certificates for root is disabled for security reasons. Let's try for zzinter_temp principal.

In this case the certificate is correctly generated for zzinter_temp. Copy as zzinter_temp.cert and update permissions. Then use it to connect to the host, we receive a shell as user zzinter

Enumerate sudo configuration for current user.

Enumerate the script /opt/sign_key.sh

This code is vulnerable to wildcard injection, similar to what we found in Week 6. Codify (Season 3). The vulnerable part of the code is here:

Basically, the script takes the ca_file entered by the user in the arguments and compares it with /etc/ssh/ca-it, but a double square bracket is used for the comparison, meaning that the statement will be true in the case we use wildcards in the ca-file

For example, both strings "ABCDEFGH..." and "A*" will be evaluated as true. Note that this will not happen if we use single square brackets.

The following Python script is similar to what we did inWeek 6. Codify (Season 3), and it dumps the contents of the /etc/ssh/ca-it file.

Copy to the host and run, shortly after the root private key is bruteforced.

Use it to generate a root certificate as we done before and login to collect the root flag.

You are root.

PreviousSeason 6NextWeek 2. Sea

Last updated