Pyrit Introduction

Introduction
This document will guide you through your first steps with Pyrit. Before continuing,
you should have Pyrit installed and working. See the Installation-Wiki for details.
You will also need to have Scapy installed, which should come with your distribution or
may be installed from source. Pyrit can use SQLAlchemy to access various kinds of
SQL-databases and you'll need to have it installed if you want to try that feature as
explained below.
You should also take a look at the manual when new commands get introduced below;
more information and details about the features a command provides are given there.
Throughout this tutorial we will refer to files and examples that are distributed together
with Pyrit's source-code. Therefore the first step is to get yourself a copy of the sourcecode tarball, unpack it and switch to the /test-directory:
wget http://pyrit.googlecode.com/files/pyrit-0.3.0.tar.gz
tar xvzf pyrit-0.3.0.tar.gz
cd pyrit-0.3.0/test
You should find three files within this directory that will be of interest for us:
dict.gz is a gzip-compressed wordlist

wpa2psk-linksys.dump.gz is a gzip-compressed dump of a WPA2-PSK
handshake
wpapsk-linksys.dump.gz is a gzip-compressed dump a WPA-PSK handshake
First steps with capture-files and

wordlists
Pyrit can understand packet capture files in pcap-format. These files basically contain
what was captured from the air. Our first meaningful step in this tutorial is to let Pyrit
analyze one of the capture files and give us some information about the content.
Analyzing a capture file

Issue to following command to analyze the file wpapsk-linksys.dump.gz:
pyrit -r wpapsk-linksys.dump.gz analyze
Pyrit should answer with output very similar like the following:
Pyrit 0.3.0 (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+
Parsing file 'wpapsk-linksys.dump.gz' (1/1)...
587 packets (587 802.11-packets), 1 APs
#1: AccessPoint 00:0b:86:c2:a4:85 ('linksys')
#0: Station 00:13:ce:55:98:ef, handshake found

#1: Station 01:00:5e:7f:ff:fa
#2: Station 01:00:5e:00:00:16
Pyrit has successfuly parsed the capture file and found one AccessPoint with BSSID
00:0b:86:c2:a4:85 and ESSID 'linksys' and three Stations communicating with that
AccessPoint. The key-negotiation (known as the fourway-handshake) between the
Station with MAC 00:13:ce:55:98:ef and the AccessPoint has also been recorded in the
capture file. We can use the data from this handshake to guess that password that is used
to protect the network.
Please note that Pyrit can transparently read/write gzip-compressed files; this becomes
very handy when dealing with large wordlists or cowpatty-files that may take hundrets
of megabytes.
Attacking a handshake and revealing the password

We now use the example wordlist dict.gz and let Pyrit guess the password that was used
in the key-negotiation between AccessPoint 00:0b:86:c2:a4:85 and Station
00:13:ce:55:98:ef. The correct password should get detected, if it is part of the list. In
our terms, this is known as a "passthrough-attack". Issue the following command:
pyrit -r wpapsk-linksys.dump.gz -i dict.gz -b 00:0b:86:c2:a4:85
attack_passthrough
This tells Pyrit to take the capture-file wpapsk-linksys.dump.gz and attack the keynegotiation with AccessPoint 00:0b:86:c2:a4:85 using the dictionary-file dict.gz.
Please note that you do not always have to tell Pyrit which AccessPoint to choose from
the capture-file - Pyrit will usually be able to figure that out by itself.
You should get a response very similar to the following:
Tried 4091 PMKs so far; 935 PMKs per second.
The password is 'dictionary'.
We've successfully revealed that the password used to protect the network
00:0b:86:c2:a4:85 is "dictionary"...
Interlude: Stripping a capture-file from unnecessary

cruft
Capture-files are usually simple dumps of the traffic captured directly from the air. For
our purpose, we are only interested in a very tiny fraction of the traffic between
AccessPoint and Station. Pyrit can help reducing the size of a packet-capture file by
analyzing the traffic and throwing away all packets that are of no use for us. We end up
with a new, very small capture file that still holds all valuable information and is
useable with other tools like Wireshark.
Please note that stripping a capture file is not necessary. It's sole purpose is to make life
a little easier when it comes to large capture files.
Our original example has 587 packets and a size of roughly 13kb. Issue the following
command:
pyrit -r wpapsk-linksys.dump.gz -o wpapsk-linksys_stripped.dump.gz
strip
You should get a response like the following:

#1: AccessPoint 00:0b:86:c2:a4:85 ('linksys')
#0: Station 00:13:ce:55:98:ef (1 authentications)
New pcap-file 'wpapsk-linksys_stripped.dump.gz' written (4 out of 587
packets)
The new capture file wpapsk-linksys_stripped.dump.gz has a size of only a few hundred
bytes and contains only three from the key-negotiation (used to attack the password)
and one beacon-frame (used to detect the network's ESSID).
Working with Pyrit's database

As you may already know, guessing the password used in a WPA(2)-PSK keynegotiation is a computational-intensive task. During this process, more than 99.9% of
the CPU-cycles have to be spent to compute what is known as the Pairwise Master Key,
a 256-bit key derived from the ESSID and a password using the PBKDF2-HMACSHA1-algorithm. One of the major weaknesses of WPA(2)-PSK is that the Pairwise
Master Key has no elements that are unique to the moment of the key-negotiation
between AccessPoint and Station. It is therefor possible to pre-compute the Pairwise
Master Key and store it for later use. In the moment of attacking a key-negotiation, we
are left with the remaining 0.1% of what depends on session-unique data. It is therefore
extremely valueable for an attacker to pre-compute large tables of Pairwise Master Keys
for common ESSIDs.
This is where Pyrit's database kicks in. It can store ESSIDs, passwords and their
corresponding Pairwise Master Keys, possibly growing to the size of hundrets of
millions of entries. Starting with a fresh installation of Pyrit, your database will most
probably be empty. Issue the following command to get an overview:
pyrit eval
Pyrit should respond like this:

Connecting to storage at 'file://'...
Passwords available: 0
connected.
Nothing fancy to see here, yet.

Please note the default filesystem-based storage 'file://'. We'll come to SQL-databases
later on.
Populating and batch-processing the database

In order to make the database usefull, we'll populate it with passwords from a wordlist.
Issue the following command:
pyrit -i dict.gz import_passwords
Pyrit will read the file 'dict.gz' and store the wordlist in it's internal database format.
You should get a response like the following:
10202 lines read. Flushing buffers...
All done.
connected.
Please note that you can add more passwords to the database later on; the command
'import_passwords' ensures that duplicates within the wordlist or between the wordlist
and the database are tossed out and not stored again. For now, run the 'eval'-command
again to see how the database has been populated with passwords from 'dict.gz'. You
should get output similar to this:
connected.
You'll notice that Pyrit has only stored 4,078 out of the 10,202 passwords from the file.
Pyrit has automatically filtered passwords that are not suitable for WPA(2)-PSK and
also sorted out duplicates. Now that we have some passwords in the database, we have
to create an ESSID. Issue the following command:
pyrit -e linksys create_essid
... and you'll get an output like this:


Created ESSID 'linksys'
connected.
Run the 'eval'-command again and you'll see that ESSID 'linksys' has been created in the
database:
connected.
ESSID 'linksys' : 0 (0.00%)
The database now contains enough information to start batch-processing it. Pyrit will
take all (ESSID:password)-combinations, compute the corresponding Pairwise master
Keys and store those for later use.
Please note that you can stop Pyrit's batch-processing at any time (with ctrl+c or
sending SIGTERM). Pyrit will start at the point where it stopped the next time you start
batch-processing. Issue to following command:
pyrit batch
... and watch how Pyrit crunches through the database until it runs out of work:
Connecting to storage at 'file://'... connected.
Working on ESSID 'linksys'
Processed all workunits for ESSID 'linksys'; 1035 PMKs per second.
Batchprocessing done.
You can use the 'eval'-command once more to see that all workunits for ESSID 'linksys'
have been computed.
Using the database to attack a handshake

We can now use the Pairwise Master Keys stored in the database to attack the same
handshake as in the example above. Instead of running a "passthrough-attack", where
the database is not touched at all, we issue a "database-attack" like the following:
pyrit -r wpapsk-linksys.dump.gz attack_db
Please note that we did neither specify the network's ESSID nor it's BSSID.
You should get a response very similar to the following:
Connecting to storage at 'file://'... connected.

Picked AccessPoint 00:0b:86:c2:a4:85 ('linksys') automatically.
Attacking handshake with Station 00:13:ce:55:98:ef...
Tried 1639 PMKs so far (39.8%); 1577435 PMKs per second.
The password is 'dictionary'.
Again, the password protecting the network has been revealed.

While our example uses an extremely small wordlist and the performance-numbers are
thereby not very reliable, attacking a handshake from a database of pre-computed
Pairwise Master Keys will usually crunch through more than one million passwords per
second. You can also run a database-attack against the second capture file 'wpa2psklinksys.dump.gz', which will also take use of the pre-computed Pairwise Master Keys.
Scaling up: Using a SQL-database as storage

Using a SQL-database instead of the filesystem will give you some benefits:
Real ACID-compliance, backup- and load-balancing-features.

Multiple Pyrit-clients can operate on the same database at the same time over the
network.
Meta- and binary-data are (possibly) stored independent of each other, making
the database easier to query and operate on.
Pyrit uses SQLAlchemy and can therefor use all kinds of SQL-databases for it's internal
storage mechanism: SQLite has all the benefits described above (except the networkfunctionality), MySQL and PostgreSQL require some setup but provide more features
and better scaling. Please refer to SQLAlchemy's documentation for more details about
supported databases.
Using a database as storage is extremely easy - all you got to do is to provide an
alternative connection-string instead of 'file://' that Pyrit uses by default (please refer to
the manual for details about the connection-string). In the following example, we use a
SQLite-database stored in the single file 'mydb.db':
pyrit -u sqlite:///mydb.db -i dict.gz import_passwords
Please note that we do not have to care about creating the database (in the case of
SQLite) or any tables within it. Pyrit will take care of this. You should get an output
very similar to this:
Connecting to storage at 'sqlite:///mydb.db'...
10202 lines read. Flushing buffers...
All done.
connected.
Setting up a MySQL- or PostreSQL-server is beyond the scope of this tutorial.

However, after setting up the database-server, creating a (empty) database and
providing the necessary credentials, the required steps in Pyrit are the same as above.
For example, to use the (already created) database 'pyrit' on a PostgreSQL-server at
192.168.0.7 with user 'pyrit' and no password, your commandline would look
something like this:
pyrit -u postgres://pyrit:@192.168.0.7/pyrit -e linksys create_essid
To make life a little easier, you can save the default connection-string in Pyrit's
configuration-file at '~/.pyrit/config'. Change the value of the key default_storage to a
new connection-string and you won't have to supply it every single time.

Pyrit Introduction

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Pyrit Introduction

Încărcat de

Drepturi de autor:

Formate disponibile

Introduction

dict.gz is a gzip-compressed wordlist

First steps with capture-files and

Analyzing a capture file

#0: Station 00:13:ce:55:98:ef, handshake found

Attacking a handshake and revealing the password

Interlude: Stripping a capture-file from unnecessary

You should get a response like the following:

Working with Pyrit's database

Pyrit should respond like this:

Nothing fancy to see here, yet.

Populating and batch-processing the database

... and you'll get an output like this:

Connecting to storage at 'file://'...

ESSID 'linksys' : 0 (0.00%)

Using the database to attack a handshake

Connecting to storage at 'file://'... connected.

Again, the password protecting the network has been revealed.

Scaling up: Using a SQL-database as storage

Real ACID-compliance, backup- and load-balancing-features.

Setting up a MySQL- or PostreSQL-server is beyond the scope of this tutorial.

S-ar putea să vă placă și