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.