[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120523210410.GA18484@debian>
Date: Thu, 24 May 2012 01:04:10 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: UI for MJohn
On Wed, May 23, 2012 at 03:46:59AM +0200, Frank Dittrich wrote:
> On 05/17/2012 09:10 PM, Aleksey Cherepanov wrote:
> > During the contest we used mailing list and irc channel for
> > everything: to talk about attacks, to track attacks in run, to
> > coordinate.
>
> IMO, one problem was that team members didn't participate as much (or as
> effective) in the communication as would have been desired.
> Some users (me included) didn't use the IRC channel, some didn't even
> use the mailing list.
There were a member of other team on irc so it was not too bad.
> This is what made coordinating and avoiding duplicate effort somewhat
> difficult.
>
> I don't want to blame those users. Probably they had good reasons.
> May be the existing communication channels were not considered to be
> that useful by all team members.
> May be it was just more fun trying out own ideas instead of coordinating
> with others.
>
> 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.
> 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.
> > The latter could be grouped to or
> > even fill attack's description. I think there should be a separate
> > place for each attack and related talks.
>
> 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).
> Usually you have:
> -file with password hashes (or some subset)
> -hash format (may be we decide to make sure each file just contains
> hashes of one format, but in a contest scenario there might be ambiguous
> hash formats and you don't know which hash belongs to which format)
--format key with hash file certainly describes set of hashes for
certain attack.
> -general attack type:
> --single
> --wordlist
> --incremental
> --external
> --markov
>
> Depending on the general attack type, you have additional parameters:
> -word list file
> -rule[s] (or a List.Rules subsection (of an existing config file) with a
> list of rules
> ...
>
>
> 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. But we need an ability
to add attack description without a wrapper for those who do not want
to run it and for case of some problems.
Other approach is to employ johnny for that: user picks options in
johnny, johnny calls wrapper, wrapper sends information to the server.
Though johnny should be improved to support all options.
Wrapper support suggesting attacks without a real run.
> -list of rules. e.g.:
> l
> cQ
> $[120-9]
>
> Alternatively, we could require that the user uploads a particular
> config file (or just copies the config file contents from the clipboard)
> and specifies command line options.
>
> The server could provide some templates for minimal config files
> depending on the attack type, e.g., a config file for --wordlist=
> doesn't need any Incremental sections.
>
> 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: wrapper reports fail of
attack as soon as it is started (if attack is added through web then
it will not be immediate after attack definition), for suggest only
mode we could run check you described instead of real run (though both
attack and fail will be reported because other members could help in
this case, also it could provide an information about common
mistakes).
> 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
and here user presses tab and bash inserts all keys for attack
old_name into command line so user could adjust anything. Other
approach is to apply only keys that should be adjusted, i.e.
$ wrapper --modify-attack=old_name --name-attack=new_name --wordlist=asdf
to adjust wordlist to be asdf. Though it seems less intuitional for
me.
> E.g., when a particular attack was successful, a user might want to try
> the same attack on a different set of hashes, or the same set of rules
> with a different (larger) word list, and so on.
>
> > Also attack status should be
> > shown there. In case of rare status changes they could be posted as
> > messages but when they are frequent it would be more appropriate to
> > show only last status, only current state without history.
> >
> > So my view of this is to have web based ui similar to weblog or forum
> > with updates in head: separate page for each attack with head message
> > for updates and with comments for discussion. Also there could be a
> > global chat for general talks.
>
> 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 but I could not find how to use them for search.
Regards,
Aleksey Cherepanov
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.
