[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG22aJCmW_H7C4BO=fLkuuc0EtwvYFbH7O91=BDFdjStOh8E6w@mail.gmail.com>
Date: Sun, 4 Dec 2011 20:08:06 +0100
From: Didier Arenzana <darenzana@...il.com>
To: john-users@...ts.openwall.com
Subject: cracking RADIUS shared secrets with john the ripper
Hi,
I am currently working at using john the ripper to audit RADIUS shared
secrets, using network captures as input.
Two interresting attacks are detailed in the following paper :
http://www.untruth.org/~josh/security/radius/radius-auth.html
They are described in section 3.1 "Response Authenticator Based Shared
Secret Attack" and 3.3 "User-password attribute based shared secret
attack".
RADIUS relies on MD5 to protect passwords; for attack 3.3 I have been
able to use format 'dynamic_1' (joomla), which implements md5($p.$s) :
I wrote a perl script to extract information from the network capture
files, and dump it to the 'dynamic_1' format. However, I came across
one problem : The salts expected by john are 'printable', so they can
be stored in native form in the passwd file. Here, the salts are
string of 16 bytes that can be of any value. So I wrote a patch to
function 'set_salt' in dynamic_fmt.c that does the above: if the salt
begins with the string 'hx', then it expects it in base16 format, and
converts it. (it appears there is also a maximum length for the salt
in the file, so I could use 'hx', but not 'hex' for the prefix). I
have been able to use it successfully with my own-generated test
capture files, and john found a trivial shared secret almost
instantly.
So here comes my first question : Is there a better solution than
using this patch ? I'd be happy to share the patch and the perl script
with the community, but I want to check first if there is a better
solution.
I will now try to implement attack 3.1, and I have already written a
dynamic format in john.conf to handle md5($s.$p) ; and I have another
question : the salt being first in the concatenation, will john be
smart enough to pre-compute the MD5-state for salt, and apply it to
all the candidate passwords? Is it of any interrest to implement such
a method by another patch in the source code?
And, one last question: using this method results in password files
with multiple times the same original password with different salts.
Is this of any use for john, or does it slow down the process of
finding the password ? (I believe the answer is the latter, but wanted
to check with others). Should I restrict the output to one line per
original password ?
Thanks for reading,
Didier.
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.
