[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP22763FF1C3C259887B2196EFD060@phx.gbl>
Date: Sun, 27 May 2012 00:57:51 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: UI for MJohn
On 05/23/2012 11:04 PM, Aleksey Cherepanov wrote:
> On Wed, May 23, 2012 at 03:46:59AM +0200, Frank Dittrich wrote:
>> So, if we want better / more effective communication / coordination, we
>> have to make it easy for the users.
>> Either by increasing the perceived value of communication, or by
>> reducing the effort required to communicate.
>
> I think we should hit both points.
>
> While during the contest communication is very important (it even
> helps to communicate and work together later) it could be less
> important for pentesting company.
You are probably right. A team of pen testers probably coordinates
before starting the pen test, because they usually know what to expect.
In a contest, you never know how far away from real-life the task is,
so there will be more need for coordination during the contest.
Also, a team of pen testers working together probably isn't spread
around the world.
>> What is "general coordination"?
>> Coordinating who is making use of which available hardware?
>> Discussing what ad-hoc scripts might be necessary (verifying john.pot
>> lines submitted by team members, detecting patterns, generating
>> candidate passwords for newly detecteed patterns)?
>
> I'd write it more right: I'd split talks into two kinds: talks related
> to certain attack and other talks. Other talks are all talks that does
> not affect (produce or modify) any particular attack.
>
> So other talks include coordinating who is making use of which
> hardware, discussing what ad-hoc script are needed and so on. These
> talks could not be formalized (easily) while talks about attacks have
> similar and formal data (cmd-line and files) as its part.
OK, so I think you should focus on supporting attack related
communication, because for the general discussion, we can use mailing
lists or IRC. A team of pen testers could either communicate directly to
each other or use some other secure form of communication.
>> While it is interesting to be able to connect planned/running/finished
>> attacks with attack descriptions and discussions related to an attack, I
>> think more important is to think about how should an attack be specified.
>
> Attack could be described by command line string and all files
> involved except .pot (it is insufficient for us): config, .rec if any,
> wordlist if any, file with hashes, john binary (rather its version).
For config files, you could even use a stripped down version of the
config file, with all unneccesary sections removed.
For word list files, it would be good to somehow identify already
existing, commonly used word list files, instead of transferring the
same file back and forth for each attack.
>> So may be when specifying the attack, the user has to pick the general
>> attack type using a drop-down list (or may be, the list of general
>> attack types is presented as a list of radio buttons instead), then,
>> depending on the attack type, the user has to specify other parameters:
>> -word list file name, to be selected from a list of existing file names
>> (we might need to provide a way to add new wordlist files)
>
> In johnny I did similar way to set options for john. Though rules as
> below and other contents of configuration file are not available in
> johnny (yet). I think such interface is not hard to implement for
> upload. Though I do not think it is really needed because the
> preferred way to add attack is to run john (under wrapper) for that
> attack and wrapper will send everything itself.
OK, then I misunderstood what the wrapper should do.
I thought it would just request new tasks to be run from the server, and
start those tasks on the client.
But I think it is important for the users to be able to see the attacks
defined by other users, and to see how good those tasks which already
completed were, to be able to either define similar attacks for other
hash types, or to define other attacks on the same hashes (which have
not yet been tried, but might be successful as well).
I don't see how you want to support this workflow with the wrapper.
>> May be we need to verify the attack description is syntactically correct
>> before we allow a client to fetch the description.
>>
>> This can be done on the server, adding --max-run-time=1 and
>> --pot=dummy.pot to the command line and replacing the password hash file
>> with a sample file containing just one hash, to avoid a huge run time
>> and memory consumption for loading large hash files...
>
> I think it could be done on client side
Yes, you are right, if the wrapper is supposed to send new possible
attacks to the server, then verification of those attacks could (and
should) be done by the client.
>> It should also be easy to create new attacks by adjusting a copy of an
>> old attack.
>
> I just imagined following:
> $ wrapper --modify-attack=old_name --name-attack=new_name
In your example, is ol_name the name of another attack defined by the
same user (on he same client), or could it be any attack defined by
another user on another client?
If it is the latter, I assume you thought of letting the user decide the
attacks name.
Of do you distinguish attack defined by several (if not hundreds of)
different users, all naming their attacks test1, test2, and so on?
>> There should also be some way to compare, sort, filter attacks according
>> to various attributes, to detect which attacks were more successful than
>> others...
>
> I'd say this is not a problem because request-tracker has custom
> fields
So you want to define some custom fields which will be populated by the
server (or by the client running the attack) automatically?
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.
