daigai

Well-Known Member
Link tải luận văn miễn phí cho ae Kết Nối

WEP: Dead Again
Part 1
Introduction
This article is the first of a two-part series that looks at the new generation of WEP Cr-acking tools for
WiFi networks, which offer dramatically faster speeds for penetration testers over the previous
generation of tools. In many cases, a WEP key can be determined in seconds or minutes. Part one,
below, compares the latest KoreK based tools that perform passive statistical analysis and brute-force
Cr-acking on a sample of collected WEP traffic. Next time, in part two, we'll look at active attack
vectors, including a method to dramatically increase the rate of packet collection to make statistical
attacks even more potent.
Is WEP that bad?
Many security folks and even more wireless folks these days are saying that WEP isn't all that bad.
They say that if you use modern equipment that filters weak Initial Vectors (IVs) and change your
keys frequently (or at least once in a while), nobody will ever Cr-ack your WEP. Sure, maybe some
next-generation WEP attacks will arise one day that will change everything, but WEP is okay today
for all but the most sensitive networks. Well, that next-generation is already here, heralded by highly
functional tools that make WEP look weaker than Barney Fife on guard duty, sleeping on the job.
Let's take a look at some of the new tools that should be in every penetration tester's bag of tricks,
rather then delving into the details of why the various attacks work. Time and time again, the industry
has shown that it will not reject broken security safeguards until attacks are actually demonstrated in
the real world. Here's how to quickly turn some heads.
The way things were
Since the summer of 2001, WEP Cr-acking has been a trivial but time consuming process. A few tools,
AirSnort perhaps the most famous, that implement the Fluhrer-Mantin-Shamir (FMS) attack were
released to the security community -- who until then were aware of the problems with WEP but did
not have practical penetration testing tools. Although simple to use, these tools require a very large
number of packets to be gathered before being able to Cr-ack a WEP key. The AirSnort web site
estimates the total number of packets at five to ten million, but the number actually required may be
higher than you think.
The first caveat to this old approach is that only encrypted packets count. As wireless access points
transmit unencrypted beacons several times per second, it is easy to be fooled into believing that you
have a larger number of useful packets than you really do. If you use Kismet for network discovery
and sniffing, it breaks down the packet count for you, displaying the number of "Crypted" packets
separately from the total number, as shown below: g
The second thing working against your packet collection efforts is that only certain "interesting" or
"weak" IVs are vulnerable to attack. Kismet also tells you how many of these have been gathered,
although it may not use the same counting method as the various Cr-acking tools. To make matters
more difficult, wireless manufacturers responded to the FMS attack by filtering out the majority of
weak IVs that their access points and wireless cards transmit. Unless your target network is using old
equipment, chances are you'll have to collect no less than ten million encrypted packets to Cr-ack a
WEP key using these older tools.
In early 2002, h1kari released a tool called dwepCr-ack (part of the bsd-airtools package) that
improved upon the existing implementations of the FMS attack. Although dwepCr-ack did a good job
of advancing the practical implementation of statistical WEP cryptanalysis, its improvements were
only incremental.
Tools that changed everything
On August 8th, 2004, a hacker named KoreK posted new WEP statistical cryptanalysis attack code
(soon to become a tool called chopper) to the NetStumbler forums. While chopper is functional, it is
not currently maintained, and the attacks have since seen better implementations in airCr-ack and
WepLab. However, the KoreK attacks change everything. No longer are millions of packets required
to Cr-ack a WEP key; no longer does the number of obviously "weak" or "interesting" IVs matter.
With the new attacks, the critical ingredient is the total number of unique IVs captured, and a key can
often be Cr-acked with hundreds of thousands of packets, rather than millions.
AirCr-ack
The first tool in our new WEP Cr-acking toolbox is airCr-ack by Christophe Devine. Implementing
KoreK's attacks as well as improved FMS, airCr-ack provides the fastest and most effective statistical
attacks available. To give airCr-ack a try, simply collect as many packets as possible from a WEP
encrypted wireless network, save them as a pcap file, and then start airCr-ack from the command line.
Figure 2. airCr-ack succeeds.
How many packets does it take?
The number of packets required for success with airCr-ack varies greatly. As a rule of thumb, shoot for
a minimum of 200,000 for a 64 bit key and 500,000 for a 128 bit key, and remember to count only
encrypted packets with unique IVs, not total packets. airCr-ack comes with a handy packet capture
tool called airodump that keeps a running tally of unique IVs (the counting method is imperfect but
soon to be fixed) and is capable of handling very large capture files. Personally, I find it easier to use
Kismet most of the time and simply estimate the number of unique IVs based on the number of
"Crypted" packets reported by Kismet. The number of encrypted packets with unique IVs is typically
more than 95% of the total number of encrypted packets.
How long does it take?
I often find that airCr-ack determines a WEP key within a few seconds, but the execution time is
highly variable. Shorter execution times require more unique IVs, more luck, and the lowest
successful "fudge factor," a setting that tells airCr-ack how wildly it should guess when trying new
keys. The higher the fudge factor, the more keys airCr-ack will try, increasing both the potential time
of execution and the likelihood that the attack will succeed. The fudge factor has a default value of
two but may be set to any positive integer. The default setting may be a good place to start, but trying
several different settings is frequently fruitful if the initial attack does not succeed. I have
encountered some data sets that could be Cr-acked with a fudge factor of one, several that could only
be Cr-acked with three, four, or higher, and one data set that could only be Cr-acked with a fudge factor
of 31 or higher.
Link Download bản DOC
Do Drive thay đổi chính sách, nên một số link cũ yêu cầu duyệt download. các bạn chỉ cần làm theo hướng dẫn.
Password giải nén nếu cần: ket-noi.com | Bấm trực tiếp vào Link để tải:

 

Các chủ đề có liên quan khác

Top