Medussa Usage Guide

Kostas Evangelinos

Revision: 1.2

What's medussa anyway?

medussa is a scalable distributed cracking system supporting remote administration, cipher arbitration. The current version is 0.5Beta, and it has been tested on the following platforms:

Solaris 2.5.1, 2.6, 7
Linux 2.2
Windows NT 4 (using Cygnus's tools; client only)

Objective

This is a stab at producing a distributed cracking system; The objectives can be summarized as follows:

Cross-platform support
Arbitrary keyspace generator functions
Arbitrary cracking methods
Low bandwidth requirements
Reliability
Recovery from network outages
Support for a potentially large number of nodes
Simple communications protocol
Proxyable communications protocol

Initial design decisions

This implementation uses a two tier model, with a single server and a number of nodes. The server's responsibilities include distributing keyspace slices to the nodes and implementing remote administration. The nodes have been kept as simple as possible.

Bandwidth consumption

Distributing keyspace to nodes at first manifests itself as a communication-heavy problem, whereby the keyspace distribution server actually pushes a portion of possible keyspace to the nodes. However, it becomes apparent that by decentralizing the keyspace generation function to the nodes themselves, we only need distribute indexing information on a portion of the keyspace that is relevant to that node.

Connectivity

Although medussa was first conceived to utilize LAN connected hosts, the addition of error recovery to the keyspace distribution server made it possible for loosely connected hosts to be utilised as well.

Installation

Requirements

POSIX threads support
OpenSSL compatible cryptography libraries. openssl-0.9.4, openssl-0.8.2 were used successfully. RSARef might be compatible, slower and buggy.
GNU Multiple Precision library. gmp-2.0.2 was used.

Configuration

Compilation options are handled by a GNU configuration script called configure. The options that are of importance with regard to providing information on external libraries are --with-ssl=/path/to/ssl and --with-gmp=/path/to/gmp. A list of further options supported by the configuration script can be obtained by running ./configure --help.

Compiling/Installing

To compile the software, simply invoke configure with the appropriate options and make. To install, type make install. A successful compile will result in five executables, namely:

[medussa] The key distribution server. It is the only executable requiring pthreads support.

[tentacle] A simple implementation of a node, somewhat suboptimal.

[mecon] The administration console to the server. This is a command line tool.

[testcrypt] Performance tester for the available ciphers.

[showspace] Standalone keyspace generator.

A complete description of available options is beyond the scope of this section.

Architecture

Communications protocol

Cracking as an operation generally dictates the use of a protocol capable to transfer binary data. To keep things simple, it was decided to proceed with a text-based protocol, which is able to support binary transfers by the use of HTTP-like character encoding.

For this implementation, there is no support for out-of-band data, and in fact the server implements two modes of operation: A simple, line-oriented approach is used for nodes and a mutiline approach for remote administration. Limitations such as these present us with a problem when say attempting to implement notifications for key retrievals and will be tackled in future releases.

The protocol is implemented on top of a TCP transport. Support for UDP and other methods is planned.

Arbitration of keyspace generation methods

It was deemed important that, in order to minimize effort in attempting to retrieve a key, the administrator should be able to select keyspace generators to match the cipher. For example, the Unix based crypt() function uses DES with an input of up to 8 7-bit characters. The input is selected by humans (usually) and hence in such a case, it makes sense to test for password weakness by initially employing a dictionary based attack. Conversely, the shared secret in an SSL session is a 128 bit binary string (with 40 unknown in the exportable flavor) which is machine generated. Currently there are three keyspace generation functions implemented:

[binary] Given the number of bytes a cipher key is expected to be, it produces all possible binary combinations.

[dictionary] It produces a rules and dictionary based keyspace, which can be customized further by the use of maximum and minimum character length parameters.

[bruteforce] ASCII based bruteforce keyspace generator. Given a set of ASCII characters, maximum and minimum lengths, it produces all possible keyspace combinations.

It has to be noted that the dictionary based generator supports file transfer over the network for files that do not exist on the nodes.

Arbitration of ciphers

The implementation of the fastest possible DES implementation using assembly code becomes unneccessary when one can just throw more nodes at the problem. Instead, this effort concentrated on making a large number of ciphers available for use, and the obvious choice was OpenSSL's libcrypto, for its fast implementation and well-defined interface. The cipher interface itself abstracts this implementation from the keyspace distributor and allows referral to ciphers by a simple text name.

Supported ciphers at this time are:

Unix crypt
Single MD5
FreeBSD MD5 based crypt
Single SHA1, as used in Netscape LDAP servers

Scheduling of keyspace runs

As mentioned above, one of the design decisions was to provide maximum control over how a cipher gets attacked. To facilitate this, one first defines a hash and then associates a number of schedule runs with it. For example, a Unix crypt based hash can be first attacked using dictionary generators, and then a bruteforce attack. It becomes obvious that a successful run needs to invalidate further runs that refer to the same cipher.

In the same spirit of maximum control, the scheduling function also supports selective node, hash and/or run disabling, deletions and additions.

The need for recovery from malfunctioning/disconnected nodes is covered by supporting automatic cleanup from such cases. In this implementation, the keyspace previously owned by such a node is migrated to one of the live ones as soon as feasible.

This scheduler supports adaptability according to node speed; It will attempt to distribute keyspace accordingly using a linear approximation function which will aim to make all nodes conform to a settable time period between keyspace slices.

In order for the implementation to have a small memory footprint, no historical information is kept on covered keyspace; Instead, each schedule run has a starting, current and ending index. A new request for keyspace is honored by looking at the estimated efficiency of that node and incrementing the schedule's current index. In the case of recovery from dead nodes, a special state is used to keep node information around until that slice can be migrated to a live node.

Minimum disruption to other users

In addition to small demands in network bandwidth, the node software (tentacle) supports lowering its processor priority for minimal disruption to real work being done on machines. It is only really necessary for non adaptive cpu scheduling algorithms, such as the one in Windows NT 4. This parameter amongst others is configurable.

Remote administration

With a system that can run for long periods of time, the ability to remotely check on progress became apparent and hence almost all of the administrative actions have been implemented with remote action in mind. The authentication system is challenge response based, with MD5 as the hashing function.

Not totally dumb nodes

Initializing a keyspace generator can be a costly operation, especially when a dictionary based attack is planned. For this reason, tentacle only initializes generators when the server indicates that the current schedule run requires a different one. Caching of generators may be a better solution for nodes that are free to use a lot of memory but since generator creation happens relatively seldomly, it was deemed unnecessary to implement.

Configuration

The distribution server: Medussa

Main options

Parameter name	Option	Default value	Meaning
bindaddr	-b	0.0.0.0	The address that medussa will bind() to
bindport	-p	5444	The port that medussa will listen on
ident	-i	hostname	The name of the server
verbose	-v	1	Amount of feedback. Can be: [0] Nothing [1] Errors only [2-9] Debugging
N/A	-f	cwd/.medussarc	Specifies the location of the configuration file
N/A	-T	N/A	Configuration variable dump
interactive	-b	1	Whether medussa will background itself
uid	N/A	60001	On background operation, the uid it will run under
gid	N/A	60001	On background operation, the gid it will run under
pidfile	N/A	/tmp/.medussapid	On background operation, the file containing the process id
logmethod	N/A	stderr	Log information. Can be stderr, syslog, file
adminpassword	N/A	None	If set, it enables remote administration
motd	N/A	None	If set, the server offers a message of the day

Configuration file sections

In addition to the above options, medussa supports sections in the configuration file. The special section name downloadable enumerates a list of files that remote nodes are allowed to request for download.

Schedule run definitions

By default, any configuration section describes a hash and the schedules that are meant to run against it. It may have the following components:

Parameter name Meaning

type The type of hash (eg unixcrypt)

hash The hash itself.

schedule* A declaration of a schedule run. The first parameter is the keyspace generator and the second is a comma separated list of options to the generator.

A sample configuration file

#
# Basics
#
verbose 1
adminpassword foo
motd Dysfunctional but persistent
#
# files that can be fetched
#
downloadable {
        words           normal stuff
        rules           normal stuff
        /usr/dict/words         system words file
}


#
# the real business. Stuff to crack
#

# test01
sha2 {
        type sharaw
        hash {SHA}wlp5xXkGunAns204AjDbkrvA/WQ=
        schedule1 bruteforce maxlen=6,poss=tes01sdc
}

The node: Tentacle

Options

Parameter name	Option	Default value	Meaning
server	-s	localhost	The address that tentacle will connect() to
serverport	-p	5444	The port that tentacle will connect() to
ident	-i	hostname	The name of the client, as reported to the server
verbose	-v	1	Amount of feedback. Can be: [0] Nothing [1] Errors only [2-9] Debugging
N/A	-f	cwd/.tentaclerc	Specifies the location of the configuration file
N/A	-T	N/A	Configuration variable dump

The console: Mecon

Options

Parameter name	Option	Default value	Meaning
host	-h	localhost	The address that mecon will connect() to
port	-p	5444	The port that mecon will connect() to
verbose	-v	1	Amount of feedback. Can be: [0] Nothing [1] Errors only [2-9] Debugging

Future work

Module	Task
hashpool	delta queue for events so that nodes can be selectively enabled and disabled according to say time of day
hashpool	switch to hash for nodes and schedule runs
hashpool	serialization of client connects to lessen server load
hashpool	checkpoint to filesystem support
hashpool	node slice might overflow the integer; switch to key_index_t
generator	redesign of the api so that we can batch generate attempts
generator	optimization, get rid of divs, mods, creating and destroying stuff
generator	need to be able to list out generator names being available
cli	optional readline support
cli	help system
method	SSL cracking
method	NT lanman and NT native cracking
method	need to be able to list out method names being available
bruteforce	character frequency tables
hash	massage api so that it looks like an array
tentacle	multiple cpu detection and forking
tentacle	implementation of a tentacle hive: a tentacle proxy
net	optional SSL for transport
net	out of band notifications for successful key retrievals
net	pipelined requests and responses
net	implement support for unreliable transports
net	implement UDP transport
medussa	last modification time support for downloadable files
medussa	Estimate initial cps for each method at startup
mecon	default schedule runs: will only need to supply a hash
mecon	range support for schedules
web server	Write a simple web server for medussa
web server	HTTP as transport, allows the use of nodes behind firewalls
web server	read only status via HTTP, allows remote monitoring

[LaTeX -> HTML by ltoh]

Russell W. Quong (quong@best.com)
Last modified: Dec 19 1999 (LaTeX doc modified: )

Parameter name	Meaning
type	The type of hash (eg unixcrypt)
hash	The hash itself.
schedule*	A declaration of a schedule run. The first parameter is the keyspace generator and the second is a comma separated list of options to the generator.