Ticket Granting Ticket forge

Remi Ferrand remi.ferrand at cc.in2p3.fr
Fri Oct 2 12:58:23 EDT 2009


Ken Raeburn a écrit :
> You would need the key for the krbtgt/YOUR.REALM at YOUR.REALM principal 
> in order to do this.  In fact, with that key, you can forge a TGT for 
> any client principal at all, without needing an existing TGT, so if 
> anyone else gets their hands on it, your realm's security is 
> compromised.  So unless your local machine is secure enough that you 
> could run a KDC on it, this would be a really bad idea.  And even 
> then, running a KDC as root is probably a better idea than leaving the 
> TGS key sitting around accessible under your regular account.
>
> Ken
I'm sure I'm very close of my goal, but it's still not working ...

My KeyTab has been created using :
# kadmin.local -q 'ktadd -k /tmp/krbtgt.keytab -norandkey 
krbtgt/TEST.IN2P3.FR at TEST.IN2P3.FR'

My Cache has been feed with
# kinit test

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: test at TEST.IN2P3.FR

Valid starting     Expires            Service principal
10/02/09 18:15:12  10/03/09 04:15:12  krbtgt/TEST.IN2P3.FR at TEST.IN2P3.FR
        renew until 10/03/09 18:15:11


I've written a little program to try to decrypt the TGT.
This program is compiler using those libraries : /-lkrb5 -lkadm5srv 
-lkadm5clnt -lkdb5/

The main steps are :
* read Keytab using krb5_kt_resolve, krb5_kt_start_seq_get, 
krb5_kt_next_entry, krb5_kt_end_seq_get.
    This step gives me a krb5_keytab_entry structure.

* retrieve TGT from Ticket Cache using krb5_cc_default, 
krb5_cc_set_flags, krb5_cc_start_seq_get, krb5_cc_next_cred.
    This step gives me a krb5_creds structure.

* My program then try to decode_ticket using krb5_decode_ticket and 
everything is successful.

* The next step is to decrypt the TGT ticket with krb5_decrypt_tkt_part, 
but I encounter an error of this kind :
    *forge: Program lacks support for encryption type decrypting with 
krb5_decrypt_tkt_part*

Debuging using GDB ensures me that krbtgt entry read from KeyTab has an 
enctype of 16 (Triple DES cbc mode with HMAC/sha1) and the same enctype 
for the ticket granting ticket krbtgt read from cache.

Does anyone already encounter this kind of error using Kerberos V M.I.T 
API ?
Do I have to load ciphers anywhere ?

If you want me to send you my code, juste ask and I'll send you ...

The main part of my code has been inspired from kinit or src/kdc/* 
utilities.

Thanks in advance
Remi

-- 

Remi Ferrand             | Institut National de Physique Nucleaire
Tel. +33(0)4.78.93.08.80 |     et de Physique des Particules
Fax. +33(0)4.72.69.41.70 | Centre de Calcul - http://cc.in2p3.fr/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4055 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20091002/1a923958/attachment.bin


More information about the Kerberos mailing list