[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 May 2012 00:19:26 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: using all available hardware
On 05/14/2012 09:28 PM, Aleksey Cherepanov wrote:
> To make system more simple and to provide support for users that do
> not want to provide full access I proposed approach of a wrapper that
> only reports attacks to the server leaving all management for humans
> themselves.
So the server just keeps track of
-which kind of attacks (cracking mode
(single/wordlist/incremental/markov/external), word list, rules) against
which hashes (hash format(s), password hash files, or part of password
hash file (split by salts) is available
-what sequence of attack has been decided / voted for by users or by
some algorithm (based on previous attacks)
-which attack has been suggested by which user
-which attack has been completed (with what result)
-which attack is currently being processed (already running or
downloaded by a client) by which client
> Also such wrapper will have ability to choose attack
> easily by name/tag/label/uuid/whatever for convenience and to make it
> obvious how to connect attack with its description on the server.
>
> But if user does not pick attacks than his machine is idle so there
> should be an option for auto-picking of attacks. It probably should be
> disabled by default.
Yes, I also think this should be disabled by default.
Otherwise, some over-eager anti-virus software might detect this wrapper
as a kind of malware...
Of course, during a pen test or during the contest we'd like the users
to enable this option, to avoid hardware being idle. So we need to
document how to configure the client/wrapper.
> Also there could be an option for auto-stop of
> attack on some conditions (for instance incremental mode became less
> effective than other probable attacks).
I think the server is in the best position to suggest some kind of
auto-stop condition, because the server keeps track of cracked passwords
of a particular hash type per time (or per number of tried candidate
passwords).
If the attack is stopped, the .rec file should be transferred back to
the server. The server should mark that task as interrupted.
There should be a way to continue this task at a later time (may be when
the overall success rate has dropped significantly.
> Wrapper may prevent users from picking attacks that other user do at
> the same moment. But there should be an option to bypass this check.
There can be several reasons to bypass this check.
1. One client downloaded the attack details a long time ago, but didn't
return any results.
2. If you plan to return intermediate results, say every 10 minutes:
The intermediate results returned by that client indicate that this
client is either overloaded because of too many tasks running running in
parallel, or the particular client is not well suited for the particular
hash type, compared to other hash types.
(E.g., a client using a 32bit OS with a single core trying to crack
passwords for a slow hash type which also has an efficient GPU
implementation.)
3. You just want to occasionally verify the results returned by a
particular client.
> In any case there will be a problem if one user with slow cpu picks
> too many attacks: he could not complete these attacks but prevents (or
> making it harder for) others from doing this attack. So there should
> be checks and advices/warning to not taking too much attacks. They
> may be tricky.
You can try to collect some information of all the available clients
prior to the contest / pen test or as soon as they join:
-build and version information
$ ./john |head -n 1
John the Ripper password cracker, ver: 1.7.9-jumbo-5+unstable
[linux-x86-sse2i]
$ ./john -list=build-info
Version: 1.7.9-jumbo-5+unstable
Build: linux-x86-sse2i
Arch: 32-bit LE
$JOHN is ./
Rec file version: REC3
CHARSET_MIN: 32 (0x20)
CHARSET_MAX: 126 (0x7e)
CHARSET_LENGTH: 8
gcc version: 4.6.3
(only in current git, might even be enhanced by magnum if you need
additional information)
-supported formats (also from john's usage output)
-performance test data
$ ./john --test=1 [--format=]
-hardware
(For Linux systems: contents of /proc/cpuinfo and/or output of lspci [-v]
or other information that can be used to determine which formats should
preferably be attacked by a particular client.
You'd probably need some way to distinguish the individual clients.
At the beginning of a cracking session, the best you can do is probably
serving those clients first which you expect to be fast, given the
performance/build information, suggest tasks for formats with OMP
support for clients built with OMP support enabled, prefer clients with
a supported GPU for hash formats with efficient GPU implementation, and
serve tasks to other clients in some kind of round-robin so that the top
priority tasks are distributed among a large number of different clients.
Certain attacks might need different files on the client side.
So if you don't distribute all sorts of wordlist files prior to the
contest (or pen test), you could also keep track of which client did
already download what file(s) (word list files, password hash files,
...) and consider the files already downloaded by a client when deciding
about the next attack for that client.
The wrapper could also prevent the client from requesting too many tasks
in advance. (IMHO, it is OK to download some more tasks than available
CPU cores, so that a client can immediately start the next attack when
one attack is finished.)
After the first few rounds of returning results, the server could use
the "track record" of particular clients to determine which clients get
the high priority tasks, which clients get tasks of lower priority...
(Of course, the evaluation of time needed to finish a task has to take
into account the number of password candidates to try, the number of
salts/hashes, the hash format, ...)
May be, even more advanced approaches are possible.
More important than implementing the most advanced approach is probably
to just have some kind of a plan to avoid the worst imbalance...
The strategy which hash types to attack in a real-life pen test will
probably be different compared to the strategy during a contest.
(During a pen test, you'll probably attack the weakest hash types first,
then attack harder hash types using information you gained during
cracking the weak hash formats.)
Regards,
Frank
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.
