[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 5 Dec 2011 21:17:09 -0600
From: "JimF" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: Re: cracking RADIUS shared secrets with john the ripper
>I had suspected this at one time, but when testing with gdb and the
>following line, which I have intentionnaly modified so the hash is
>'unsolvable' :
>crack:$dynamic_1008$af25d95ad759e0f43921be2782d10b74$HEX$7ae3c680caee7171e28e0409b2e2f3ab
>seting a break point to dynamic_fmt.c:set_salt, I have seen set_salt
>is called 3 times with the $HEX$ salt (and 48 times with the example
>that is listed in the relevant section in dynamic.conf), and after
>that john is runing uninterrupted; so I assumed it was ok. Maybe this
>is due do the fact that I use dynamic_>1000 as opposed to the
>internals dynamic_n formats ?
You have to have multple lines (i.e. multiple salts), before this makes any difference. If john runs a salted format, and there is only one salt, it switches into a 'non-salted' method of attack. But if you run this file:
crack:$dynamic_1008$af25d95ad759e0f43921be2782d10b74$HEX$7ae3c680caee7171e28e0409b2e2f3ab
crack:$dynamic_1008$bf25d95ad759e0f43921be2782d10b74$HEX$7ae3c680caee7171e28e0409b2e2f3bb
crack:$dynamic_1008$cf25d95ad759e0f43921be2782d10b74$HEX$7ae3c680caee7171e28e0409b2e2f3cb
crack:$dynamic_1008$df25d95ad759e0f43921be2782d10b74$HEX$7ae3c680caee7171e28e0409b2e2f3db
crack:$dynamic_1008$ef25d95ad759e0f43921be2782d10b74$HEX$7ae3c680caee7171e28e0409b2e2f3eb
crack:$dynamic_1008$ff25d95ad759e0f43921be2782d10b74$HEX$7ae3c680caee7171e28e0409b2e2f3fb
Then I think you will see that set_salt is called much more frequently.
> However, the caveat here is, 'can' these salts contain NULL bytes? If so, then we either have to do the work like you have it done, or have the salt returned be like a Pascal string (length prepended to the string of bytes). Other than this 'possible' change, I think this addition to dynamic is good.
>The salts used in the RADIUS protocol, which is why I wrote the patch
>can and do contain NULL bytes, unfortunately. Is this pascal string
>format already taken into acount in other parts of john?
No, it would simply be the format for salts used in dynamic. If I were to make this change, it would be wholesale, all salts in dynamic would be done this way.
#pragma pack(1)
struct dynamic_salt
{
ARCH_WORD_32 length; // or possibly unsigned char length;
char String[1];
};
#pragma pack()
Then I would alloc length of salt+sizeof(ARCH_WORD_32) bytes for the hash, set the length, then memcopy the data into the String value. Within set_salt, I would memcpy from String to cur_salt, and set salt_size based upon length. I would also want to look into this, and if there is no place in dynamic which does *dest++ = *salt++ type moving (32 bits at a time), then we might be able to make the length value 1 byte. The reason for 4 bytes, is so that the start of String is ARCH_WORD_32 aligned. If we would not have to keep that, then 1 byte length is more than enough.
> in other
>words, If I change the patch to use salt() and return a pascal string,
>are there other changes needed than in the salt() and valid()
>functions ?
There will be other changes, indeed. What you have laid out in 1.7.8 is probably adequate at this time. I will get things put together shortly on the bleeding edge updates in 1.7.9, and will look at all the nuances needed to change from NULL terminated C strings, to Pascal style strings to store the salt values. I have an idea that may be a change which ends up having some slightly ugly parts to it. If you want to have a shot at changing valid, to account for the 'real' length of the salt (vs the string representation), then have a go. That change should be localized to valid, I think. Also any changes you make there will be super easy to put into the bleeding edge 1.7.9 jumbo's, likely a straight re-diff, to get the proper line numbers.
>I did not bother to change the valid() function, because using
>dynamic_>1000, I did not specify a fixed length so I expected that it
>would not cause trouble. And anyways, I could even have specified in
>the config file a fixed len of 4 (the size of HEX$) + double the
>length of the salt, to pass the check.
That is due to the hashes within the dynamic.conf have not been 'bullet-proofed'. The reason for setting limits on the lengths, is that during the running of the dynamic, it makes NO boundary checks for overflows, etc. So, in MMX mode, we can have a max of 55 bytes. So, for a specific format, we allow passwords up to 32 bytes, and that gives us 23 bytes left. So we set that as the max salt length. If we do not do this, then we can easily end up with overflows. What happens on an overflow, is that it can 'damage' the password we are working on. It can also damage a password in the next MMX block (or overwrite random memory, if this is the last block). Also, worse, is it can damage finding the right password in that 'slot'. Thus, keeping the lengths under control is VERY critical. The test suite was how we found these type problems. However, I have not spent any time bullet proofing the dynamic.conf formats.
>> once this is added, we could add $HEX$hex_salt to any salted format, and it should be 'happy' with it.
>
>I might modify the patch later to comply with this, for now this patch
>fulfill my needs I guess (except if I'm wrong on the set_salt vs salt
>part). Of course, if anyone wants to improve the patch by applying
>your suggestion, I have nothing against it .
I will certainly take whatever you end up with, and expand upon it inside 1.79. I am not coding to 1.78 at this time, so getting this as a patch there is a good thing, since there is no jumbo patch yet for 1.79. This request had been made before, and I knew it was needed, but did not have a good idea on how to achieve it. The way you have put it together works really well. I think I will also expand upon this and do it for user name, salt 2, and F1 to F9
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
