Kerberos AS-REP Cracking

[VbScrub]

Just looking to understand how the cracking of kerberos AS-REP encrypted data works if anyone can explain?

I'm talking about mode -m 18200 and as an example the input for a password of "password123" looks like this:

Code:

$krb5asrep$23$jsmith@SCRM.LOCAL:83ef5dfc031383cf195504c9e07a8733$b70396f4f51eecea3ac23e23c5115ff2b2786eae8211b42e5425f084ed9ed0928468c6f835c92a1da427343f857f5941a610a39661008ce67063d4f79e30b461b47361e7ded199002cb63848b5c00e008fd2cc3f454dc91adad12d94bcba67cc8bf06b7f8807643af587971c129db103a14edde927f470fdbc3a477bf9d1ec22a57a029dbfdf4c6fc075234721ffe96e6513685fbc84ff727d9f6ad1870d3e1534bbabecd888c93f37f57bdcd31baac44a0d5be93cbe7464c637b510b75fd061c315a1251534007223d032c94a70aa96241520e298781f04229bd46f828ea2588a34416060ea4f41

If I've understood the Kerberos RFC correctly (https://tools.ietf.org/html/rfc4120) then the actual data contained in this cipher is:

Code:

EncKDCRepPart  ::= SEQUENCE {
          key            [0] EncryptionKey,
          last-req        [1] LastReq,
          nonce          [2] UInt32,
          key-expiration  [3] KerberosTime OPTIONAL,
          flags          [4] TicketFlags,
          authtime        [5] KerberosTime,
          starttime      [6] KerberosTime OPTIONAL,
          endtime        [7] KerberosTime,
          renew-till      [8] KerberosTime OPTIONAL,
          srealm          [9] Realm,
          sname          [10] PrincipalName,
          caddr          [11] HostAddresses OPTIONAL
  }

So I'm just curious how exactly does hashcat know when it has got the correct password? 

I believe the sname property mentioned above will contain the same principal name that is being passed in to hashcat right before the hash (jsmith@SCRM.LOCAL in my example). So is hashcat comparing that passed in value to the decrypted sname value with each cracking attempt? 

I had a quick look at the hashcat source code here: https://github.com/hashcat/hashcat/blob/...le_18200.c

But although I can usually follow C/C++ ok for the most part, here I can't see where its actually doing anything like what I mentioned above. In fact all it seems to do is just parse the input and set some properties. Doesn't seem like it actually checks anything or decrypts anything at all, so I must be missing something. Is there somewhere else in the source code that handles that, and if so how do I find it? 

Sorry for probably very noob question and thanks in advance

[undeath]

the code you're actually looking for is here: https://github.com/hashcat/hashcat/blob/...a0-pure.cl

[philsmd]

The algorithm is of course implemented in OpenCL code: https://github.com/hashcat/hashcat/blob/...a3-pure.cl

You could also look at the perl test module: https://github.com/hashcat/hashcat/blob/...pm#L28-L80

[VbScrub]

Thanks for the quick replies guys, much appreciated.

I've had a good look at that OpenCL code you linked to but still struggling to wrap my head around it. Especially as I can't seem to see where where some of the parameter values are coming from. Probably just my C noobness, sorry. If anyone does understand how this format in particular is handled and fancies explaining it to me then that would be great, but no worries if not.

Looking at the perl module, I can't tell if this is just for generating a test hash for the main program to try and crack or if this is actually the routine that tests if passwords are correct? I mean I see this part:

Code:

my $check_correct  = ((substr ($ticket_decrypt, 16, 4) eq "7981" && substr ($ticket_decrypt, 22, 2) eq "30")) ||
                         ((substr ($ticket_decrypt, 16, 2) eq "79") && (substr ($ticket_decrypt, 20, 2) eq "30")) ||
                         ((substr ($ticket_decrypt, 16, 4) eq "7982")  && (substr ($ticket_decrypt, 24, 2) eq "30"));

which is obviously checking for specific values at specific points in the decrypted output. But is this just for the test module using a specific password or something so it knows these characters should always be in the result. Or is this exactly the same as what the program does to decide if the hash has been cracked?

[philsmd]

the decrypted bytes do have a specific structure:
https://github.com/hashcat/hashcat/blob/...#L157-L167

[VbScrub]

the decrypted bytes do have a specific structure:
https://github.com/hashcat/hashcat/blob/...#L157-L167

Ah ok thanks. I did see that comment and thought that might be the case originally, especially as some of the values its looking for matched with the perl script. But then the fact that the code in that function carries on for so long afterwards made me think it can't be the final part where it checks to see if the hash has been decrypted correctly.

So what are the extra 100 lines of code after that doing?

[VbScrub]

Oh wait I think I was misunderstanding and thinking that returning 0 indicated success. But now I'm thinking maybe returning 1 is success and 0 means failure. So in that case that check you highlighted is just so early in the function because if those bytes are not set correctly at that point, there's no point going any further and checking the checksum etc. Is that about right?

[philsmd]

yes, early reject optimizations