This challenge is part of the misc category:

freya
Misc (200 pts)
-------------------
We've traveled back far, but this protocol looks familiar...
Our reconnaissance team did a great job, they got us a data capture
from the currently running systems and a private key
from the server (shell.woo.pctf which resolves to 54.226.73.167).
Take  a look at the traffic our reconnaissance team picked up, and see if you
can get access to The Plague's server, at 54.226.73.167.

with the following four files:

• freya.pcapng
• freya_cert.pem
• freya_priv.pem
• password

The task is pretty simple - somehow get access to shell.woo.pctf, probably by using ssh.

The first file I looked at was the password file, which just contains ‘shellpls’. Sadly this isn’t the password for any ssh account on the target server but at least we know that we probably somehow need to use this one to get access:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Bummer. That would’ve been too easy. What about freya_cert.pem and freya_key.pem? Looking at them reveals that they are a self-signed SSL certificate for shell.woo.pctf and the corresponding private key. That’s not very useful right now though since we are not trying to MITM some server - we just want a shell!

The first useful hint is the permission denied line given by ssh, specifically the supported authentication methods: publickey,gssapi-keyex,gssapi-with-mic. publickey is your usual ssh keys and while we could convert freya_priv.pem to one of those and try to login the other two methods are a lot more interesting: gssapi-keyex,gssapi-with-mic. A quick google search tells that this is usually used in combination with Kerberos, which can be set up as a central authority server which handles the authentication and then is able to delegate clients to different services without requiring to enter your credentials again. All we need to find out is where this Kerberos server is and how we’re supposed to login.

Time to look at the last file freya.pcapng with Wireshark. Just scrolling through the captured packets reveals the following TCP streams:

• Two HTTPS connections to shell.woo.pctf
• A SSH connection to shell.woo.pctf

And luckily we have the SSL private key for those HTTPS connections. It’s even better that they do not use perfect forward secret cipher modes - we can just use Wireshark to decrypt the whole PCAP and read the plaintext communication.

This is the first POST request:

00000000  50 4f 53 54 20 2f 6b 6b  64 63 70 20 48 54 54 50 POST /kk dcp HTTP
00000010  2f 31 2e 30 0d 0a 43 61  63 68 65 2d 43 6f 6e 74 /1.0..Ca che-Cont
00000020  72 6f 6c 3a 20 6e 6f 2d  63 61 63 68 65 0d 0a 50 rol: no- cache..P
00000030  72 61 67 6d 61 3a 20 6e  6f 2d 63 61 63 68 65 0d ragma: n o-cache.
00000040  0a 55 73 65 72 2d 41 67  65 6e 74 3a 20 6b 65 72 .User-Ag ent: ker
00000050  62 65 72 6f 73 2f 31 2e  30 0d 0a 43 6f 6e 74 65 beros/1. 0..Conte
00000060  6e 74 2d 74 79 70 65 3a  20 61 70 70 6c 69 63 61 nt-type:  applica
00000070  74 69 6f 6e 2f 6b 65 72  62 65 72 6f 73 0d 0a 43 tion/ker beros..C
00000080  6f 6e 74 65 6e 74 2d 6c  65 6e 67 74 68 3a 20 31 ontent-l ength: 1
00000090  38 34 0d 0a 0d 0a 30 81  b5 a0 81 a6 04 81 a3 00 84....0. ........
000000A0  00 00 9f 6a 81 9c 30 81  99 a1 03 02 01 05 a2 03 ...j..0. ........
000000B0  02 01 0a a3 0e 30 0c 30  0a a1 04 02 02 00 95 a2 .....0.0 ........
000000C0  02 04 00 a4 7d 30 7b a0  07 03 05 00 50 00 00 10 ....}0{. ....P...
000000D0  a1 10 30 0e a0 03 02 01  01 a1 07 30 05 1b 03 70 ..0..... ...0...p
000000E0  70 70 a2 0a 1b 08 57 4f  4f 2e 50 43 54 46 a3 21 pp....WO O.PCTF.!
000000F0  30 1f a0 03 02 01 01 a1  18 30 16 1b 04 68 6f 73 0....... .0...hos
00000100  74 1b 0e 73 68 65 6c 6c  2e 77 6f 6f 2e 70 63 74 t..shell .woo.pct
00000110  66 a5 11 18 0f 32 30 31  34 30 34 31 33 30 32 33 f....201 40413023
00000120  37 35 35 5a a7 06 02 04  10 93 a2 30 a8 14 30 12 755Z.... ...0..0.
00000130  02 01 12 02 01 11 02 01  10 02 01 17 02 01 19 02 ........ ........
00000140  01 1a a1 0a 1b 08 57 4f  4f 2e 50 43 54 46       ......WO O.PCTF

and here’s the reply:

00000000  48 54 54 50 2f 31 2e 30  20 32 30 30 20 4f 4b 0d HTTP/1.0  200 OK.
00000010  0a 43 6f 6e 74 65 6e 74  2d 74 79 70 65 3a 20 61 .Content -type: a
00000020  70 70 6c 69 63 61 74 69  6f 6e 2f 6b 65 72 62 65 pplicati on/kerbe
00000030  72 6f 73 0d 0a 43 6f 6e  74 65 6e 74 2d 6c 65 6e ros..Con tent-len
00000040  67 74 68 3a 20 33 32 37  0d 0a 0d 0a 30 82 01 43 gth: 327 ....0..C
00000050  a0 82 01 3f 04 82 01 3b  00 00 01 37 7e 82 01 33 ...?...; ...7~..3
00000060  30 82 01 2f a0 03 02 01  05 a1 03 02 01 1e a2 11 0../.... ........
00000070  18 0f 31 39 37 38 31 30  32 34 32 30 35 39 32 38 ..197810 24205928
00000080  5a a4 11 18 0f 32 30 31  34 30 34 31 32 30 32 33 Z....201 40412023
00000090  37 35 36 5a a5 05 02 03  0e d8 e1 a6 03 02 01 19 756Z.... ........
000000A0  a7 0a 1b 08 57 4f 4f 2e  50 43 54 46 a8 10 30 0e ....WOO. PCTF..0.
000000B0  a0 03 02 01 01 a1 07 30  05 1b 03 70 70 70 a9 0a .......0 ...ppp..
000000C0  1b 08 57 4f 4f 2e 50 43  54 46 aa 21 30 1f a0 03 ..WOO.PC TF.!0...
000000D0  02 01 01 a1 18 30 16 1b  04 68 6f 73 74 1b 0e 73 .....0.. .host..s
000000E0  68 65 6c 6c 2e 77 6f 6f  2e 70 63 74 66 ab 10 1b hell.woo .pctf...
000000F0  0e 4e 45 45 44 45 44 5f  50 52 45 41 55 54 48 ac .NEEDED_ PREAUTH.
00000100  81 91 04 81 8e 30 81 8b  30 0a a1 04 02 02 00 88 .....0.. 0.......
00000110  a2 02 04 00 30 63 a1 03  02 01 13 a2 5c 04 5a 30 ....0c.. ....\.Z0
00000120  58 30 14 a0 03 02 01 12  a1 0d 1b 0b 57 4f 4f 2e X0...... ....WOO.
00000130  50 43 54 46 70 70 70 30  14 a0 03 02 01 11 a1 0d PCTFppp0 ........
00000140  1b 0b 57 4f 4f 2e 50 43  54 46 70 70 70 30 14 a0 ..WOO.PC TFppp0..
00000150  03 02 01 10 a1 0d 1b 0b  57 4f 4f 2e 50 43 54 46 ........ WOO.PCTF
00000160  70 70 70 30 14 a0 03 02  01 17 a1 0d 1b 0b 57 4f ppp0.... ......WO
00000170  4f 2e 50 43 54 46 70 70  70 30 09 a1 03 02 01 02 O.PCTFpp p0......
00000180  a2 02 04 00 30 0d a1 04  02 02 00 85 a2 05 04 03 ....0... ........
00000190  4d 49 54         

It’s a POST request to shell.woo.pctf/kddcp with a Content-Type of application/kerberos. By just searching for kkdcp you’ll stumble across the MS-KDCCP protocol which has a freely available specification that matches up with the those POST requests. They negotiate a key delegation of the principal (read: login name) ppp in the realm WOO.PCTF for the host shell.woo.pctf.

With all this combined we can setup our local machine with a Kerberos client to repeat this process. It turns out that we’re going to need a special version of krp5 with support for MS-KDDCP over SSL from the branch http of https://github.com/nalind/krb5. On top of that I patched the ssl_verify_callback in src/lib/krb5/os/sendto_kdc.c to always return 1 because freya_cert.pem is not signed by some certificate authority.

Compiling and installing this library is straight forward:

git clone https://github.com/nalind/krb5.git
git checkout http
cd src; ./util/reconf --force
# edit ssl_verify_callback
./configure
make
make install

Now configure it for the WOO.PCTF realm in /etc/krb5.conf

[libdefaults]
        dns_lookup_kdc = false
        dns_lookup_realm = false
        plugin_base_dir = /home/cvopt/krb5/src/plugins
        default_realm = WOO.PCTF
        canonicalize = true

[realms]
        WOO.PCTF = {
                kdc = https://shell.woo.pctf:443/kkdcp
                default_domain = shell.woo.pctf
        }

[domain_realm]
        .woo.pctf = WOO.PCTF
        woo.pctf = WOO.PCTF

[logging]
        kdc = CONSOLE
        default = CONSOLE

and create entries in /etc/hosts for woo.pctf and shell.woo.pctf both pointing to the given IP address. We can finally login to the kerberos server now with the password ‘shellpls’ :

$ kinit ppp
$ klist
Default principal: ppp@WOO.PCTF

Valid starting       Expires              Service principal
13.04.2014 20:51:08  14.04.2014 20:51:00  krbtgt/WOO.PCTF@WOO.PCTF

And then just use

$ ssh -K ppp@shell.woo.pctf

to grab the flag “M1T&H31MD4L&M1CR0$0FT&SH1SH1”.