Wi Foo - The Secrets of Wireless Hacking - PDFCOFFEE.COM (2024)

• •

Table of Contents Index

Wi-Foo By Andrew A. Vladimirov, Konstantin V. Gavrilenko,

Andrei A. Mikhailovsky Publisher : Pub Date : ISBN : Pages :

Addison Wesley June 28, 2004 0-321-20217-1 592

The definitive guide to penetrating and defending wireless networks. Straight from the field, this is the definitive guide to hacking wireless networks. Authored by world-renowned wireless security auditors, this hands-on, practical guide covers everything you need to attack -- or protect -- any wireless network. The authors introduce the 'battlefield,' exposing today's 'wide open' 802.11 wireless networks and their attackers. One step at a time, you'll master the attacker's entire arsenal of hardware and software tools: crucial knowledge for crackers and auditors alike. Next, you'll learn systematic countermeasures for building hardened wireless 'citadels''including cryptography-based

techniques, authentication, wireless VPNs, intrusion detection, and more. Coverage includes: Step-by-step walkthroughs and explanations of typical attacks Building wireless hacking/auditing toolkit: detailed recommendations, ranging from discovery tools to chipsets and antennas Wardriving: network mapping and site surveying Potential weaknesses in current and emerging standards, including 802.11i, PPTP, and IPSec Implementing strong, multilayered defenses Wireless IDS: why attackers aren't as untraceable as they think Wireless hacking and the law: what's legal, what isn't If you're a hacker or security auditor, this book will get you in. If you're a netadmin, sysadmin, consultant, or home user, it will keep everyone else out.

• •

Table of Contents Index

Wi-Foo By Andrew A. Vladimirov, Konstantin V. Gavrilenko,

Andrei A. Mikhailovsky Publisher : Pub Date : ISBN : Pages :

Addison Wesley June 28, 2004 0-321-20217-1 592

Copyright Acknowledgments About the Authors Introduction Why Does Wi-Foo Exist and for Whom Did We Write It? What About the Funky Name? How This Book Is Organized Chapter 1. Real World Wireless Security Why Do We Concentrate on 802.11 Security? Getting a Grip on Reality: Wide Open 802.11 Networks Around Us The Future of 802.11 Security: Is It as Bright as It Seems? Summary Chapter 2. Under Siege Why Are "They" After Your Wireless Network? Wireless Crackers: Who Are They? Corporations, Small Companies, and Home Users: Targets Acquired Target Yourself: Penetration Testing as Your First Line of Defense Summary Chapter 3. Putting the Gear Together: 802.11 Hardware PDAs Versus Laptops PCMCIA and CF Wireless Cards Antennas RF Amplifiers RF Cables and Connectors Summary

Chapter 4. Making the Engine Run: 802.11 Drivers and Utilities Operating System, Open Source, and Closed Source The Engine: Chipsets, Drivers, and Commands Getting Used to Efficient Wireless Interface Configuration Summary Chapter 5. Learning to WarDrive: Network Mapping and Site Surveying Active Scanning in Wireless Network Discovery Monitor Mode Network Discovery and Traffic Analysis Tools Tools That Use the iwlist scan Command RF Signal Strength Monitoring Tools Summary Chapter 6. Assembling the Arsenal: Tools of the Trade Encryption Cracking Tools Wireless Frame-Generating Tools Wireless Encrypted Traffic Injection Tools: Wepwedgie Access Point Management Utilities Summary Chapter 7. Planning the Attack The "Rig" Network Footprinting Site Survey Considerations and Planning Proper Attack Timing and Battery Power Preservation Stealth Issues in Wireless Penetration Testing An Attack Sequence Walk-Through Summary Chapter 8. Breaking Through The Easiest Way to Get in A Short Fence to Climb: Bypassing Closed ESSIDs, MAC, and Protocols Filtering Picking a Trivial Lock: Various Means of Cracking WEP Picking the Trivial Lock in a Less Trivial Way: Injecting Traffic to Accelerate WEP Cracking Field Observations in WEP Cracking Cracking TKIP: The New Menace The Frame of Deception: Wireless Man-in-the-Middle Attacks and Rogue Access Points Deployment Breaking the Secure Safe The Last Resort: Wireless DoS Attacks Summary Chapter 9. Looting and Pillaging: The Enemy Inside Step 1: Analyze the Network Traffic Step 2: Associate to WLAN and Detect Sniffers Step 3: Identify the Hosts Present and Perform Passive Operating System Fingerprinting Step 4: Scan and Exploit Vulnerable Hosts on WLAN Step 5: Take the Attack to the Wired Side Step 6: Check Wireless-to-Wired Gateway Egress Filtering Rules Summary Chapter 10. Building the Citadel: An Introduction to Wireless LAN Defense Wireless Security Policy: The Cornerstone Layer 1 Wireless Security Basics The Usefulness of WEP, Closed ESSIDs, MAC Filtering, and SSH Port Forwarding

Secure Wireless Network Positioning and VLANs Deploying a Linux-Based, Custom-Built Hardened Wireless Gateway Proprietary Improvements to WEP and WEP Usage 802.11i Wireless Security Standard and WPA: The New Hope Summary Chapter 11. Introduction to Applied Cryptography: Symmetric Ciphers Introduction to Applied Cryptography and Steganography Modern-Day Cipher Structure and Operation Modes Bit by Bit: Streaming Ciphers and Wireless Security The Quest for AES Between DES and AES: Common Ciphers of the Transition Period Selecting a Symmetric Cipher for Your Networking or Programming Needs Summary Chapter 12. Cryptographic Data Integrity Protection, Key Exchange, and User Authentication Mechanisms Cryptographic Hash Functions Dissecting an Example Standard One-Way Hash Function Hash Functions, Their Performance, and HMACs Asymmetric Cryptography: A Different Animal Summary Chapter 13. The Fortress Gates: User Authentication in Wireless Security RADIUS Installation of FreeRADIUS User Accounting RADIUS Vulnerabilities RADIUS-Related Tools 802.1x: The Gates to Your Wireless Fortress LDAP NoCat: An Alternative Method of Wireless User Authentication Summary Chapter 14. Guarding the Airwaves: Deploying Higher-Layer Wireless VPNs Why You Might Want to Deploy a VPN VPN Topologies Review: The Wireless Perspective Common VPN and Tunneling Protocols Alternative VPN Implementations The Main Player in the Field: IPSec Protocols, Operations, and Modes Overview Deploying Affordable IPSec VPNs with FreeS/WAN Summary Chapter 15. Counterintelligence: Wireless IDS Systems Categorizing Suspicious Events on WLANs Examples and Analysis of Common Wireless Attack Signatures Radars Up! Deploying a Wireless IDS Solution for Your WLAN Summary Afterword Appendix A. Decibel​W atts Conversion Table Appendix B. 802.11 Wireless Equipment Appendix C. Antenna Irradiation Patterns Omni-Directionals: Semi-Directionals:

Highly-directionals Appendix D. Wireless Utilities Manpages Section 1. Iwconfig Section 2. Iwpriv Section 3. Iwlist Section 4. Wicontrol Section 5. Ancontrol Appendix E. Signal Loss for Obstacle Types Appendix F. Warchalking Signs Original Signs Proposed New Signs Appendix G. Wireless Penetration Testing Template Arhont Ltd Wireless Network Security and Stability Audit Checklist Template Section 1. Reasons for an audit Section 2. Preliminary investigations Section 3. Wireless site survey Section 4. Network security features present Section 5. Network problems / anomalies detected Section 6. Wireless penetration testing procedure Section 7. Final recommendations Appendix H. Default SSIDs for Several Common 802.11 Products Glossary Index

Copyright Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers discounts on this book when ordered in quantity for bulk purchases and special sales. For more information, please contact: U.S. Corporate and Government Sales (800) 382-3419 [emailprotected] For sales outside of the U.S., please contact: International Sales (317) 581-3793 [emailprotected] Visit Addison-Wesley on the Web: www.awprofessional.com Copyright © 2004 by Pearson Education, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. Published simultaneously in Canada. For information on obtaining permission for use of material from this work, please submit a written request to: Pearson Education, Inc. Rights and Contracts Department 75 Arlington Street, Suite 300 Boston, MA 02116 Fax: (617) 848-7047 Text printed on recycled paper

1 2 3 4 5 6 7 8 9 10 0807060504 First printing, June 2004 Library of Congress Cataloging-in-Publication Data

Acknowledgments The authors would like to express their gratitude to All packets in the air Our family, friends, and each other The Open Source Community, GNU, and all the wireless hackers for providing tools and information All the other people who were involved with the project and made it possible

About the Authors The authors have been active participants in the IT security community for many years and are security testers for leading wireless equipment vendors. Andrew A. Vladimirov leads the wireless consultancy division at Arhont Ltd, one of the UK's leading security consultants. He was one of the UK's first IT professionals to obtain the coveted CWNA wireless certification. Konstantin V. Gavrilenko co-founded Arhont Ltd. He has more than 12 years of IT and security experience, and his expertise includes wireless security, firewalls, cryptography, VPNs, and IDS. Andrei A. Mikhailovsky has more than a decade of networking and security experience and has contributed extensively to Arhont's security research papers.

Introduction "Our first obligation is to keep the Foo Counters turning." ​RFC3092

Why Does Wi-Foo Exist and for Whom Did We Write It? There are multiple white papers and books available on wireless security (only two years ago you would have hardly found any). Many of them, including this book, are centered around 802.11 standards. Most explain the built-in security features of 802.11 protocols, explain future 802.11 security standards development and requirements, list (and sometimes describe in detail) known security weaknesses of 802.11 networks, and describe the countermeasures that a wireless network manager or system administrator can take to reduce the risks presented by these flaws. However, all books (except this one) do not describe how "hackers" can successfully attack wireless networks and how system administrators can detect and defeat these attacks, step by step, as the actual attack takes place. We believe that the market needs above all else a hands-on, down-to-earth source on penetration testing of wireless networks. Such a source should come from the field and be based on the practical experience of penetrating a great number of client and testing wireless networks, an experience that many in the underground and few in the information security community possess. As a core of the Arhont wireless security auditing team, we perform wireless penetration testing on an almost daily basis and we hope that our experience will give you a good jump start on practical wireless security assessment and further network hardening. If you are a curious individual who just got a PCMCIA card and a copy of the Netstumbler, we hope that this book will teach you about real wireless security and show, in the words of one of the main heroes of The Matrix, "how deep the rabbit hole goes." You will, hopefully, understand what is possible to do securitywise with the wireless network and what isn't; what is considered to be legal and what crosses the line. In the second, defense-oriented section of the book, you will see that, despite all the limitations of wireless security, an attacker can be successfully traced and caught. At the same time, we hope that you will see that defending wireless networks can be as thrilling and fascinating as finding and attacking them, and you could easily end up as a local wireless community security guru or even choose a professional path in this area. If you do participate in a wireless community project, you can raise awareness of wireless security issues in the community and help educate and inform others and show them that "open and free" does not mean "exploited and abused." If you run your own home wireless LAN, we take it for granted that it will be far more difficult to break into after you finish reading this book. If you are a system administrator or network manager, proper penetration testing of your wireless network is not just the only way to see how vulnerable your network is to both external and internal attackers, but also the only way to demonstrate to your management the need for additional security safeguards,

training, and consultants. Leaving the security of your wireless network unattended is asking for trouble, and designing a network with security in mind from the very beginning saves you time, effort, and perhaps your job. Unless the threats are properly understood by top management, you won't be able to implement the security measures you would like to see on your WLAN, or make the best use of the expertise of external auditors and consultants invited to test, troubleshoot, and harden the wireless network. If you decide (or are required) to tackle wireless security problems yourself, we hope that the defense section of the book will be your lifeline. If the network and company happen to be yours, it might even save you a lot of cash (hint: open source). If you are a security consultant working within the wireless security field or expanding your skills from the wired to the wireless world, you might find a lack of structure in the on-line information and lack of practical recommendations (down to the command line and configuration files) in the currently available literature; this book will fill the vacuum. The most prestigious and essential certification in the wireless security area at the time of writing is the Certified Wireless Security Professional (CWSP; see the "Certifications" section at http://www.cwne.com). People who have this certification have shown that they have a sufficient understanding of wireless security problems and some hands-on skills in securing real-life wireless networks. Because the CWSP certification is vendor-independent, by definition the CWSP preparation guide cannot go into specific software installation, configuration, troubleshooting, and use in depth. Thus, this book is a very useful aid in CWSP exam preparation, helping the reader comprehend the studied issues on a "how-to" level. In fact, the structure of this book (planned half a year before the release of the official CWSP study guide) is similar to the guide structure: The description of attack methods is followed by chapters devoted to the defensive countermeasures. After that, as you will see, the similarities between the books end. Finally, if you are a cracker keen on breaking into a few networks to demonstrate that "sad outside world" your "31337 2k1LLz," our guess is what you are going to read here can be useful for your "h4x0r1ng" explorations, in the same manner that sources like Securityfocus or Packetstorm are. Neither these sites nor this book are designed for your kin, though (the three categories of people we had in mind when writing it are listed earlier). We believe in a free flow of information and sensitive open disclosure (as, e.g., outlined by a second version of the infamous RFPolicy; see http://www.wiretrip.net/rfp/policy.html). What you do with this information is your responsibility and the problems you might get into while using it the illicit way are yours, and not ours. The literature on martial arts is not banned because street thugs might use the described techniques against their victims, and the same applies to the informational "martial arts" (consider this one of the subreasons for the name of this book). In fact, how often are you

attacked by the possessors of (rightfully earned) black belts on streets or in bars without being an offender yourself? Real masters of the arts do not start fights and true experts in information security do not go around defacing Web sites or trying to get "a fatter free pipe for more w4r3z." If you are truly keen on wireless security, you will end up as a wireless security application developer, security system administrator, or consultant. Although it is not an example from the wireless side of the world, take a close look at Kevin Mitnick, or read his recent "The Art of Deception" work. If you remain on the "m3 0wnZ j00" level, you will end up living without the Internet behind bars in some remote prison cell, and no manuals, books, or tools will save you. It's the mindset that puts "getting root by any means to impress my mates and satisfy my ego" before knowledge and understanding that is flawed.

What About the Funky Name? All that we describe here we did first for fun and only then for profit. It is an art, in a sense, of informational warfare over the microwave medium that involves continuing effort and passion, on both the attacking and defending sides. Currently the attacking side appears to be more persistent and thus, efficient: new attack tools and methodologies appear on a monthly, if not weekly basis. At the same time, the majority of wireless networks we have observed and evaluated were frankly "foo bar'ed." For a non-geek, that term means, roughly, "messed up beyond human comprehension." There are far more colorful definitions of this great and useful term and the curious reader is referred to Google for the deep linguistic investigations of all things foo and bar. Don't forget to stop by http://www.ietf.org/rfc/rfc3092.txt on your journey for truth. The "foo bar" state applies to both real-world wireless security (you would be surprised by the number of completely open wireless networks around, without even minimal available security features enabled) and some other issues. Such issues primarily include radio frequency side misconfigurations​access points transmitting on the same and overlapping channels, incorrectly positioned antennas, incorrectly chosen transmission power level, and so on. Obviously, 802.11-Foo would be a more technically correct name for the book (not every 802.11 device is wireless fidelity-certified) but, admit it, Wi-Foo sounds better :). To comment on the "hacking" part of the title, in the Western world there are two sides constantly arguing about the meaning of this term. Whereas the popular media and the public opinion it fosters identify "hacking" with breaking systems and network security for fun, knowledge, or nefarious aims, old-time programmers and system administrators tend to think that "hacking" is tweaking and tinkering with software and hardware (and not only) to solve various technical problems employing lateral thinking. A good illustration of the second approach to the term is Richard Stallman's "On Hacking" article you can enjoy at http://www.stallman.org/articles/on-hacking.html. In our case it is the second applied to the first with nefarious aims taken away and defense methodologies added. No network is the same and this statement applies to wireless networks far more than their wired counterparts. Have you ever seen a wired network affected by a heavy rain, blossoming trees, or 3D position of the network hosts? Can the security of an Ethernet LAN segment be dependent on the chipsets of network client cards? Although this book tries to be as practical as possible, no solution or technique presented is an absolute, universal truth, and you will find that a lot of tweaking (read: hacking) for the particular network you are working on (both attack and defense-wise) is required. Good luck, and let the packets be with you.

How This Book Is Organized Practically every wired or wireless network security book available starts with an outline of the seven Open Systems Interconnection (OSI) layers, probably followed by explaining "the CISSP triad" (confidentiality, integrity, and availability), basic security principles, and an introduction to the technology described. These books also include an introductory chapter on cryptography normally populated by characters called Bob, Alice, Melanie, and of course, Eve, who tends to be an evil private key snatcher. This book is different: We assume that the reader has basic knowledge of the OSI and TCP/IP layers, understands the difference between infrastructure / managed and independent / ad-hoc wireless networks as well as can distinguish between common IEEE 802 standards. Describing the basics of networking or detailed operations of wireless networks will constitute two separate books on their own, and such well-written books are easily found (for 802.11 essentials we strongly recommend the Official CWNA Study Guide and O'Reilly's 802.11 Wireless Networks: The Definitive Guide). However, you'll find a lot of data on 802.11 network standards and operations here when outlining it is appropriate, often in form of the inserted "foundations" boxes. Also, there is a cryptography part that isn't directly related to everything wireless, but is absolutely vital for the proper virtual private network (VPN) deployment, wireless users authentication, and other security practices outlined in the following chapters. We skimmed through a lot of cryptographic literature and have been unable to find anything written specifically for system and network administrators and managers to cover practical networking conditions taking into account the access media, bandwidth available, deployed hosts' CPU architecture, and so forth. Chapters 11 and 12 will be such a source and we hope it will help you even if you have never encountered practical cryptography issues at all or aren't an experienced cryptographer, cryptanalytic, or cryptologist. We have divided the book into two large parts: Attack and Defense. Although the Attack half is self-sufficient if your only aim is wireless security auditing, the Defense part is heavily dependent on understanding who the attackers might be, why they would crack your network, and, most important, how it can be done. Thus, we recommend reading the Attack part first unless you are using Wi-Foo as a reference. This part begins with a rather nontechnical discussion outlining the wireless security situation in the real world, types of wireless attackers, and their motivations, objectives, and target preferences. It is followed by structured recommendations on selecting and setting up hardware and software needed to

perform efficient wireless security testing. We try to stay impartial, do not limit ourselves to a particular group of vendors, and provide many tips on getting the best from the hardware and utilities you might already have. After all, not every reader is capable of devoting his or her resources to building an ultimate wireless hacking machine, and every piece of wireless hardware has its strong and weak sides. When we do advise the use of some particular hardware item, there are sound technical reasons behind any such recommendation: the chipset, radio frequency transceiver characteristics, antenna properties, availability of the driver source code, and so on. The discussion of standard wireless configuration utilities such as Linux Wireless Tools is set to get the most out of these tools security-wise and flows into the description of wireless penetration testing-specific software. Just like the hardware discussion before, this description is structured, splitting all available tools into groups with well-defined functions rather than listing them in alphabetic or random order. These groups include wireless network discovery tools, protocol analyzers, encryption cracking tools, custom 802.11 frame construction kits, and various access point management utilities useful for access point security testing. Whereas many "network security testing" books are limited to describing what kind of vulnerabilities there are and which tools are available to exploit them, we carry the discussion further, outlining the intelligent planning for a proper audit (or attack) and walking the reader step by step through the different attack scenarios, depending on the protection level of the target network. We outline advanced attack cases, including exploiting possible weaknesses in the yet unreleased 802.11i standard, accelerating WEP cracking, launching sneaky layer 2 man-in-the-middle and denial of service attacks, and even trying to defeat various higher layer security protocols such as PPTP, SSL and IPSec. Finally, the worst case scenario, a cracker being able to do anything he or she wants with a penetrated wireless network, is analyzed, demonstrating how the individual wireless hosts can be broken into, the wired side of the network assaulted, connections hijacked, traffic redirected, and the firewall separating wireless and wired sides bypassed. The Attack chapters demonstrate the real threat of a wireless network being abused by crackers and underline the statement repeated throughout the book many times: Wireless security auditing goes far beyond discovering the network and cracking WEP. In a similar manner, wireless network hardening goes beyond WEP, MAC address filtering, and even the current 802.11i developments. The later statement would be considered blasphemy by many, but we are entitled to our opinion. As the Attack part demonstrates, the 802.11i standard is not without its flaws and there would be cases in which it cannot be fully implemented for various administrative and financial reasons. Besides, we believe that any network security should be a multilayered process without complete dependence on a single safeguard, no matter how great the safeguard is. Thus, the primary aim of the Defense part of the book is giving readers the choice. Of course, we dwell on the impressive work

done by the "i" task force at mitigating the threats to which all pre-802.11i wireless LANs are exposed. Nevertheless, we spend a sufficient amount of time describing defending wireless networks at the higher protocol layers. Such defense methodologies include mutually authenticated IPSec implementations, authentication methods alternative to 802.1x, proper network design, positioning and secure gateway deployment, protocol filtering, SSL/TLS use, and ssh port forwarding. The final chapter in the book is devoted to the last (or first?) line of defense on wireless networks, namely wireless-specific intrusion detection. It demonstrates that wireless attackers are not as untraceable as they might think and gives tips on the development and deployment of affordable do-it-yourself wireless IDS systems and sensors. It also lists some well-known high-end commercial wireless IDS appliances. Even though we have barely scratched the surface of the wireless security world, we hope that this book will be useful for you as both a wireless attack and defense guide and a reference. We hope to receive great feedback from our audience, mainly in the form of fewer insecure wireless networks in our Kismet output and new exciting wireless security tools, protocols, and methodologies showing up to make the contents of this book obsolete.

Chapter 1. Real World Wireless Security "Every matter requires prior knowledge." ​Du Mu "If you can find out the real conditions, then you will know who will prevail." ​Mei Yaochen Rather than concentrating on the basics of general information security or wireless networking, this introductory chapter focuses on something grossly overlooked by many "armchair experts": The state of wireless security in the real world. Before getting down to it, though, there is a need to tell why we are so keen on the security of 802.11 standards-based wireless networks and not other packet-switched radio communications. Figure 1-1 presents an overview of wireless networks in the modern world, with 802.11 networks taking the medium circle.

Figure 1.1. An overview of modern wireless networks.

As shown, we tend to use the term 802.11 wireless network rather than 802.11 LAN. This particular technology dissolves the margin between local and wide area connectivity: 802.11b point-to-point links can reach beyond 50 miles in distance, efficiently becoming wireless wide area network (WAN) connections when used as a last mile data delivery solution by wireless Internet service providers (ISPs) or long-range links between offices. Thus, we consider specifying the use of 802.11 technology to be necessary: Local area networks (LANs) and WANs always had and will have different security requirements and approaches.

Why Do We Concentrate on 802.11 Security? The widespread area of 802.11 network coverage zones is one of the major reasons for rising security concerns and interest: An attacker can be positioned where no one expects him or her to be and stay well away from the network's physical premises. Another reason is the widespread use of 802.11 networks themselves: By 2006 the number of shipped 802.11-enabled hardware devices is estimated to exceed 40 million units (Figure 1-2), even as the prices on these units keep falling. After 802.11g products hit the market, the price for many 802.11b client cards dropped to the cost level of 100BaseT Ethernet client cards. Of course there is a great speed disadvantage (5​7 Mbps on 802.11b vs. 100 Mbps on switched fast Ethernet), but not every network has high-speed requirements, and in many cases wireless deployment will be preferable. These cases include old houses in Europe protected as a part of the National Heritage. In such houses, drilling through obstacles to lay the cabling is prohibited by law. Another case is offices positioned on opposite sides of a busy street, highway, or office park. Finally, the last loop provider services via wireless are basically a replacement for the cable or xDSL link and 802.11b "pipe" is not likely to be a bottleneck in such cases, taking into account common xDSL or cable network bandwidth.

Figure 1.2. The growth of the 802.11 wireless market.

802.11 networks are everywhere, easy to find, and, as you will see in this book, often do not require any effort to associate with. Even if they are protected by WEP (which still remains the most common security countermeasure on 802.11 LANs), the vulnerabilities of WEP are very well publicized and known to practically anyone with a minimal interest in wireless networking. On the contrary, other

wireless packet-switched networks are far from being that common and widespread, do not have well-known and "advertised" vulnerabilities, and often require obscure and expensive proprietary hardware to explore. At the same time, 802.11 crackers commonly run their own wireless LANs (WLANs) and use their equipment for both cracking and home and community networking. Attacks on GSM and GPRS phones are mainly related to unit "cloning," which lies outside the realm of network hacking to which this book is devoted. On the personal area network (PAN) side, the hacking situation is far more interesting to dive into from a network security consultant's viewpoint. Attacks on infrared PANs are a form of opportunistic cracking based on being in the right place at the right time​a cracker would have to be close to the attacked device and be in a 30-degree zone from its infrared port. Because the infrared irradiation power is limited to 2 mW only, the signal is not expected to spread further than two meters. An exemption to the 30 degrees/2 mW limitations is the case when an infrared access point (e.g., Compex iRE201) is deployed in an office or conference hall. In such a situation, all that a cracker needs to sniff traffic and associate with the infrared PAN is to be in the same room with the access point. There is no layer 2 security in Infrared Data Association (IrDA) PANs and unless higher layers' encryption or authentication means are deployed, the infrared network is open for anyone to exploit. Windows 2000 and Windows XP clients automatically associate with other IrDA hosts and Linux IrDA project stack (http://irda.sourceforge.net/) provides a remote IrDA host discovery option (do irattach -s) as well as irdadump, which is a utility similar to tcpdump. Irdaping has been used to freeze dead unpatched Windows 2000 machines before the Service Pack 3 release (see the Bugtraq post at http://www.securityfocus.com/archive/1/209385/2003-03-11/2003-03-17/2). If you want to dump layer 2 IrDA frames under Windows 2000, an infrared debugger interface in rCOMM2k (a port of Linux IrDA stack, http://www.stud.unihannover.de/~kiszka/IrCOMM2k/English/) will do a decent job. However, no matter how insecure the infrared networks are, their limited use and physically limited spread means that scanning for data over light will never be as popular as scanning for data over radio frequency (RF) waves. As such, warnibbling or looking for Bluetooth networks will gain much higher popularity than looking for infrared connections and might one day compete with wardriving in popularity. The tools for Bluetooth network discovery such as Redfang from @Stake and a graphical user interface (GUI) for it (Bluesniff, Shmoo Group) are already available to grab and use and more tools will no doubt follow suit. Three factors limit the spread of Bluetooth hacking. One is the still limited use of this technology, but that is very likely to change in a few years. Another factor is the limited (if compared to 802.11 LANs) coverage zone. However, Class 1

Bluetooth devices (output transmission power up to 100 mW) such as Bluetoothenabled laptops and access points can cover a 100-meter radius or greater if high-gain antennas are used. Such networks are de facto WLANs and can be suitable targets for remote cracking. The third factor is the security mechanisms protecting Bluetooth PANs against both snooping and unauthorized connections. So far there are no known attacks circumventing the E0 streaming cipher used to encrypt data on Bluetooth PANs. However, only time will determine if this proprietary cipher will stand Kerckhoffs's assumption and whether the famous story of the unauthorized Cypherpunks mail list disclosure of the RC4 algorithm structure will not repeat itself again (see Chapter 11 if you find this example confusing). There are already theoretical observations of possible Bluetooth security mechanism weaknesses (see http://www.tcs.hut.fi/~helger/crypto/link/practice/bluetooth.html). Besides, even the best security countermeasure is useless unless it is implemented, and Bluetooth devices are usually set to the first (lowest) security mode out of the three Bluetooth security modes available and have the default of "0000" as the session security PIN. It is also common to use the year of birth or any other meaningful (and guessable) four-digit number as a Bluetooth PIN. This happens for convenience reasons, but the unintended consequence is that it makes the cracker's job much easier. In our observations, about 50 percent of Bluetoothenabled devices have the default PIN unchanged. There are also devices that have default PINs prewired without any possibility of changing them: all the attacker would have to do is find the list with the default PINs online. Although this provides a great opportunity for the potential attacker, we have yet to meet a real flesh-and-bone "warnibbler" who goes beyond sending prank messages via Bluetooth on the street. At the same time, security breaches of 802.11 networks occur on a daily, if not hourly, basis bringing us back to the main topic: Why and, most important, how they take place.

Getting a Grip on Reality: Wide Open 802.11 Networks Around Us As mentioned, in the majority of cases an attacker does not have to do anything to get what he or she wants. The safe door is open and the goods are there to be taken. The Defcon 2002 wardriving contest showed that only 29.8 percent of 580 access points located by the contesters had WEP enabled. As much as 19.3 percent had default ESSID values, and (not surprisingly) 18.6 percent of discovered access points did not use WEP and had default ESSIDs. If you think that something has changed since then, you are mistaken. If there were any changes, these were the changes for the worse, because the Defcon 2003 wardrive demonstrated that only approximately 27 percent of networks in Las Vegas are protected by WEP. Because one of the teams employed a lateral approach and went to wardrive in Los Angeles instead, this number also includes some statistics for that city. The Defcon wardrive observations were independently confirmed by one of the authors wardriving and walking around Las Vegas on his own. Are things any better on the other side of the Atlantic? Not really. We speculated that only around 30 percent of access points in the United Kingdom would have WEP enabled. To validate this for research purpose, one of the authors embarked for a London Sightseeing Tour in the famous open-top red double-decker bus armed with a "debianized" laptop running Kismet, Cisco Aironet LMC350 card, and 12 dBi omnidirectional antenna. During the two-hour tour (exactly the time that laptop's batteries lasted), 364 wireless networks were discovered, of which 118 had WEP enabled; 76 had default or company name and address ESSIDs. Even worse, some of the networks discovered had visible public IP addresses of wireless hosts that were pingable from the Internet side. If you are a wireless network administrator in central London and are reading this now, please take note. Of course, in the process of collecting this information, no traffic was logged to avoid any legal complications. The experiment was "pure" wardriving (or rather "warbusing") at its best. Not surprisingly, warwalking in central London with a Sharp Zaurus SL-5500 PDA, D-Link DCF-650W CF 802.11b card (wonderful large antenna, never mind the blocked stylus slot), and Kismet demonstrated the same statistics. A similar level of 802.11 WLAN insecurity was revealed in Bristol, Birmingham, Plymouth, Canterbury, Swansea, and Cardiff. Crossing the English Channel does not help either. One of the authors has driven from Warsaw to London with another Zaurus/D-Link CF card/Kismet kit and found a similar ratio of WEP/noWEP 802.11 networks, including very powerful unencrypted point-to-point links crossing the countryside motorways in the middle of nowhere. Another author has evaluated 802.11 security in Riga, Latvia. Curiously, the wireless networks in Riga were so abundant that it was practically

impossible to use the middle ISM band (2.4​2.45 GHz) and many networks moved to the UNII (5.15​5.35 and 5.725​5.825 GHz) or even licensed ~24 GHz bands. Many legacy Breeznet and 802.11 FHSS networks were present. The wireless boom in Riga can be explained by old, noisy, Soviet-period phone lines incapable of carrying xDSL traffic without a significant packet loss/retransmission rate. Yet, despite the popularity of 802.11 networks, hardly anyone used WEP. If you think that the majority of these unprotected wireless networks were home user access points, wireless community networks, or public access hot spots, you are wrong. Many of the wide open networks we have observed "in the wild" belong to government organizations (foreign governments included) and large corporations (multinationals included). In fact, some of these corporations are major information technology (IT) enterprises or IT-related consultancies, which is particularly shameful! We don't even dare to think how many of the 802.11 networks located had implemented proper security measures beyond the standard ("crackable") WEP and MAC address filtering. Single-digit percentage values surely come to mind. Considering that both WEP and MAC filtering are not difficult to circumvent with a bit of patience, it is not surprising that security remains the major concern restricting the spread and use of wireless technology around the world. At the same time, there are efficient wireless security solutions available, including powerful and affordable free and Open Source-based wireless safeguards that we describe in the second part of this book. Unfortunately, very few wireless network engineers and administrators are aware of the existence of these solutions. As always, human factor proves to be the weakest link.

The Future of 802.11 Security: Is It as Bright as It Seems? Will the new 802.11 standards alleviate this situation? Again, only time will tell. While this book was being written, many manufacturers started to release 802.11g equipment onto the market, even though the 802.11g standard was not complete (see Figure 1-3 for reference on 802.11g development process). A great deal of these pre-802.11g products were advertised as "ultrasecure due to the new standard." In reality, 802.11g has nothing to do with security at all. In a nutshell, it is an implementation of the 802.11a orthogonal frequency division multiplexing (OFDM) physical layer modulation method for a middle ISM band to provide 802.11a speed (54 Mb/s is a standard-defined maximum), thus achieving both high connection speed and 802.11b or even the original 802.11 direct sequence spread spectrum (DSSS) standards compatibility. Therefore, the marketing attempts trying to link 802.11g and security were blatantly false.

Figure 1.3. 802.11i development process.

[View full size image]

On the other hand, the 802.11i standard (still in draft at the time of this writing) is the new wireless security standard destined to replace WEP and provide much stronger wireless security according to its developers. 802.11i was supposed to be released together with 802.11g, but we are not living in a perfect world. Wireless Protected Access (WPA) WiFi Alliance certification version 1 implements many of the current 802.11i development features, but not every 802.11g product currently sold is WPA certified. At the moment, there are many 802.11g networks deployed that still run old, insecure versions of WEP, and we have observed 802.11g LANs without any data encryption enabled by security-unaware administrators. A detailed description of 802.11i is beyond the reach of this introductory chapter and impatient readers are referred to Chapter 10 for the 802.11i structure and function discussion.

What deserves to be mentioned here are the issues of wireless hardware replacement, backward compatibility, personnel training, and falling prices on older 802.11 equipment (combined with higher prices on newly released 802.11g with 802.11i support products) mean that the old vulnerable WEP is with us to stay. This will happen even if 802.11i finally makes it and is unbreakable (very few security safeguards are, if any). Just as in the previously mentioned case of Bluetooth security, there will be users and even system administrators who forget to turn 802.11i security features on or leave the default or obvious key value unchanged. Also, as you will see, WLANs will still remain vulnerable to denial of service (DoS) attacks on both the first and second layers. A vile and determined attacker can use this to his or her advantage, bringing down the network only when 802.11i security features are enabled, thus playing a "Pavlovian game" against the wireless administrator. (When the authentication or encryption is on, the network doesn't work properly!) Thus, an opportunity for a cracker to sneak in will always remain a specific threat to wireless networks to be reckoned with.

Summary Despite the claims of wireless vendors' marketing departments and opinions of some "security experts," stating that "everyone is using WEP and it still provides a realistic level of security," real-world 802.11 security is next to abysmal. There are many factors contributing to this situation, both technical and administrative. Human factors, primarily the lack of user and even system administrator education, is the highest source of wireless insecurity in our opinion. As such, it is not going to disappear when newer, more secure standards become universally accepted. Thus, many security problems faced by modern wireless networks will persist for years ahead.

Chapter 2. Under Siege "Assess yourself and your opponents." ​Ho Yanxi

Why Are "They" After Your Wireless Network? In the "good old days," Internet access was a privilege of the few and many used to try getting access by all means possible. A common way to achieve unauthorized access was wardialing, or calling through long lists of phone numbers using automated tools such as Tonelock for MS-DOS or BreakMachine / Sordial for UNIX in search of modem tones and then trying to log in by guessing a username​password pair. The term wardriving, as well as everything else "war + wireless" has originated from these BBS and wardialing days. Today wardialing is not that efficient, even though you can still stumble on a guessable username and password out-of-band login set for a remote router administration via an AUX port, in case the main WAN link to the router fails. In the age of cheap broadband connections everywhere, is getting free bandwidth worth the effort or the gasoline and parking fee? Is it really about the bandwidth and getting access to the Internet, or are there other reasons for people to buy wireless equipment, configure the necessary tools, and drive, walk, or climb out of their comfortable home to search for packets in the air? At least wardialing did not require leaving one's room and getting a laptop or PDA, as well as wireless client cards and (in some cases) even access points. We can outline at least six reasons for such "irrational" and "geeky" behavior by would-be wireless attackers. 1. It is fun. Many geeks find hacking that involves tweaking both software (sniffing / penetration tools) and hardware (PCMCIA cards, USB adapters, connectors, antennas, amplifiers) more exciting than more traditional cracking over wired links. The same applies to being able to hack outdoors, while driving, while drinking beer in a pub that happened to be in some unlucky network's coverage zone, and so on. 2. It gives (nearly) anonymous access and an attacker is difficult to trace. Any time the attacker logs in from his or her ISP account, he or she is within a single whois command and a legally authorized phone call from being caught. The "traditional" way of avoiding being traced back is hopping through a chain of "owned" hosts that then get rm -rfed (or, in case of a more experienced attacker, shredded, defiled, decimated, or bcwiped) after a serious attack is completed and the time for an escape sequence has arrived. There are few significant disadvantages (from a cracker's viewpoint) of such a method. A cracker still needs an ISP account, for which he or she has to supply credentials. He or she also needs enough "rooted" hosts to hop through; ideally these hosts must belong to different networks in different countries. If one of the targeted hosts implements log storage on a nonerasable medium (e.g., CD-R, logs sent to a printer), a cracker is in deep trouble. The same applies to secure centralized logging if a cracker cannot get

into the log server. LIDS installed on the attacked host can bring additional trouble; suddenly getting "w00t" is not really getting anywhere. Finally, one of the used hosts can be a trap. Thanks to Lance Spitzner's work, honeypots and even honeynets are growing exceedingly popular among the security community.The bottom line is this: Hiding one's tracks this way is a complex process that includes many steps. Each one of these steps can suddenly become a point of failure. With wireless cracking, things are different. There is no ISP involved (save for the target's ISP) and the trace would lead to the attacked and abused wireless network, where it would literally dissolve in the air. Even if a person with a laptop or car with a mounted antenna was spotted near the wireless network from which the attack originated, authorities would have a very hard time finding the cracker and proving he or she is guilty. If before and after the attack the cracker has changed his or her wireless client card MAC address, and removed all the tools and data relevant to the attack from the laptop or PDA, then proving the attacker's guilt becomes frankly impossible. Even if you or the company guards approach the cracker during an attack, as long as the cracker is not on the premises, he or she can simply refuse to cooperate and leave. What are you going to do? Take a laptop by force from a stranger on a street? 3. Some might view illicit wireless access as a way of preserving one's online privacy. Recent legislation in the United Kingdom (the infamous RIP or The Regulation of Investigatory Powers Bill) makes online privacy practically impossible, with ISP logs required to be kept for up to seven years. This legislation is primarily a response to September 11 and the U.S. Patriot Act, which many other countries have followed in terms of introducing somewhat similar regulations. An unintended result of this is to encourage users, keen on privacy, to view the Internet connection via someone's WLAN as a good way of remaining anonymous. Of course, at the same time they will violate the privacy of the abused wireless network's owners, but most people are generally selfish. In addition, because they might not trade pirated software or p*rnography, send SPAM, or crack local or remote hosts, they will not view their action as something explicitly illegal: It's just "borrowing the bandwidth" for "self-defense" reasons. 4. In addition, there are purely technical reasons (apart from the vague network perimeter) that make wireless networks very attractive for crackers. An access point is not a switch; it's a hub with a radio transceiver. When was the last time you saw a shared wired Ethernet network? Putting a network interface into promiscuous mode and sniffing out all the Telnet / POP3 / SMTP passwords and NTLM hashes on a LAN looked like a thing of the past until 802.11 networks came into broad existence. At the same time, due to improper network design, an attacker associated with a wireless network will often find himself or herself connected straight to a wired LAN behind the corporate firewall with many insecure and unpatched services exposed to an

unexpected attack. Security-illiterate system administrators might ignore the security of the "inner LAN" altogether, equating network security with the settings of the perimeter firewall. It is a very common mistake and because of it, once the perimeter firewall is bypassed, you can still find old Winsock Windows 95 machines, unpatched wu-ftpd 2.6.0 daemons, passwordless shares, flowing LM hashes, and similar awful security blunders. Another technical point to be made is that due to the high anonymity of wireless access, crackers can play dirty to achieve maximum break-in efficiency. By that we primarily mean that powerful but very "noisy" vulnerability discovery tools, initially aimed at system administrators auditing their own networks without a need to hide, can be run by wireless attackers without a fear of reprisal. Such tools include Nessus, Satan/Saint/Sara, ISS and RETINA, and so forth. 5. A cracker can install a PCMCIA / PCI card / USB adapter / rogue access point as an out-of-band backdoor to the network. All the pages of sophisticated egress filtering rules on the corporate firewall suddenly become useless and a sensitive information leak occurs where no one expects it. On the other hand, unruly users can install wireless devices, from PCMCIA cards in an ad-hoc mode to access points, without company system administrators even knowing about it. When they do find out, it could be too late. It is simply an evolution of the infamous case of users connecting a modem and opening a hole in an otherwise secure network by creating a new insecure point of external entry. When a frontal attack against the corporate gateway fails, a desperate Black Hat might attempt to scan the company premises for insecure wireless access points or ad-hoc networks and succeed. 6. There is always "opportunistic cracking." If you had the chance to read your neighbors' e-mails and check which Web sites they were surfing, would you resist it? If a neighbor has an insecure wireless network, chances are an opportunistic attack will occur. What if the network in question is a corporate WLAN that opens future access into a large, impressive wired network, with the possibility of sensitive data flow and a very high-speed connection to the Internet? Opportunistic cracking of this kind is the victim's nightmare: The attacker does not have to go anywhere, is not limited by battery power, can involve a more powerful desktop machine in executing the attack, and is likely to have some form of Internet access at hand to get the necessary tools and manuals to carry out an intrusion. Besides, a stationary attacker can sell illegally obtained bandwidth to neighbors and friends, basically operating a small do-it-yourself wireless ISP at the unsuspecting company's expense. We are quite sure that there are more reasons for targeting wireless networks than entertainment, hiding one's tracks, anonymity, privacy, lateral attacks against well-protected gateway networks, out-of-band backdoor insertion, and, of course, free bandwidth. However, even these reasons should be sufficient to set

alarms off for anyone planning to install a wireless network or secure an already existing one.

Wireless Crackers: Who Are They? Knowing what kind of individual might launch an attack against your wireless network is just as important as being aware of his or her motivations. From the motivations already outlined, it is possible to split attackers of wireless networks into three main categories: 1. Curious individuals who do it for both fun and the technical challenge. This category of attackers does not usually present a huge threat to your WLAN and might even do a service to the community by publicly exposing insecure wireless networks and raising public awareness of wireless security issues. Many of them could actually become (or already are) wireless networking professionals and security tools developers for the Open Source community. If you happen to belong to this group, please be responsible and correct the flaws you find together with the located insecure WLAN management. If you are a beginner, progress further by continuously learning about more advanced wireless security methodologies and tools (this book will help). If you are an Open Source wireless security software developer, we acknowledge your work and wish you the best of luck. Finally, if as a system administrator or manager of an insecure wireless network you encounter such people who are informing you about your network's flaws, do not rush to the police. A real cracker would never approach you to tell about your network security faults. Instead, he or she will use them to take over your LAN, launch further attacks from it, and hide his or her tracks afterward. Although everyone is critical about "these damn script kiddies," a "script kiddie system administrator" who lacks an understanding of network security basics presents an equal, if not worse, security threat and should be held responsible for the network break-in as well as the cracker who did it. So, if a White Hat hacker or a security consultant approaches you regarding your wireless network vulnerabilities, listen, learn, and perhaps use the tools he or she employed to audit your own network for potential security flaws. Alternatively, you might want to order a wireless security audit from a capable local IT security consultancy that can fix the problems discovered. Of course, you don't have to wait for the disclosure to happen, and that is probably why you bought this book. 2. "Bandwidth snatchers." This category of wireless crackers are the "script kiddies" of the wireless world. Spammers and "warez" / p*rnography traders as well as some "I like my neighbor's wireless" opportunistic types belong here. They usually go for the lowest hanging fruit and are easy to repel (even WEP and MAC address filtering might do, but don't be so sure). As you will learn in Chapter 15, they are also relatively easy to discover and trace. Using someone else's network resources is illegal anywhere in the world and before attempting to do it, a cracker should decide if the "free ride" is really worth the trouble of being discovered and tried in a court of law. Even if the

bandwidth thief can manage to avoid strict punishment due to the immaturity of cybercrime laws in many parts of the world, he or she is likely to lose the equipment used for attacking and have a damaged reputation and social status. 3. Real Black Hats who happen to like wireless. These are the serious attackers who generally know what they do, why they do it, and what the legal consequences could be. Anonymity, lateral attacks on otherwise protected networks, and out-of-band backdoor access are the reasons professional crackers are attracted to wireless networks. They might be well-versed in both network and host penetration techniques, as well as radio frequency theory and practice, which makes them very difficult to catch (consider a throughly planned attack using a highly directional antenna and high-power transmitter client card against a long-distance, point-to-point wireless link). Standard security measures will only delay such attackers by a couple of hours. Unless the security of the 802.11 network is given proper attention in both time and effort, the attack will inevitably succeed. This book aims to give a system administrator enough data to protect his or her network against this type of attacker, but some creativity and planning on the administrator's side is also an absolute requirement. If you feel that you don't have the time or capability to stop a sophisticated wireless cracker even with the knowledge gained from this book, you need to apply to the specialized wireless security firms to investigate and remove the threat. Unfortunately, because 802.11 security is a hot topic, there are plenty of self-professed "wireless security consultants" with Windows XP Home Edition laptops and a copy of Netstumbler (or, in the best case, a copy of a single commercial wireless protocol analyzer alongside the Netstumbler). They can actually be detrimental to overall wireless network safety as they engender a false sense of security that makes you less concerned with the problem and thus more vulnerable. We hope that the data presented in this book will help system administrators and network managers to be selective in their outsourcing strategy.

Corporations, Small Companies, and Home Users: Targets Acquired There is a general misconception that only large enterprises are at risk from cracking, wireless cracking included. This is a myth, but it is very prevalent. Large corporations are where the money and sensitive data are. However, every experienced attacker first looks after his or her own safety in regards to future legal responsibility, so he or she would start by looking for an easy target for anonymous access. At the same time, an inexperienced cracker goes for anything "crackable" without considering whose network it is and what its purpose is. Large businesses usually have (or should have) trained security personnel, and a well-written and followed corporate security policy, as well as specific security equipment. This obviously increases the chances of discovering who the attackers are. In smaller companies and home networks many wireless attacks happen undetected and unmentioned until it is too late. Reinforcing the myth, however, the media pays attention to break-ins into major companies, thus creating an impression that smaller networks are of little interest for the underground. Large corporations might have massive wireless networks with high output power to bridge distant buildings and provide wireless point-to-point links between company offices in the same city. Such links are easy to discover and tap into at a significant distance from the transceiver. Corporate point-to-multipoint networks might also have an impressive coverage zone with a huge number of roaming hosts. Thus, it can be difficult to discover an illicitly connected host in the "large crowd" or even an additional access point among multiple access points on the network. Besides, massive enterprises are at a higher risk from users installing unsolicited wireless equipment (both 802.11 and 802.15) and are more susceptible to social engineering attacks. These factors counterbalance the larger amount of resources that sizable companies can put into their wireless network security. An issue we have discovered when auditing the security of various 802.11 networks is the use of legacy non-IP protocols over wireless. Although corporate networks generally tend to stay current, many organizational networks (government organizations included) do not appear to upgrade often and still run DECnet and Banyan Vines (not to mention IPX and AppleTalk) over 802.11 links. These protocols came into existence when networks were smaller, friendlier, and less exposed to the general public. At that time, security issues weren't very high on the network applications and protocols developers' lists, and known cases of cracking were sporadic. As the significance of TCP/IP grew together with the expansion of the Internet, security protocols running over IP (IPSec, Secure Sockets Layer (SSL), etc.) were developed, driven by the security demands of a large public network and the increasing importance of e-commerce around the

world. At the same time, little attention was paid to non-TCP/IP protocol security, and there is nothing close to IPSec for DECnet, Banyan Vines, AppleTalk, and IPX (at least to our knowledge). Although the attacker's sniffer might not be able to decode these protocols well (although tcpdump and Ethereal understand DECnet and Banyan Vines fine), information transmitted in plaintext is still readable by anyone. Thus, while running legacy protocols over 802.11, the main (and, perhaps the only) line of defense is 802.11 (second layer) security features. Until the final 802.11i draft is available, universally accepted, and used, such networks cannot be considered secure. Of course, there are proprietary solutions to WEP insecurities as well as the WPA TKIP/802.1x (see Chapter 10). However, compatibility and interoperability issues can be a serious obstacle to deploying these solutions on large wireless networks that run legacy protocols (and probably using legacy wireless hardware). It is likely that such networks running DECnet or Banyan Vines will end up relying on static 128-bit (or 64-bit) WEP keys for security (the alternative is to drop that VAX and begin a new life). At the same time, the protocols in question are very chatty and constantly generate wireless traffic, even when no user activity on the network takes place. As described in Chapter 8, chatty network protocols (including IPX and AppleTalk) are WEP crackers' best friends. Turning from large businesses and organizations to smaller enterprises and even home user networks, a common error is to consider them to be off the crackers "hit list" because they are "not interesting" and have "low value" for an attacker. At many business meetings we were told that "your services are not needed for our small company because the company does not handle any sensitive data or perform financial transactions online." Later on the very same people were inquiring about incident response and recovery services. The reasons wireless crackers would attack small business and home networks were already listed and are quite clear to anyone in the IT security field: anonymous access, low probability of getting caught, free bandwidth, and the ease of breaking in. Specific issues pertaining to wireless security in the small enterprise 802.11 LANs include the following: The prevalence of a sole overloaded system administrator unfamiliar with wireless networking or the frequent absence of any qualified system administrator. The use of low-end, cheap wireless equipment with limited security features (unless you deal with Open Source, you get what you pay for). The absence of a centralized authentication server. The absence of wireless IDS and centralized logging system.

The absence of a wireless security policy. Insufficient funds to hire a decent wireless security auditor or consultant. Although many would not expect the widespread use of wireless networks in the small business sector, this assumption is wrong. Frequently, WLAN deployment is a crucial money saver for a limited-size enterprise. Although wireless client cards and access points still cost more than Ethernet network interface cards and switches, the costs of cabling are often prohibitive for a small business. Whereas large enterprises usually have their buildings designed and built with Cat 5 or even fiber cables installed, smaller businesses often use older buildings not suitable for extensive network cabling. We have found that in central London many small and medium companies must resort to 802.11 because their offices are based in designated conservation buildings. Thus, the need to use wireless networks combined with a lack of resources for hardening these networks creates a great opportunity for wireless crackers that attack small enterprise WLANs. It is interesting to mention that when it comes to the use of basic wireless security countermeasures such as WEP, we saw that home networks tend to use WEP more frequently than many WLANs at small businesses and even larger enterprises. The rationale is probably the involved users' interest and attention to their own network and data protection as compared to the "we do not have a problem" approach to WLANs at the workplace exhibited by many corporate business users and, unfortunately, some system administrators and network managers. On the other hand, the majority of the "default SSID + no WEP combination" WLANs are also home user networks.

Target Yourself: Penetration Testing as Your First Line of Defense It is hard to overemphasize the importance of penetration testing in the overall information security structure and the value of viewing your network through the cracker's eyes prior to further hardening procedures. There are a variety of issues specific to penetration testing on wireless networks. First of all, the penetration tester should be very familiar with RF theory and specific RF security problems (i.e., signal leak and detectability, legal regulations pertaining to the transmitter power output, and characteristics of the RF hardware involved). Watch out for the "RF foundations" inserts through the book; they will be helpful. Layer 1 security is rarely an issue on wired networks, but it should always be investigated first on wireless nets. The initial stage of penetration testing and security auditing on 802.11 LANs should be a proper wireless site survey: finding where the signal from the audited network can be received, how clear the signal is (by looking at the signal-to-noise ratio (SNR)), and how fast the link is in different parts of the network coverage zone. It must also discover neighboring wireless networks and identify other possible sources of interference. The site survey serves four major security-related aims: 1. Finding out where the attackers can physically position themselves. 2. Detecting rogue access points and neighbor networks (a possible source of opportunistic or even accidental attacks). 3. Baselining the interference sources to detect abnormal levels of interference in the future, such as the interference intentionally created by a jamming device. 4. Distinguishing network design and configuration problems from securityrelated issues. This last point is of particular significance because air is a less reliable medium than copper and fiber and a security-keen administrator can easily confuse network misconfigurations with security violations, in particular, DoS attacks. For example, a host on wireless network might be unable to discover another wireless host that roamed into a "blind spot" and keeps sending SYN packets. Sensitive IDS alarms go off indicating a SYN flood! At the same time the disappeared host stops sending logs to the syslog server. The security system administrator goes to Defcon 1, but five minutes later everything returns to normal (the roaming user has left the "blind spot"). Another example is an "abnormal" amount of packet fragments coming from the WLAN side. Of course it could be a fragmented nmap or hping2 scan by an intruder or an overly curious user, but most likely it has

something to do with a much larger default maximum transmission unit (MTU) size on a 802.11 LAN (2312 bits on 802.11 vs. approximately 1500 bits on 802.3/Ethernet taking 802.1q/ISL into account). Whereas for a wireless networker these issues are obvious, for a system administrator not familiar with 802.11 operations they can be a pain in the neck, security and otherwise. After surveying the network, the next stage of penetration testing is dumping the traffic for analysis and associating with the audited LAN. However, being able to associate to the WLAN is not the end of a penetration test on a wireless network, as many security consultants would have you believe. In fact, it is just a beginning. If penetration testing is looking at the network through the cracker's eyes, then please do so! Crackers do not attack wireless networks to associate and be happy: They collect and crack passwords, attempt to gain root or administrator privileges on all vulnerable hosts in a range, find a gateway to the Internet, and connect to external hosts; finally they hide their tracks. Unless the penetration test demonstrated how possible everything just listed is, it has not reached its goal. Later chapters in this book are devoted to precisely this​describing proper penetration testing procedures on 802.11 LANs in detail and providing the instructions for working with the tools included on the accompanying Web site (http://www.wi-foo.com). Of course new versions of the tools inevitably come out frequently and completely new security software utilities are getting released. At the same time, the process from submitting the book proposition to seeing the work on the shelves is very lengthy. Nevertheless, we aim to provide the latest versions of everything you need to audit 802.11 LAN security and, at least, what we have described in the book should give you a good direction on where to look for the new releases and tools and what they are supposed to do. Besides, the accompanying Web site will be continuously maintained and posted with all recent developments in wireless security and new software releases. Visit it regularly and you won't be disappointed!

Summary There are a handful of sound reasons why people attack wireless networks and why your WLAN can be next on the crackers' list. Understanding the attackers' motivation is helpful in predicting the risk they present to your wireless network as well as useful in the incident response procedure. Whatever this motivation might be, penetration testing remains the only way to evaluate how susceptible your network is to various types of wireless attackers. To fulfill this function, wireless penetration testing must be structured, well-planned, and emulate the action of a highly skilled Black Hat determined to break in and abuse the tested network.

Chapter 3. Putting the Gear Together: 802.11 Hardware "You cannot fight to win with an unequipped army." ​Mei Yaochen When reading other books somewhat related to wireless penetration testing or just simple wardriving, the suggested hardware choice is both limited and amusing. It creates the impression that only this particular laptop brand together with that specific PCMCIA card type are useful for these aims. In reality, much depends on the hardware chosen, but there are precise technical reasons for such selection that are never listed in these sources. These reasons include client card sensitivity in dBm, client card chipset, the presence of connector sockets for an external antenna, client card power emission and consumption level, laptop/PDA battery power life and compatibility with UNIX-like operational systems, and so forth. That said, practically any wireless client card and PCMCIA/CF/SD slotcontaining mobile computer can be used for wireless hacking with some additional tweaking and different grades of efficiency. This is the main message of this chapter.

PDAs Versus Laptops The first question that beginners ask before assembling their kit is whether a laptop or a PDA should be used for wireless penetration testing of any kind. Our answer is to use both if you can. The main advantage of PDAs (apart from size) is decreased power consumption, letting you cover a significant territory while surveying the site. The main disadvantage is the limited resources, primarily nonvolatile memory. The CPU horsepower is not that important here as we are not cracking AES. Other disadvantages are the limited amount of security tools available in packages and lack of Compact Flash (CF) 802.11 cards with standard external antenna connectors (we have yet to see one). However, Secure Digital (SD) and CF memory cards are getting larger and cheaper, external connectors can be soldered to the cards, and both Linux and BSD can be successfully installed on major PDA brands. In addition, CF-to-PCMCIA adapters or PCMCIA cradles can be used to employ your favorite PCMCIA card with an MMCX connector. PCMCIA cradles for iPAQs supporting two client cards and an auxiliary built-in battery to compensate for the additional power consumption by the cards are simply great. When we talk about the use of PDAs in wireless penetration testing, we mainly mean Compaq's iPAQs and Sharp Zaurus. Wireless sniffers for other PDAs do exist; for example, the Airscanner Mobile Sniffer (Windows CE; free for personal use, downloaded from http://airscanner.com/downloads/sniffer/amsniffer.exe), and PocketWarrior (Windows CE; GPL, home page at http://pocketwarrior.sourceforge.net/). However, if you want more than just network discovery and packet capture, you will need a UNIX-enabled PDA with a collection of specific tools we describe in the following two chapters. Sharp Zaurus comes with the Embeddix Linux preinstalled, with the main install-it-yourself alternative being OpenZaurus based on the Debian Linux distribution. Although iPAQs come with Windows CE by default, Linux distributions like Intimate, Familiar and OpenZaurus can be installed on iPAQs by anyone willing to experiment with open source security tools on a StrongARM platform. In fact, you can buy an iPAQ with Familiar Linux preinstalled from http://www.xtops.de. The common GUI for these distributions offered by Xtops is Open Palmtop Integrated Environment (OPIE). OPIE is similar to Trolltech's Qtopia used by the Embeddix distro on Zaurus. Another Linux PDA GUI alternative is the GPE Palmtop Environment, based on a GTK+ toolkit and running over an X server. Unfortunately, the peculiarities of installing Linux on iPAQs go beyond the wireless hacking book boundaries, even though we might include them in further editions. The best place to look for how-to information and help on this topic is http://www.handhelds.org/. Of note, IBM has produced an experimental 802.11 security testing software for iPAQs running Linux. More about this software suite can be found at http://www.research.ibm.com/gsal/wsa/. Another possibility is running NetBSD to use the brilliant BSD-airtools suite and

Wnet (if ported from OpenBSD 3.2). This requires more effort and knowledge than installing Intimate or Familiar, but isn't the pursuit of knowledge what hacking is really about? To find out more about installing BSD on your beloved PDA, check out the NetBSD mail list at http://handhelds.org/hypermail/netbsd/. If you decide to remain on the Windows CE side, the best idea is to get a copy of AirMagnet, Sniffer Wireless PDA version, or PDAlert. Neither solution is cheap, but that is to be expected from proprietary software. Although a PDA running Linux or BSD can be turned into a very powerful wireless security auditing tool, the inconvenience of using a small keyboard allied to the price of the full kit (additional nonvolatile memory, PCMCIA cradle/CF 802.11 card, PDA-specific GPS device) and the time-consuming Linux/BSD installation (if not preinstalled) means that all but the most determined should stay away from PDA-only wireless security auditing. An additional issue is finding the 802.11a and now, 802.11g cards for PDAs, which are nearly nonexistent. However, there are YellowJacket and YellowJacket Plus suites for iPAQs designed for evaluating 802.11a WLANs and available from Berkeley Varitronics Systems (http://www.bvsystems.com/). Generally, Berkeley Varitronics produces a large variety of brilliant wireless site survey tools for a selection of protocols, although they come at a hefty price. We have found a compromise in the "PDA vs. laptop" question: Use the PDA running a tool like Kismet or Wellenreiter and some signal strength monitoring software (e.g., wavemon or Wireless Monitor) for site surveys and rogue access point (or even user) discovery and the laptop loaded with the necessary tools for heavy-duty penetration testing. As for which laptop to choose, just be sure your pick, as long as it can run Linux or BSD, has two PCMCIA slots and as much battery life as possible. The reasons for two and not one PCMCIA slots are explained when we come to certain man-inthe-middle attacks on WLANs in Chapter 8.

PCMCIA and CF Wireless Cards This is probably the most important choice when selecting the gear for your "rig" (a term used by many wardrivers for the complete kit of necessary equipment). The reason lies in the significant differences among the wireless client cards available, including the following: The chipset The output power level and the possibility of its adjustment The receiving sensitivity The presence and amount of external antenna connectors The support for 802.11i and improved WEP versions

Selecting or Assessing Your Wireless Client Card Chipset Major 802.11 chipsets include Prism, Cisco Aironet, Hermes/Orinoco, Symbol, Atheros AR5x10, and, nowadays, ADMtek ADM80211 and Atheros AR5x11. Let's explore each in further detail.

Prism Chipset Prism chipset, formerly from Intersil, Inc., is one of the oldest 802.11 transceiver chipsets, evolving from Prism I (original 802.11) to Prism II (802.11b), Prism III (802.11b), Prism Indigo (802.11a), Prism GT (802.11b/g), Prism Duette (802.11a/b), Prism Nitro (improved pure 802.11g networking), and Prism WorldRadio (802.11a, b, d, g, h, i and j standards support). It is a favorite chipset among hackers due to the complete openness of Intersil in the chipset specifications, operation, and structure. All Prism Evaluation Board documents, Reference Designs, Application Notes, tech briefs and a variety of general technical papers could be freely downloaded from Intersil's Web site. Wireless security software developers would probably be most interested in studying the Prism MAC controller, which communicates with the software drivers. The MAC controller firmware performs most of the basic 802.11 protocol handling and thus will determine whether the card can be used for the monitor mode sniffing, frame insertion, and manipulation or as an access point device. Figure 3-1 is a reference scheme of a very common Prism 2.5 device borrowed from Intersil's Web site.

Figure 3.1. Common Prism 2.5 device.

[View full size image]

It demonstrates the internals of a card or access point including power amplifier and detector, RF/IF converter and synthesizer, IQ modulator/demodulator synthesizer and, finally, the host computer interface made up by a baseband processor and MAC controller. It is important to note here that the MAC controller has a specific WEP engine for hardware-based WEP encryption processing, which spares the CPU cycles when WEP is enabled. This is important when we discuss 802.11i standard release implications in Chapters 10 and 11. As a result of Intersil's specification openness, a variety of open source tools operating with Prism chipset cards came into existence, some of them essential for wireless security auditing. There are more Linux drivers for Prism chipset cards than for any other 802.11 chipset cards on the market. Apart from the commonly distributed and used Linux-wlan-ng modules and utilities, these drivers include the following: Jouni Malinen's HostAP drivers for deploying Linux-based access points (important for Layer 1 man-in-the-middle attack and DoS testing and wireless honeypot deployment). Abaddon's AirJack, which is essential for Layer 2 man-in-the-middle attacks as well as determining close networks' SSIDs, some Layer 2 DoS attacks, and overall 802.11 frames manipulation. Prism54 drivers for newer Prism GT, Duette, and Indigo chipsets that do support the monitor mode for use with wireless sniffers and can be configured to run a software-based access point in a manner similar to HostAP.

Prism cards had very early FreeBSD support (the legacy awi device) and were the first 802.11 client cards to provide the RFMON mode capability and antenna diversity natively and without patching (see the comments on wlan-ng drivers later in the chapter). BSD-Airtools require a Prism chipset card to perform RFMON frame sniffing and dumping with prism2dump and dwepdump and WEP cracking with dwepcrack. Running a BSD-host-based 802.11b access point also requires a Prism PCMCIA or PCI device. The bottom line is that if you are serious about 802.11 penetration testing, you should get a decent Prism chipset card. If you plan to base your security audit effort around the BSD platform, you probably cannot do without it. Prism chipset PCMCIA and CF cards are known to be produced by Addtron, Asante, Asus, Belkin, Buffalo (CF cards only), Compaq, Demark, D-Link, Linksys, Netgate, Netgear, Proxim, Senao, SMC, Teletronics, US Robotics, Zcomax, and ZoomAir.

Cisco Aironet Chipset The Aironet chipset is a Cisco, Inc., proprietary chipset, developed on the basis of Intersil's Prism. Common opinion is that the Aironet chipset is a Prism II "on steroids." Cisco added some useful features to their Aironet cards, including regulated power output and the ability to hop through all ISM band channels without running a software-based channel hopper. Cisco Aironet cards are perfect for wireless network detection due to their excellent receiving sensitivity and seamless traffic monitoring from several access points running on different channels. On the other hand, you would not be able to lock these cards on a single channel or set of channels in the monitor mode because in this mode they will continue to hop through the band on a firmware level. Other useful features of the Cisco Aironet cards are the amber traffic detection light and well-supported antenna diversity (providing that you use the AirLMC350 series card with two external antenna connectors). These cards are very well supported across all common platforms including Microsoft Windows and practically any UNIX-like operating system in existence. The ACU configuration utility supplied by Cisco for both Windows and Linux is very user-friendly and has capabilities of a decent wireless site surveying tool. Unfortunately, because Cisco Aironet chipset specifications are proprietary and are different from the original Intersil Prism, HostAP drivers do not work with Cisco Aironet and neither does the AirJack. However, it is rumored that an undisclosed version of the AirJack driver for Cisco Aironet does exist. This limits the use of Cisco Aironet cards for man-in-the-middle attacks and DoS resilience testing. Nevertheless, these cards are our PCMCIA cards of choice for site surveying, rogue access points detection, and multiple-channel traffic analysis.

Hermes Chipset The third very common 802.11 client card chipset is the Hermes chipset developed by Lucent. These cards have been on the market for years and are well-developed products boasting good receiving sensitivity and user-friendliness. Even though they do not provide firmware hopping on all ISM band channels like Cisco Aironet, they tend to identify the transmitting access point and assume the correct network ESSID and frequency automatically as soon as the wireless interface is up. Most Hermes chipset cards boast an external antenna connector, but they rarely come in pairs. These connectors seem to be superior to the MMCX connectors on Prism and Cisco Aironet cards; they are tighter and less prone to damage. A pigtail slipping out of the wireless card is highly annoying; we have never seen it with Hermes chipset card connectors and pigtails. Although Hermes chipset specifications are closed source and proprietary, Lucent did publish a piece of source code for controlling the basic functions of their WaveLAN/ORiNOCO cards. It is a pared-down version of the HCF library used in their Windows driver and their binary-only Linux driver. The code was not easy to read and integrated poorly into the Linux kernel, but proved to be useful when the old wvlan_cs driver was written. The currently used orinoco_cs driver is an improvement over the original wvlan_cs, but it still uses its higher level functions, whereas the low-level function support partially originates from the BSD wi driver for both Prism and Hermes chipset cards. A patch released by The Shmoo Group (http://airsnort.shmoo.com/orinocoinfo.html) enables you to put Hermes chipset cards into a monitoring mode for proper second layer 802.11 frames analysis. Although HostAP drivers do not work with the Hermes chipset cards, there is currently a HermesAP project that is still in an early development stage, but looks very promising. You can find more information about it at http://www.hunz.org/hermesap.html. The bottom line is that with a little bit of driver patching, Hermes chipset cards are fine for full 802.11 penetration testing and might even have an advantage over their counterparts (except Cisco Aironet) when it comes to ease of use and configuration. Hermes chipset PCMCIA and CF cards include Buffalo PCMCIA, Dell Truemobile, IBM High Rate Wireless LAN card, Intel AnyPoint 802.11b, Lucent/Orinoco Silver and Gold, Lucent WaveACCESS, and Sony PCWA-C100.

Symbol Chipset The Symbol Spectrum24t chipset is specific for Symbol-based cards including Nortel Emobility 4121, 3Com AirConnect, Intel PRO/Wireless, and Symbol Wireless Networker Cards. Ericsson WLAN cards are also Symbol-based, but have a separate Linux driver (eriwlan). Symbol cards are Prism II cards with their own MAC layer controller. Surprisingly, under Linux they are supported by the orinoco

driver (read the orinoco.c source) and are similar to Hermes chipset cards in terms of configuration and usefulness in the penetration testing of WLANs. Symbol CF cards have an orinoco and spectrum24t-based driver that is different, as these cards don't have built-in firmware. At http://www.redbean.com/~proski/symbol/readme, you can find more information about "nofirmware" Symbol cards and download a Spectrum24 Linux driver. However, for Layer 2 traffic analysis in the monitor mode, the morinoco patch (http://www.cs.umd.edu/~moustafa/morinoco/morinoco.html) has to be applied. Jesus Molina provides a package of the Spectrum24 CF driver already patched with the morinoco patch with some additional old kernel versions for backward compatibility. A good example of a common Symbol chipset card is a low-power Socket CF card from Socketcom. Although this card does save your PDA battery power, it has a lower transmitting and receiving range compared to more powerhungry cards, but always remember that everything comes with a price. The precompiled packages of Spectrum24 Linux driver (kernel 2.4.18) for this card, patched for monitor mode frame capture and supplemented by useful comments on configuring the card, are available at http://www.handhelds.org/~nils/socketcf-wlan.html.

Atheros Chipset The Atheros AR5000 chipset is the most commonly encountered chipset in 802.11a devices. This chipset combines the world's first 5 GHz "radio-on-a-chip" (RoC) and a host computer interface (baseband processor + MAC controller). It supports the Turbo Mode (72 Mbps theoretical speed) and hardware-based WEP encryption at 152 bits or less. Because it relies on a standard-process CMOS, both power consumption and the device costs are low, and the operational reliability is enhanced. AR5001x is a further evolution of AR5000 and is a common chipset in modern combo 802.11a/b/g cards. Because we are interested in "hackable" drivers for 802.11a cards, which would let us monitor and inject traffic on a second layer, the most suited are Madwifi and Vantronix vt_ar5k drivers for Linux available from http://team.vantronix.net/ar5k/ and the Madwifi project at SourceForge. The list of vt_ar5k supported 802.11a cards includes Actiontec 802CA, Netgear HA501, Netgear HA311, Proxim Harmony, SMC 2735W, Sony PCWA-C500, IODATA WNA54/PCM, and ICom SL-50. Unfortunately, the combo card support is not fully implemented yet and in our experience with vt_ar5k and Netgear 32-bit CardBus WAG511 and Orinoco Gold Combo cards the lead goes on and the card is detected, but the vt_ark5k module does not load. Nevertheless the supported card's vt_ar5k driver provides raw sniffing mode support and aims to implement frame injection in the future; stay tuned. Hopefully, by the time you hold this book in your hands, vt_ar5k combo card support is fully implemented.

Madwifi Linux drivers also provide support for 802.11a/b/g universal NIC cards based on the Atheros chipset. At the moment, these drivers are probably what you need to use for your 802.11a/b/g combo card under Linux. The official project is located at Sourceforge (http://sourceforge.net/projects/madwifi/). Additional information about madwifi drivers can be found at http://www.mattfoster.clara.co.uk/madwifi-faq.htm and Madwifi Wiki page http://madwifiwiki.thewebhost.de/wiki/. Before installing the modules, we recommend visiting these sites to get the latest details on the project and familiarize yourself with the FAQs. Even though these drivers are in an early development state, they have been proven to work on many Atheros-based combo wireless cards. We have tested Proxim 8480-x and Netgear WAG511 and found them to work reasonably well at 18 to 24 mbits per second. Some people have reported performance, WEP, and power-management-related issues with Proxim 848x-based cards, so check the latest CVS source and patches section of the project page. Madwifi drivers are RFMON-friendly and are supported in the current versions of Kismet (see the kismet.conf file for more details).

ADM8211 Chipset Finally, there is an ADM8211 chipset originating from ADMtek, Inc. (http://www.admtek.com.tw/products/ADM8211.htm). This chipset is becoming common in combo 802.11a/b/g cards. At the same time, very little is released in terms of ADM8211 specifications. It appears that the driver for the ADM8211 takes responsibility for more 802.11 MAC functions than the older drivers for Lucent/Prism/Aironet cards; BSD-wise the driver will be more similar to awi than wi or an. We have initiated a discussion in the open source community about the development of multifunctional Linux and BSD drivers for ADM8211, supporting RFMON mode and hopefully, access point functionality. There are clear signs of enthusiasm and we hope that in the near future such drivers will exist. In the meantime, ADMtek has released precompiled drivers for kernel 2.4.18-3 oriented toward Red Hat 7.3 distribution. The source code for these drivers was posted at http://www.seattlewireless.net/index.cgi/DlinkCardComments. We expect that the development of open source drivers and configuration utilities for both AR5001x and ADM8211 chipset cards will grow quickly and porting and development of major wireless security applications will follow. We also hope that AR5001x and ADM8211 cards with external antenna connectors will eventually come out and these connectors will be compatible with the existing pigtail types. For now, the best idea is to stick to Prism, Aironet, or Hermes chipset cards for 802.11b/g and AR5000 chipset cards for 802.11a security auditing. Backward compatibility of 802.11g helps everyone, penetration testers and crackers alike.

Other Chipsets That Are Common in Later Models of 802.11Compatible Devices As more and more hardware vendors join the wireless chip manufacturing race, the diversification of 802.11 chipsets available on the market continues. Examples of newer wireless chipsets include Texas Instruments's ACX100, Atmel AT76C503A, Broadcom AirForce, InProcomm IPN2220, Realtek RTL8180L, and Intel PRO/Wireless (Centrino). From the wireless security auditor and hacker viewpoint, it is important to have open specifications and open source drivers for these chipsets, allowing the monitor mode, software access point functionality, and ability to build and mangle wireless frames. Whereas some of the chipsets listed satisfy these requirements and have decent Linux and even BSD support (e.g., ACX100), others aren't that "hacker-friendly" and might have to be used under Linux via the Linuxant DriverLoader (http://www.linuxant.com/driverloader). DriverLoader is a compatibility wrapper that allows standard Windows drivers provided by hardware manufacturers to be used as is on Linux x86 systems. NdisWrapper is another project similar to the DriverLoader that supports a few chipsets that do not have open source drivers available at the moment of writing, namely Broadcom, Intel PRO/ Wireless (Centrino), and InProcomm IPN2120. Although the standard end-user connectivity and even 802.11i security features are provided by using the vendor drivers through the DriverLoader or NdisWrapper, do not expect to run your favorite UNIX wireless network discovery and penetration tools under the Windows NDIS drivers launched using the wrapper applications. Thus, if you are not a developer interested in creating, improving, or modifying drivers for these chipsets and porting existing wireless security auditing tools to be used with such drivers, steer clear of novel or littleknown wireless chipset devices unless you are absolutely sure that working open source drivers for that particular chipset exist. Check out the updates at the Linux Wireless Drivers in the Construction and Defense Tools section of our Web site (http://www.wi-foo.com) to see which open source drivers are currently available for download.

Selecting or Assessing Your Wireless Client Card RF Characteristics After determining the chipset, the next things to look for in an 802.11 client card are its power output, the possibility of power output regulation, and receiving sensitivity.

The RF Basics: Power Calculations The transmitting power output is estimated at two different points of a wireless system. The first point is called an intentional radiator (IR). IR includes the radio transmitter and all cabling and connectors but excludes the antenna used. The second point is the power actually irradiated from the antenna, designated as the equivalent isotropically radiated power (EIRP). Both IR and EIRP outputs are legally regulated by the Federal Communications Commission (FCC) in the United States (see Part 47 CFR, Chapter 1, Section 15.247) or European Telecommunications Standards Institute (ETSI) in the European Union. To measure both the power of the emitted energy and the receiving sensitivity of your wireless device, watts (more often milliwatts [mW]) or decibels are used. Power gain caused by antennas and amplifiers as well as power loss caused by distance, obstacles, electrical resistance of cables, connectors, lightning protectors, splitters, and attenuators is estimated in decibels or, to be more precise, dBm. The m in dBm signifies the reference to 1 mW: 1 mW = 0 dBm. Antenna power gain is estimated in dBi (i stands for isotropic), which is used in the same way with the dBm in RF power calculations. Decibels have a logarithmic relationship with watts: PdBm = 10log pmW. In simple terms, every 3 dB change would double or halve the power and every 10 dB difference would increase or decrease the power by an order of magnitude. The receiving sensitivity of your wireless devices will be affected in the same way. To calculate the EIRP value of your wireless kit, simply sum all dBm values of devices and connectors involved. For example, a standard wardrivers' rig consisting of a 20 dBm (100 mW) PCMCIA client card, 2 dBm loss long pigtail connector, and 5 dBi gain magnetic mount omnidirectional antenna would have 20 ​ 2 + 5 = 23 dBi or 200 mW power output. Note that each 6 dBi increase in EIRP doubles the transmission or reception range (so-called 6 dB Rule). A Milliwatts-to-dBm conversion table is given in Appendix A for your power estimation convenience. Also, there are many RF power calculators available, including online tools such as the following: http://www.zytrax.com/tech/wireless/calc.htm http://www.ecommwireless.com/calculations.html http://www.csgnetwork.com/communicateconverters.html http://www.vwlowen.demon.co.uk/java/games.htm http://www.satcomresources.com/index.cfm?do=tools&action=eirp However, if you deal with wireless networking on a regular basis, it is vital to familiarize yourself with RF power calculations and be able to perform basic calculations of mW/dBm conversions and EIRP output in field conditions without any tools or tables available.

When looking at both power output and the receiving sensitivity of wireless equipment through the cracker's eyes it is quite simply "the more, the better." Higher power output means the chance of connecting to the target network from a longer distance, better capability to launch jamming DoS attacks, and increased chances of Layer 1 man-in-the-middle attack success. Better receiving sensitivity means more wireless networks detected when scouting, higher connection speed when associating to the WLAN, and more wireless traffic dumped and analyzed. If more WEP-encrypted traffic can be captured, more interesting IV frames should be sniffed out and the process of cracking WEP (see Chapter 8) should take less time. To our surprise, no one has ever investigated this matter by using a variety of client cards with very different receiving sensitivity values (dBm). Anyone who wants us to check this area is more than welcome to send us appropriate client

hardware for testing by contacting us at [emailprotected]. As for the wireless equipment selection for your networking and security auditing practice, we have included modified tables of 802.11 equipment characteristics originally published at the Seattlewireless and Personaltelco Web sites (Appendix B). The separate table devoted to Prism chipset cards is included due to the significance of these cards for wireless penetration testing and open source software development. Check the wireless community Web sites mentioned for the most recent updates and use these tables when selecting the hardware to fit your specific requirements. Client cards that are excellent for building a 802.11 security auditing kit might not be the best cards for end-user wireless networking and the opposite might be true. The issues we have not covered yet are the regulated power output and the presence of MMCX external antenna connectors. Out of the cards that we have tried, Cisco Aironet, Senao Long Range, and Zcomax XI-325HP had regulated IR output. Being able to adjust the IR is essential in both attack (stealth, preserving battery power) and defense (limiting the network perimeter, spread, and detectability) on WLANs: We return to this topic many times as the appropriate area is reviewed. The importance of external antenna connectors can never be underestimated, even though you might want to have an additional client card with a built-in antenna for indoor security testing. There are many sites that describe how to weld a pigtail for an external antenna onto the built-in antenna connector; such is the (time and effort) price of not looking for a card with MMCX connector(s) in the first place. Finally, although the support for larger WEP key sizes and 802.1x might appear to be more relevant for the Defense chapters, it is useful to have it on a client card that is used for penetration testing. It can come in handy when connecting to the proprietary larger WEP key size network after the key was broken or for brute forcing or guessing 802.1x access. To summarize, proper selection of 802.11 client hardware and firmware is the first essential step in a successful wireless security audit. However in the majority of cases you shouldn't worry if you did not pick your PCMCIA/CF specifically for that. With some minor patching and reconfiguration, any client card should work fine. An exception is some of the rare chipset newest combo a/b/g 32-bit cardbus cards, but the development of flexible open source drivers for these is on the way and, hopefully, you won't have to wait for long until they are out and supported by 802.11 security auditing tools. Pay attention to the card receiving sensitivity (the difference between -80 and -90 dBm is a factor of 10; think what kind of impact it will have on the distance of network discovery and amount of data dumped). A cracker with a highly sensitive and powerful card linked to a highgain antenna (mind the connectors!) might be able to attack from a position in which you could never expect him or her to be. Think about it when performing your WLAN site survey as the first stage of a proper wireless security audit. Do not assume that the attackers will try to get as close as they can and won't have

equipment allowing them to attack from long range. After all, more sensitive and powerful cards are not obviously more expensive, cheap high-quality antennas are abundant, and prices on amplifiers are slowly falling. The cost of assembling a very decent attacker's kit is not higher than the cost of deploying a casual home WLAN.

Antennas Security-wise, antennas and amplifiers give an enormous edge to both the skillful attacker and defender. From the attacker's perspective, antennas give distance (resulting in physical stealth), better signal quality (resulting in more data to eavesdrop on and more bandwidth to abuse) and higher power output (essential in Layer 1 DoS and man-in-the-middle attacks). From the defender's perspective, correctly positioned antennas limit the network boundaries and lower the risk of network detection while reducing the space for attackers to maneuver. In addition, three highly directional antennas in conjunction with mobile wireless clients, running signal strength monitoring software, can be used to triangulate the attacker or a rogue wireless device. This is, of course, dependent on the attacker actually transmitting some data. A self-respecting wireless security company should be able to provide the triangulation service as a part of an incident response procedure. Unfortunately, this is not usually the case. Before we provide suggestions on antenna use in wireless security auditing, a brief overview of antenna theory basics is necessary. If you are an RF expert you can safely skip the intermezzo and move forward.

The RF Basics: An Introduction to the Antenna Theory There are two main characteristics in antennas: gain (or power amplification) provided by an antenna, and beamwidth (which shapes the antenna coverage zone). In fact, it makes sense to look at the zone of coverage as a third variable, because side and back beams of some antennas are difficult to describe in terms of beamwidth. You should always demand the antenna irradiation pattern diagram from the vendor to assess the shape of the antenna irradiation (if only approximately). A future site survey will show how closely the provided diagram corresponds to the truth. We have collected diagrams from some vendors in Appendix C for your convenience as well as an aid to understanding the distinctions between different types of antennas. Another often overlooked antenna characteristic is the antenna polarization, which can easily be changed by altering the antenna position. We cover the security significance of antenna polarization in Chapter 10. An antenna's gain is estimated in dBi because it is referenced to an abstract isotropic irradiator, a fictional device that irradiates power in all directions (a star is an example of such a device). It is defined as passive because no power is injected by an antenna. Instead, the gain is reached by focusing the irradiated waves into a tighter beam. The beamwidth can be both horizontal and vertical; never lose the 3D perspective! There are three generic types of antennas that differ by irradiation pattern and beamwidth and can be further divided into subtypes. These types include: 1. Omnidirectional antennas Mast mount omni Pillar mount omni Ground plane omni Ceiling mount omni 2. Semidirectional antennas Patch antenna Panel antenna Sectorized antenna Yagi antenna 3. Highly directional antennas Parabolic dish Grid antenna Omnidirectional antennas have a 360-degree horizontal coverage zone and reach gain by decreasing the vertical beam. The irradiation pattern of an omnidirectional antenna resembles a doughnut with the antenna going through the doughnut's hole. The ground plane antennas (and some ceiling mount omnidirectionals with a ground plane) prevent the irradiation from spreading downward or upward. For the magnetic mount omnidirectionals loved by wardrivers, the car serves as the ground plane. A typical use of omnidirectional antennas is providing point-to-multipoint (hub-and-spoke) links for multiple clients or even networks, using semidirectional antennas for multiple connections to a powerful central access point hooked up to an omni. Semidirectional sectorized, patch, and panel antennae form a "bubble" irradiation pattern spreading in 60 to 120 degrees in direction. They are frequently used to cover an area along a street or a long corridor; sectorized semidirectionals placed in a circle can act as a replacement for an omnidirectional, having the advantage of higher gain and vertical bandwidth (but at a higher price). Yagis form a more narrow "extended bubble" with side and back lobes. A typical use for a yagi is establishing medium-range bridging links between corporate buildings as a very cheap alternative to laying fiber where the CAT5 with its 100 m limit for 100BaseT Ethernet cannot reach. Highly directional antennas emit a narrowing cone beam capable of reaching the visible horizon and are

used for long-range point-to-point links, or where a high-quality point-to-point link is required. Due to their usually high gain, directional antennas are sometimes used to blast through obstacles such as walls when no other alternative is present.

Sometimes the antennas take rather bizarre shapes (e.g., flag yagi), sometimes they are well-hidden from prying eyes (many of the indoor patch or panel antennas), and sometimes they look like fire alarms (small ceiling-mount omnis). Spotting wireless antennas is an important part of a site survey, which might help you determine the overall shape of the wireless network before turning on your monitoring tools. Pay particular attention to the back and side lobes, such as the ones in yagi's irradiation patterns; the network might span somewhere the system administrator without knowledge of RF basics might never expect it to be. When selecting your antennas for wireless security audit, a decent omnidirectional and a high-gain, narrow-beamwidth antenna are the minimum. We usually use 12 dBi omni and 19 dBi grid directional, but you should pick the antennas that suit you best. An omnidirectional comes in handy when surveying a site, looking for rogue access points, analyzing traffic from several hosts positioned in different directions, and monitoring the area for unauthorized or suspicious traffic or interference. You should always keep in mind that with a higher gain the "doughnut" becomes flatter, and while using a higher gain omni you might not discover wireless hosts positioned below or above the coverage zone (e.g., hosts in the same building but on different floors). On the other hand, a lower gain omni might not be sufficiently sensitive to pick these hosts up. This is a possible case for using a semidirectional antenna (we use 15 dBi yagis). Alternatively, you can do a thorough scan with a narrow beamwidth directional, but remember both horizontal and vertical beamwidth planes! When it comes to the use of directional antennas, there are several obvious advantages: You can check how far a well-equipped cracker can position himself or herself. You can blast through walls and see how much data leaks through. It is essential for trying out jamming and certain man-in-the-middle attacks. It is vital for determining the attacker's position. Some networks can only be discovered using a decent gain directional (or semidirectional). These include the WLANs on the top floors of very tall buildings.

There is considerable information (even in the popular media) on making your own antennas from Pringles tubes, empty tins, and so forth. Although it is a cool hardware hack and worth trying in your free time, we do not recommend using these antennas in serious commercial wireless penetration testing. Their beamwidth, irradiation pattern, gain, and some other important criteria, such as voltage standing wave ratio (VSWR; should be approximately 1.5:1) are rarely verified and the performance can be unreliable. Of course, there are cases when homemade antennas beat the commercially built ones by a large margin. Nevertheless, properly quantifying the do-it-yourself antennas parameters just listed is difficult and expensive, which makes defining and documenting your site survey results difficult. At the same time, it is easy to get a decent 2.4​2.5 or 5.15​5.85 GHz antenna for a very reasonable price (we recommend http://www.fab-corp.com, but there are many other affordable online WLAN antenna stores).

RF Amplifiers Whereas the antennas achieve passive gain by focusing the energy, amplifiers provide active gain by injecting external DC power into the RF cable. This power is sometimes referred to as "phantom voltage" and is carried by the RF cable from a DC injector to an amplifier. There are two types of amplifiers: unidirectional (which only increase the transmitting power) and bidirectional (which improve the receiving sensitivity as well). In addition, both amplifier types come as fixed or variable gain devices. For a network design purpose, fixed power gain amplifiers are recommended for overall stability reasons and because all necessary RF power calculations should be done prior to the network deployment and you should be aware of your network power needs. Traditionally, amplifiers are deployed to compensate for loss due to significant cable length between an antenna and the wireless device. It is unlikely that you will need one in your penetration testing procedure, as it is cheaper and more convenient to use a highly directional antenna. However, if you have additional cash to spare, you might want to purchase a bidirectional amplifier to use in conjunction with the directional antenna for typical power-demanding security experiments such as long-distance connectivity and traffic analysis, or jamming and Layer 1 man-in-the-middle attacks. Unlike the actual network design case, variable gain amplifiers are recommended for testing purposes, security testing included. For example, you might want to tweak the amplifier power to find at which EIRP a Layer 1 man-inthe-middle or DoS attack will succeed. The main problem with using amplifiers for security evaluation is providing a mobile power source. For this reason, amplifiers are rarely used by casual attackers. However, the use of one by a determined stationary attacker cannot be excluded.

RF Cables and Connectors The final word is on using RF cables and various connectors. As mentioned before, RF cables are one of the major sources of loss on wireless networks. Do not save money on cabling​get the lowest attenuation rating (estimated in dB loss per 100 feet at a given frequency) cables possible. Get cables with preinstalled connectors. Installing connectors yourself is possible, but the end result is likely to be less reliable than the industry standard. RF signal loss due to bad connectors or damaged cables can be enormous, yet hard to discover. Do not forget that the cable should have the same impedance (usually 50 Ohms) as the rest of your wireless components. Choose cable connectors that suit your client devices and existing antennas. You can connect anything with appropriate cheap barrel or crimp connectors, but just one such connector might bring an additional 2 to 3 dB loss, halving your transmission power and receiving sensitivity. When it comes to wireless hardware, pigtail connectors gave (and keep giving) us the biggest headache of all. In mobile site survey and security evaluation practices, pigtails quickly wear off, the connectors are easily broken, and you have to ensure that the MMCX connector does not slip off the client card (fixing it to the card or laptop with a sticky tape helps). The most common pigtails are Aironet-type, which also fit the majority of Prism chipset cards, and Lucent/Orinoco pigtails, which fit Hermes chipset cards. In our experience, the latter are of better quality and lock on a card in a more reliable way. Make sure you have spare pigtails so as not to be caught by a broken one in the middle of your security audit. Remember, although cabling and connectors are not directly relevant to wireless security, it doesn't matter what side of wireless networking you are involved with, a strong, clear signal and good receiving sensitivity are essential. A WLAN with significant signal loss would have a very low resilience to jamming and Layer 1 man-in-the-middle attacks. This is yet another point that underlines the "network security and reliability from the initial design stages" concept.

Summary Thoughtful selection of wireless hardware for your security evaluation tasks can save a lot of time, effort, and money and tremendously increase your capability to run the attacks. Such selection should be based on the specific technical criteria that we have briefly outlined in this chapter. It should not stem from advertisem*nts or recommendations not reinforced by thorough and wellargumented technical explanation. Nevertheless, you can probably use any wireless client card you already have for penetration testing, albeit with some additional patching and tweaking. Various tasks require different wireless hardware for maximum security auditing efficiency. Don't bet on a single set of hardware to suit all cases; be prepared for different methodologies and hardware sets depending on the target and the audit demands.

Chapter 4. Making the Engine Run: 802.11 Drivers and Utilities "As one of the ancient strategists said, 'Those who cannot deploy their machines effectively are in trouble.'" ​Du Mu

Operating System, Open Source, and Closed Source It is no secret that the majority of the techniques and methodologies we describe are based on open source (both GPL and Berkeley-licensed) software. There are several reasons for this. When doing anything related to wireless hacking (see the Introduction for our definition of hacking), you want to operate with "hackable" software you can modify and optimize for your specific needs and hardware at hand. This book is oriented toward wireless community activists and enthusiastic users as well as corporate professionals and security consultants, so we want to describe affordable techniques and solutions. Finally, as long as penetration testing is supposed to be looking at the network through the cracker's eyes, we should stick to the same methodology used by Black Hats. Do you really expect a cracker to use a copy of the latest $5,000 closed source wireless protocol analyzer? In addition, many of the "underground" attacking tools we describe have features no commercial product possesses; never underestimate the power of the Black Hat community. For example, there isn't a commercial wireless security auditing tool capable of cracking WEP or generating custom 802.11 frames (to our knowledge, anyway). Naturally, Linux comes as the platform of choice for running, tweaking, and developing such software. BSD is our second choice (mainly due to the smaller size of the developer community and somewhat smaller list of supported hardware). Unfortunately, to our current knowledge, there is no 802.11a support under any BSD flavor at the time of writing. However, some reviewed 802.11b/g security-relevant tools and commands are BSD-specific (BSD-airtools, Wnet, leapcrack), and BSD systems have decent 802.11b software access point support. Nevertheless, in our opinion Linux HostAP has more functionality and is more configurable than BSD software AP implementations. Why do we use Linux? The main reason is simple: It is easy to use. You can use the tools described as they come, without any additional modification. If you are bound to the Microsoft platform, you can install Cygwin (http://www.cygwin.com), Perl, and port a variety of existing relevant UNIX tools and scripts to run using Windows headers and libraries. This would work fine, but would take a lot of unnecessary effort. Installing Linux or BSD is much easier and saves time. There are also multiple commercial (and even freeware) wireless-related tools for Windows. The high-end commercial tools like Sniffer Wireless or AiroPeek are powerful, but somewhat costly. The low-end tools such as Netstumbler or the majority of Windows Freeware 802.11 "sniffers" are not up to the job; we outline the reasons for this in Chapter 5. There are some brilliant exemptions, such as the Packetyzer/Ethereal for Windows combination. Somehow, these exemptions happen to be released under the GPL. However, the approach taken in the "Defense" part of this book is different. As a security consultant or enthusiast, you might have the freedom and opportunity to

select wireless security auditing hardware and software that suits you the best. As a system administrator or network manager, you have to defend what your company has by using existing resources, possibly without significant additional funds or available time. Thus, the defensive countermeasures are platformindependent and range from using free open source tools to deploying high-end commercial wireless gateways and IDS systems. For now, we review 802.11 configuration utilities and drivers from a Linux, and partially BSD, perspective with penetration testing in mind. If you are not a part of the UNIX world, don't worry. We tried to simplify the described methodologies as much as possible. Our apologies to seasoned UNIX hackers; you know which bits and pieces you can safely skip. We have aimed to provide an easy step-by-step installation, configuration, and usage instructions for all utilized tools and utilities.

The Engine: Chipsets, Drivers, and Commands A good thing about Linux drivers is their universal separation by the client card chipset: linux-wlan-ng, HostAP, and AirJack for Prism cards; Orinoco and HermesAP for Hermes cards; airo-linux for Cisco Aironet; Orinoco/Symbol24 for Symbol cards; vt_ar5k for Atheros 802.11a; and initial ADM8211 drivers and Madwifi for ADM8211 and Atheros 5212 in many 802.11a/b/g combo cards. However, all these drivers use the same /etc/pcmcia/wireless.opts configuration file, supplemented by more specific configurations such as wlanng.conf, hermes.conf, hostap_cs.conf, or vt_ar5k.conf. These additional files contain the description of 802.11 cards known to be supported by a particular driver they come with. As to the configuration utilities and scripts, the majority of listed card types use Jean's Tourrilhes Linux Wireless Extensions, apart from linux-wlan-ng (which has its own wlancfg and wlanctl-ng configuration utilities) and Cisco Aironet (configured by editing a text file in /proc/driver/aironet created when the card is initialized, usually /proc/driver/aironet/eth1/Config). Being rather flexible, Cisco Aironet cards can also be configured using Linux Wireless Extensions or through an ACU GUI utility. Due to this difference there are different initialization scripts for linuxwlan-ng (/etc/pcmcia/wlan-ng) and cards configured using Linux Wireless Extensions (/etc/pcmcia/wireless). Under BSD, wireless drivers for Prism and Hermes chipset cards are grouped into the wi interface driver, whereas Cisco Aironet cards are supported by the an device. Other (Free) BSD wireless device drivers you might encounter are ray for Raylink-based and awi for old Prism I cards. The configuration of wireless client cards on BSD is done via the wicontrol utility for Prism and Hermes chipset cards (listed later in the chapter) or ancontrol for Cisco cards. On FreeBSD versions above 4.5, the functionality of both wicontrol and ancontrol is merged into ifconfig, but both wicontrol and ancontrol are still there. The startup configuration scripts for FreeBSD have to be written by the user, but this is easy. A good example of such a script placed into /usr/local/etc/rc.d is given in Bruce Potter's and Bob Fleck's "802.11 Security." On OpenBSD, necessary parameters for wireless card initialization can be added to the file, such as hostname.an0 or hostname.wi0. Whereas the Linux and BSD configuration files and utilities are pretty much unified by the chipset type, under Windows these utilities and files are specific for a particular card brand. Thus, a comprehensive review is outside the scope of this book, considering the amount of 802.11 client cards available on the market. We suggest you read the instructions provided by the card manufacturer.

Making Your Client Card Work with Linux and BSD The first step in installing your 802.11 client card under Linux or BSD is choosing the correct options in the kernel and compiling pcmcia-cs Card Services. If you use a vanilla kernel or a kernel that comes with your default distribution installation, chances are that the modules for your wireless card are already compiled and included and the Set Version Information On All Module Symbols option is enabled. This is fine as long as you use the Prism chipset cards only, which support RFMON sniffing mode by default using the majority of linux-wlanng driver versions. You can even compile Prism support into the kernel. Otherwise you should use patched (Orinoco/Hermes) or third-party (Sourceforge airo-linux) modules when setting up a system for security audits (Aironet drivers that come with the latest linux kernels are actually fine). Specific drivers such as HostAP do not come with the kernel and have to be compiled separately. In such cases you should disable Set Version Information On All Module Symbols and should not try to compile your card support into the kernel, instead compile it as modules (see Figure 4-1).

Figure 4.1. Kernel loadable modules support.

[View full size image]

You can either skip selecting the modules coming with your kernel or overwrite them later with the patched modules when installing pcmcia-cs or card-specific drivers.

After the kernel compiles (read Kernel-How-To if you never compiled one), you should build the pcmcia-cs package. We do not recommend using the precompiled pcmcia-cs distribution packages due to the patching and the future need for pcmcia-cs sources if you want to build other tools. Before building pcmcia-cs, you might need to apply the Shmoo patch, which can be obtained from http://airsnort.shmoo.com/orinocoinfo.html. Pick a patch appropriate for your particular pcmcia-cs version and execute:

arhontus:~# patch -p0 < pcmcia-cs-"your-pcmcia-cs-version"-orinoco-patc

Alternatively, you can download the orinoco-cs driver, patch it, and replace the unpatched sources in /usr/src/pcmcia-cs-"current-version"patched/wireless by the patched one. Also, you can compile the patched modules separately and copy them into /lib/modules/"yourkernelversion"/pcmcia, perhaps over the unpatched ones that come with a distribution kernel. If you intend to do this, you need to disable the "Set version information on all module symbols" option. If you use Cisco Aironet, don't use the default drivers that come with the card or the Cisco Web site because they don't support RFMON mode. Instead download airo-linux drivers from Sourceforge (http://sourceforge.net/projects/airo-linux/). The easiest way of installing them is copying the airo.c and airo_cs.c sources from airo-linux into the wireless subdirectory of the pcmcia-cs. If you use the modules that come with the kernel, you'll have to apply the patch packaged with the airo-linux software. Because this patch is only applicable to kernel 2.4.3, this is not recommended. However, all the latest kernels provide RFMON-enabled Aironet drivers. Therefore, if you keep your kernel up to date, you can safely use the modules that came with the kernel. If you want to overwrite the original kernel modules, use ./configure --force flag when compiling pcmcia-cs. Otherwise simply execute:

arhontus:~# make config

-------- Linux PCMCIA Configuration Script --------

The default responses for each question are correct for most users. Consult the PCMCIA-HOWTO for additional info about each option.

Linux kernel source directory [/usr/src/linux]:

The kernel source tree is version 2.4.20. The current kernel build date is Thu Mar 6 22:53:57 2003.

Build 'trusting' versions of card utilities (y/n) [y]: Include 32-bit (CardBus) card support (y/n) [y]: Include PnP BIOS resource checking (y/n) [n]: Module install directory [/lib/modules/2.4.20]:

Kernel configuration options: Kernel-tree PCMCIA support is enabled. Symmetric multiprocessing support is disabled. PCI BIOS support is enabled. Power management (APM) support is enabled. SCSI support is enabled. IEEE 1394 (FireWire) support is disabled. Networking support is enabled.

Radio network interface support is enabled. Token Ring device support is disabled. Fast switching is disabled. Frame Diverter is disabled. Module version checking is disabled. Kernel debugging support is enabled. Memory leak detection support is disabled. Spinlock debugging is disabled. Preemptive kernel patch is disabled. /proc filesystem support is enabled.

It looks like you have a System V init file setup.

X Window System include files found. Forms library not installed.

If you wish to build the 'cardinfo' control panel, you need the forms l Window System include files. See the HOWTO for details.

Configuration successful.

Your kernel is configured with PCMCIA driver support. Therefore, 'make

the PCMCIA utilities but not the drivers.

arhontus:~# make all && make install && make clean

This will finish the job. You need to build trusting versions of the card utilities if you want non-root users to be able to suspend and resume pcmcia cards, reset cards, and change the current configuration scheme. The 32-bit CardBus support is only necessary for using 32-bit CardBus cards, such as the current combo a/b/g cards, as well as many recent 802.11a and 802.11b cards that support proprietary 22 Mbps or 108 Mbps speed enhancements. It is not needed for older 16-bit PC cards. Prism chipset card drivers such as prism2_cs and p80211 are not included within the wireless subdirectory of PCMCIA-cs: They have to come with the kernel, or be built and installed when compiling linux-wlan-ng. Installing PCMCIAcs creates the /etc/pcmcia directory, which can be modified later when you compile other wireless card drivers like linux-wlan-ng or HostAP. If you use multiple wireless cards with different chipsets on the same laptop, we recommend keeping /etc/pcmcia configs for each chipset card separately. Then you will be able to switch between different chipset cards easily. For example, if your current card is Orinoco and you want to change it to Prism, a good option is this:

arhontus:/#rm -rf /etc/pcmcia && cp -r /usr/local/wireless/pcmcia-wlan/etc/init.d/pcmcia restart

Make sure you have a backup for all of the configuration files. For your convenience we have included samples of PCMCIA configuration files for Wlan-ng, Hermes, HostAP, and Ark chipset cards on the http://www.wi-foo.com Web site. The given PCMCIA Ark configuration files also support Wlan-ng. As long as airo_cs and airo modules are correctly installed, the Cisco Aironet cards are unaffected by the peculiarities of /etc/pcmcia config files and will work with all config files without any need to restart PCMCIA services. You can always check the status of the card by using the cardctl:

arhontus:~# cardctl config && cardctl info && cardctl status

or even using the graphical cardinfo (Figure 4-2) utility, which lets you control the card in the same way /etc/init.d/pcmcia script does.

Figure 4.2. Cardinfo graphical utility.

To use 802.11a PCMCIA cards with an Atheros chipset, select the kernel PCMCIA support, compile the vt_ark5k driver (edit the Makefile if your Linux kernel source is not in /usr/src/linux), and insert "options vt_ar5k reg_domain=???" into /etc/modules.conf. There is a variance according to the country you are in and its power output regulations; the available options are fcc (U.S.), etsi (E.U.), and de (Germany and Japan). Alternatively, you can specify these options when the module is inserted (e.g., insmod vt_ar5k.o reg_domain=fcc). When the card services are restarted, you should see the module with lsmod and the card should be recognized. Alternatively, you can use the Madwifi project drivers, in particular when trying to set up and configure a combo 802.11a/b/g Atheros chipset card. As of the time of writing, the latest version of the driver was madwifi-20030802, but as we have found out, the CVS version is more stable, provides support for more Wi-Fi cards and has faster network performance. To obtain the latest CVS driver use the following command:

arhontus:$ cvs -z3 -d: \ pserver:[emailprotected]:/cvsroot/madwifi co madwifi

To compile these modules for 2.6.x Linux kernels, you should consider downloading relevant patches from the project page. For illustration purposes, this section describes madwifi installation under 2.4.x based kernels. To compile Wi-Fi modules, change the current working directory to madwifi CVS and issue:

arhontus:$ make all && make install

To load the modules, make sure the wifi card is inserted and type modprobe ath_pci. If all goes well, you should have similar output to lsmod and iwconfig commands:

arhontus:~#lsmod Module

Size

Used by Tainted: P

ath_pci 31952

1

wlan

1 [ath_pci]

45512

ath_hal 101152

1 [ath_pci]

arhontus:~#iwconfig ath0 ath0 IEEE 802.11 ESSID:"ComboNet" Mode:Managed Frequency:2.412GHz Access Point: 00:30:BD:9E:50:7C

Bit Rate:54Mb/s Tx-Power:off Sensitivity=0/242700000 Retry:off RTS thr:off Fragment thr:off Encryption key:4330-4445-3145-4537-4330-4747-45 Security mode:open Power Management:off Link Quality:0/1 Signal level:-216 dBm Noise level:-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0

For the card interface configuration use Linux Wireless Extensions, as described in the next chapter. If you require further information about the madwifi driver, consult the README file in the madwifi directory.

Tip There are many wireless card chipsets and corresponding Linux drivers that are different from the mainstream Prism, Hermes, Aironet, and Atheros. Some of these chipsets and drivers, such as Symbol24t, have been mentioned earlier. Unfortunately, we cannot cover them all, as it would require a book on its own. We also do not review the drivers' internals for the same reason, even though we consider this area to be of great interest for people interested in hacking. If you are interested in knowing more about this area, we suggest studying Jean's Tourrilhes Linux wireless drivers page, in particular http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.drivers.html#Prism2hostAP, and follow the links it provides. This provides a good insight for anyone interested in modification and development of wireless client card drivers, or people who want to know why Hermes chipset cards have three different drivers or what the difference is between the function and structure of prism2_cs and p80211 linux-wlan-ng modules for the Prism cards. Please note that we do not discuss the installation of HostAP and AirJack drivers in this chapter, as they are described in the review of man-in-the-middle attacks.

On BSD systems the installation of wireless drivers is more straightforward: You use the wi or an device drivers that come with the system. Ensure that your

kernel configuration file in /usr/src/sys/i386/conf has PCMCIA support. An example of FreeBSD configuration is as follows:

device card device pcic0 at isa? irq 0 port 0x3e0 iomem 0xd0000 device pcic1 at isa? irq 0 port 0x3e2 iomem 0xd4000 disable options WLCACHE options WLDEBUG options PCIC_RESUME_RESET

Do not forget to add pccard_enable="YES" to /etc/rc.conf. You might also need to add pccard_mem="DEFAULT" to the rc.conf configuration file and specify an unused IRQ and any additional options you like in /etc/pccard.conf. For example:

# Lucent WaveLAN/IEEE PCMCIA card card "Lucent Technologies" "WaveLAN/IEEE" config 0x1 "wi0" 10 insert echo Lucent card inserted insert /etc/pccard_ether wi0 remove echo Lucent card removed remove /sbin/ifconfig wi0 delete

In this example, "10" in the "config 0x1 "wi0" 10" string is the IRQ. In OpenBSD, the kernel configuration options to recognize PCMCIA 802.11 cards would look like this:

#PCMCIA controllers pcic*

at pci? dev? function?

# PCMCIA bus support pcmcia* at pcic? controller? socket? pcmcia* at tcic? controller? socket? wi*

at pcmcia? dev? function?

an*

at pcmcia? function?

The list of cards supported by wi in accordance with the OpenBSD manuals is given in Table 4-1. Table 4.1. Supported Wireless Cards in BSD Card

Chip

Bus

3Com AirConnect 3CRWE737A

Spectrum24

PCMCIA

3Com AirConnect 3CRWE777A

Prism-2

PCI

ACTIONTEC HWC01170

Prism-2.5

PCMCIA

Addtron AWP-100

Prism-2

PCMCIA

Agere Orinoco

Hermes

PCMCIA

Apple Airport

Hermes

macobio

Buffalo AirStation

Prism-2

PCMCIA

Buffalo AirStation

Prism-2

CF

Cabletron RoamAbout

Hermes

PCMCIA

Compaq Agency NC5004

Prism-2

PCMCIA

Contec FLEXLAN/FX-DS110-PCC

Prism-2

PCMCIA

Corega PCC-11

Prism-2

PCMCIA

Corega PCCA-11

Prism-2

PCMCIA

Corega PCCB-11

Prism-2

PCMCIA

Corega CGWLPCIA11

Prism-2

PCI

Dlink DWL520

Prism-2.5

PCI

Dlink DWL650

Prism-2.5

PCMCIA

ELSA XI300

Prism-2

PCMCIA

ELSA XI325

Prism-2.5

PCMCIA

ELSA XI325H

Prism-2.5

PCMCIA

ELSA XI800

Prism-2

CF

EMTAC A2424i

Prism-2

PCMCIA

Ericsson Wireless LAN CARD C11

Spectrum24

PCMCIA

Gemtek WL-311

Prism-2.5

PCMCIA

Hawking Technology WE110P

Prism-2.5

PCMCIA

I-O DATA WN-B11/PCM

Prism-2

PCMCIA

Intel PRO/Wireless 2011

Spectrum24

PCMCIA

Intersil Prism II

Prism-2

PCMCIA

Intersil Mini-PCI

Prism-2.5

PCI

Linksys Instant Wireless WPC11

Prism-2

PCMCIA

Linksys Instant Wireless WPC11 2.5

Prism-2.5

PCMCIA

Linksys Instant Wireless WPC11 3.0

Prism-3

PCMCIA

Lucent WaveLAN

Hermes

PCMCIA

NANOSPEED ROOT-RZ2000

Prism-2

PCMCIA

NDC/Sohoware NCP130

Prism-2

PCI

NEC CMZ-RT-WP

Prism-2

PCMCIA

Netgear MA401

Prism-2

PCMCIA

Netgear MA401RA

Prism-2.5

PCMCIA

Nokia C020 Wireless LAN

Prism-I

PCMCIA

Nokia C110/C111 Wireless LAN

Prism-2

PCMCIA

Nortel E-mobility 211818-A

Spectrum24

PCI

NTT-ME 11Mbps Wireless LAN

Prism-2

PCMCIA

Proxim Harmony

Prism-2

PCMCIA

Proxim RangeLAN-DS

Prism-2

PCMCIA

Samsung MagicLAN SWL-2000N

Prism-2

PCMCIA

Symbol Spectrum24

Spectrum24

PCMCIA

Symbol LA4123

Spectrum24

PCI

SMC 2632 EZ Connect

Prism-2

PCMCIA

TDK LAK-CD011WL

Prism-2

PCMCIA

US Robotics 2410

Prism-2

PCMCIA

US Robotics 2445

Prism-2

PCMCIA

You can also check the lists of networking equipment in Appendix B for more compatibility information. If your card is in the list of supported hardware and you have modified the BSD kernel config file as shown earlier and recompiled the kernel, everything should work. We'll emphasize this point one more time: If you want to use BSD as the primary platform for proper wireless penetration testing, you'll need a Prism chipset card, and 802.11a will remain out of reach until the appropriate drivers are developed (if ever, considering the current 802.11g spread and popularity).

Getting Used to Efficient Wireless Interface Configuration To perform efficient wireless security audits, you should familiarize yourself with using UNIX wireless configuration utilities. Yes, this means a lot of command line. However, there are significant advantages to be gained from knowing it, including understanding how more complicated wireless security tools work, being able to write useful shell scripts that save time and make your life easier, and, finally, saving a lot of battery power by not using a GUI (more on that in the following chapter).

Linux Wireless Extensions We start with Linux Wireless Extensions as the most common wireless card and interface configuration utilities used on the Linux operating system. Linux Wireless Extensions were initially developed in 1996 to work with the first Hermes chipset cards. Wireless Extensions' support of Prism cards running under wlan-ng drivers is very limited and mainly related to (often incorrect) checking the inserted card configuration parameters. However, Prism cards running under HostAP drivers are perfectly supported and configurable by Linux Wireless Extensions. Besides, 802.11a cards using vt_ark5k drivers and combo cards under Madwifi are configured using the Extensions as well. Despite the comments in the INSTALL file considering possible installation difficulties, we have never encountered any when compiling the Extensions from source, and there is nothing wrong with installing it from your favorite distribution package, unless you have some code modification ideas in mind. The most important utility in Linux Wireless Extensions is iwconfig:

arhontus:~# iwconfig --help Usage: iwconfig interface [essid {NN|on|off}] [nwid {NN|on|off}] [mode {managed|ad-hoc|...} [freq N.NNNN[k|M|G]] [channel N]

[sens N] [nick N] [rate {N|auto|fixed}] [rts {N|auto|fixed|off}] [frag {N|auto|fixed|off}] [enc {NNNN-NNNN|off}] [power {period N|timeout N}] [txpower N {mW|dBm}] [commit]

As you can see, practically any parameter of your WLAN can be configured using iwconfig. Some useful tips to keep in mind are these: Set essid as "off" or "any" when scanning for 802.11 networks/devices:

arhontus:~# iwconfig eth0 essid off

Set the nwid as "off" to have undefined domains accepted when scanning:

arhontus:~# iwconfig eth0 nwid off

Turn off the WEP key to accept unencrypted packets when scanning:

arhontus:~# iwconfig eth0 key off

Set the sensitivity threshold to the lowest value possible for your card, for example:

arhontus:~# iwconfig eth0 sens -85 (if your card sensitivity is lim

If your card supports variable transmitting power, set it to the minimum when scanning or analyzing traffic:

arhontus:~# iwconfig eth0 txpower 1

(dBm)

arhontus:~# iwconfig eth0 txpower 1mW

(mW)

Unset the nickname and chosen access point address if enabled and check that the bit rate is set on "auto." You can preserve battery power by setting power management; for example:

arhontus:~# iwconfig eth0 power timeout 300u all

("All" is needed when scanning for networks.) The command iwconfig mode master would only work with HostAP drivers and Prism chipset cards. When setting a WEP key, do not forget that if the key is given in ASCII and not hex, 's:' should be appended:

arhontus:~# iwconfig eth0 key s:idonttrustwep

In all these command examples, as well as many more to follow, we use the example eth0 interface for Hermes chipset, wlan0 for Prism and ath0 for Atheros (madwifi) chipsets, and eth0 and wifi0 for Cisco Aironet chipset cards. Don't forget to use appropriate interfaces in your practice. When iwconfig is executed without any given parameters, it displays the data about all available 802.11 interfaces taken from /proc/net/dev. The latest versions of Linux Wireless Extensions support automatic scanning for access points in range and taking the ESSID/frequency of the appropriate access point found. In our observations, the scanning might not work perfectly unless the interface is first brought up with ifconfig (e.g., ifconfig eth0 up) and, until the interface is up, iwconfig might show a freakish frequency value. If for some reason you need an easy-to-use GUI interface to iwconfig, you can use xwconfig from http://www.random-works.co.uk/xwconfig/ (Figure 4-3).

Figure 4.3. Xwconfig graphical front end to iwconfig.

Iwpriv, or the private extension, is the important companion tool to iwconfig: Whereas iwconfig deals with setting generic standard-defined parameters, iwpriv enables driver-specific configuration changes. Iwpriv is used for setting wireless roaming with some 802.11 card drivers (e.g., wavelan_cs). The main implication of iwpriv in security testing and wireless protocol debugging is setting the card into a monitor mode. For Hermes chipset cards running under the Shmoo-patched Orinoco driver, the command to put such a card into the monitor mode is as follows:

arhontus:~# iwpriv eth0 monitor

where the mode can be 1 (append Prism II headers-specific data to the frame, ARPHRD_IEEE80211_PRISM device type), 2 (monitor mode with no Prism IIspecific info, ARPHRD_IEEE80211 device type), and 0 (turn the monitor mode off). For Prism chipset cards running under HostAP drivers, this would be the corresponding command:

arhontus:~# iwpriv wlan0 monitor

where the mode value 2 is ARPHRD_IEEE80211 device type, mode value 3 is ARPHRD_IEEE80211_PRISM device type, and mode value 0 is also turning the RFMON mode off. Interestingly, the Linux Wireless Extensions version 25 and

later iwconfig can be used to set Prism cards under HostAP into the monitor mode:

arhontus:~# iwconfig wlan0 mode monitor

This might make obsolete the use of iwpriv with the latest HostAP and also Madwifi versions. You can still set the device type and dumped headers data to both possible values with this:

arhontus:~# prism2_param wlan0 monitor_type

where type 0 is IEEE 802.11 headers (ARPHRD_IEEE80211) and type 1 is Prism2 + IEEE 802.11 headers (ARPHRD_IEEE80211_PRISM). HostAP drivers come with their own 802.11 frame parser called wlansniff in the sniff subdirectory:

arhontus:~# ./wlansniff -h wlansniff [-h] [-b#] [auth] -h = help -b0 = do not show beacons -b1 = show only one line of data for each beacon -b2 = show full beacon data -auth = show only authentication frames

You need to put the card into the monitor mode (both ARPHRD_IEEE80211 and ARPHRD_IEEE80211_PRISM device types would do) before running wlansniff. Finally, when you use iwconfig to set an Atheros chipset 802.11a card into the monitor mode the command is this:

arhontus:~# iwconfig wlan0 mode monitor

After executing this command, bring up the wireless interface (ifconfig wlan0 up). A simple vt_ar5k_monitor.sh shell script to do this can be found in the vt_ar5k/misc directory. You can also enable prism2-compatible headers appending with iwpriv wlan0 prism 1 command if necessary.

802.11 Basics: Prism Headers and RFMON Mode The Prism monitor header we referred to earlier is not a part of the 802.11 frame header as defined by the IEEE standard. It is a physical layer header generated by the firmware of the receiving Prism chipset. This header includes Received Signal Strength Indication (RSSI), Signal Quality (SQ), Signal Strength and Noise (in dBm), and Data Rate (in Mbps) parameters; watching it can be helpful. The Prism header is defined by a hex value different from the standard 802.11 header in the if_arp.h file on different Unices:

/* Dummy types for non ARP hardware */ ......................................................... #define ARPHRD_IEEE80211 801 /* IEEE 802.11*/ #define ARPHRD_IEEE80211_PRISM 802 /* IEEE 802.11 + Prism2 header */

(This is an example from Linux if_arp.h.) We hope that now all references to ARPHRD_IEEE80211 and ARPHRD_IEEE80211_PRISM in the text are more understandable. As for the RF monitor (RFMON) or monitoring mode itself, it is commonly confused with the promiscuous mode on the Ethernet (as in ifconfig eth0 promisc). These are two completely different modes. Promiscuous mode on 802.3 networks is accepting all frames and it doesn't matter to whom on a LAN segment the frames are addressed by MAC. RFMON mode on 802.11 networks is passing all 802.11 frames information (usually dealt with by the client card firmware) to the end-user applications, thus allowing dumping and analysis of such frames. This is why so much attention is paid to the client card driver's ability to support RFMON and the ways of enabling the mode. Let's look at the practical example of a PCMCIA card in three possible states:

arhontus:~# ifconfig wlan0 up arhontus:~# tcpdump -i wlan0 tcpdump: WARNING: wlan0: no IPv4 address assigned tcpdump: listening on wlan0 0 packets received by filter 0 packets dropped by kernel

No traffic can be seen.

arhontus:~# ifconfig wlan0 promisc arhontus:~# tcpdump -i wlan0 tcpdump: WARNING: wlan0: no IPv4 address assigned tcpdump: listening on wlan0

0 packets received by filter 0 packets dropped by kernel

Again, no traffic can be seen, even though one of the wireless hosts is pinged from this machine. The traffic is encrypted with WEP; if it wasn't you would see the packets flying by, but you still won't see 802.11 frames. Now we put the card into the monitor mode and run tcpdump again:

arhontus:~# iwconfig wlan0 mode monitor arhontus:~# tcpdump -i wlan0 17:53:59.422074 Beacon ( ) [ 11.0 Mbit] ESS CH: b , PRIVACY 17:53:59.440055 Acknowledgment RA:0:90:4b:6:15:4f 17:53:59.442675 Acknowledgment RA:0:2:2d:8e:74:5e 17:53:59.524466 Beacon ( ) [ 11.0 Mbit] ESS CH: b , PRIVACY

Here they are! We hope this example is sufficiently convincing.

A few other utilities included with Linux Wireless Extensions are iwevent, iwgetid, iwlist, and iwspy. Iwevent reports changes of settings such as ESSID, channel, mode, WEP, and network ID, as well as joining new access points or adhoc cells, dropped transmitted packets, and the registration or unregistration of new clients if the card is run in a master mode (acts as an access point under the HostAP drivers). As such, iwevent can be useful for creating network monitoring and even intrusion detection scripts. Iwgetid is an auxiliary utility that shows current wireless network parameters such as access point (AP) MAC address, interface mode, channel, and ESSID and can be useful in scripting together with iwevent. Iwspy sets a list of host names, IPs, or MAC addresses for wireless hosts and monitors the link quality for every device on the list using /proc/net/wireless. Iwlist is another parameter-showing utility that has some very useful options including these:

arhontus:~# iwlist -h

Usage: iwlist [interface] frequency [interface] channel [interface] ap [interface] accesspoints [interface] bitrate [interface] rate [interface] encryption [interface] key [interface] power [interface] txpower [interface] retry [interface] scanning

The iwlist frequency or channel commands demonstrate a list of frequencies supported by the selected interface and currently used frequency; for example:

arhontus:~# iwlist eth1 freq eth1 14 channels in total; available frequencies: Channel 01 : 2.412 GHz Channel 02 : 2.417 GHz Channel 03 : 2.422 GHz Channel 04 : 2.427 GHz

Channel 05 : 2.432 GHz Channel 06 : 2.437 GHz Channel 07 : 2.442 GHz Channel 08 : 2.447 GHz Channel 09 : 2.452 GHz Channel 10 : 2.457 GHz Channel 11 : 2.462 GHz Channel 12 : 2.467 GHz Channel 13 : 2.472 GHz Channel 14 : 2.484 GHz Current Frequency:2.412GHz (channel 01)

Ensure that the interface you use supports all frequencies you might encounter in the country of operation.

802.11 Basics: 2.4​2.5 GHz (Medium ISM Band) Frequencies In different countries the available channels vary due to legal and licensing regulations. 802.11b channel is 22 MHz wide. The IEEE standard defines minimum space between channels as 5 MHz. Thus, the channels start from 2.412 ± 11 MHz followed by 2.417 ± 11 MHz and so forth. As you can see, the channels badly overlap (Figure 4-4).

Figure 4.4. DSSS channels 2.4Ghz spectrum.

[View full size image]

In theory, nonoverlapping channels would be 5 x 5 MHz apart, because 25 > 22 MHz. Thus, there could only be three access points in a single network coverage area. In the United States it means channels 1, 6, and 11. In the rest of the world there is the possibility to have up to 14 channels (83.5 MHz ​ 11 MHz)/5 MHz = 14.5. That would mean 2, 7, 12/3, 8, 13/4, 9, 14 and many other (1, 8, 14, etc.) combinations of three access point channels are possible. Now you know where to look for APs channel-wise and how many APs would be there, unless the system administrator does not understand the concept of radio interference and deploys multiple APs on overlapping channels.

The iwlist rate command lists the supported connection speed values and the current connection speed, iwlist key/enc shows the WEP keys available and lists their sizes (ensure proper iwlist and /etc/pcmcia/wireless.opts permissions), and iwlist txpower can help you find out if your card supports regulated transmitted power output:

arhontus:~# iwlist eth1 txpower eth1 6 available transmit-powers: 0 dBm

(1 mW)

7 dBm

(5 mW)

14 dBm

(20 mW)

15 dBm

(30 mW)

17 dBm

(50 mW)

20 dBm

(100 mW)

Current Tx-Power=20 dBm

(100 mW)

(This example is a Cisco Aironet 350 card.) The most interesting iwlist command is iwlist scan (the obsolete one is iwlist ap/accesspoint), which shows all APs and ad-hoc networks in range and even gives a variety of their settings like the signal quality. If you run HostAP in a master mode, you have to use the old iwlist ap and not iwlist scan command, although by the time this book comes out this might change. Also, iwevent has an option of showing that iwlist scan request is completed (iwlist scanning), which can come in handy in your scripting adventures. The iwlist scan option gives you an opportunity for the quick discovery of access points in range while staying connected to your AP and without putting the card into the monitor mode. We have included the fine manpages for Linux Wireless Extensions in Appendix D. Although many consider including manpages or Requests for Comments (RFCs) a waste of space, in our experience sometimes there is no substitution to printed text, and manpages make perfect bedtime reading. :)

Linux-wlan-ng Utilities There are multiple reasons you might want to use linux-wlan-ng drivers with a Prism chipset card. The configuration options are immense, RFMON mode can be set out of the box, and the majority of network discovery and security-related tools support linux-wlan-ng by default. In fact, the development of LINUX wireless security auditing tools has started exclusively on Prism chipset cards and wlan-ng drivers. The linux-wlan-ng utilities include wlancfg and wlanctl-ng. These tools are very powerful, but their syntax is somewhat awkward and lacks documentation. Nevertheless, linux-wlan-ng utilities syntax closely reflects 802.11 standard specifications and standard-defined SNMP MIBs, which makes

playing with wlancfg and wlanctl-ng very educational. If you have trouble understanding linux-wlan-ng and its utilities, you can always consult a linux-wlan maillist at http://archives.neohapsis.com/archives/dev/linux-wlan/. Compiling linux-wlan-ng is very straightforward:

arhontus:~# ./Configure -------------- Linux WLAN Configuration Script ------------The default responses are correct for most users. Build Prism2.x PCMCIA Card Services (_cs) driver? (y/n) [y]: Build Prism2 PLX9052 based PCI (_plx) adapter driver? (y/n) [n]: Build Prism2.5 native PCI (_pci) driver? (y/n) [n]: Build Prism2.5 USB (_usb) driver? (y/n) [n]: Linux source directory [/usr/src/linux]: The kernel source tree is version 2.4.20. The current kernel build date is Thu Mar 6 22:53:57 2003. Alternate target install root directory on host []: PCMCIA script directory [/etc/pcmcia]: Module install directory [/lib/modules/2.4.20]: It looks like you have a System V init file setup. Prefix for build host compiler? (rarely needed) []: Build for debugging (see doc/config.debug) (y/n) [n]: y Configuration successful. arhontus:~# make all && make install && make clean

You don't need to build the prism2_cs and p80211 modules if you already have the ones that come with your kernel. Interestingly, apart from placing wlan-ng and wlan-ng.conf files in /etc/pcmcia, linux-wlan-ng creates an additional /etc/wlan directory, which contains shared, wlan.conf and wlancfg-DEFAULT files (check them out). Some useful examples of employing wlanctl-ng include the following: Switching the card to the monitor mode:

arhontus:~# wlanctl-ng wlan0 lnxreq_wlansniff channel=6 enable=true

(You can also append prismheader=true if desired.) Associating with a network:

arhontus:~# wlanctl-ng wlan0 lnxreq_ifstate ifstate=enable

arhontus:~# wlanctl-ng wlan0 lnxreq_autojoin ssid= aut

(Note: Without executing the first command the association would not take place.) In our experience, the best way to configure Prism cards running under wlan-ng drivers is using the wlancfg show command followed by wlancfg set and inputting:

arhontus:~# wlancfg show wlan0 dot11StationID=00:02:6f:01:4c:49 dot11PowerManagementMode=active dot11DesiredSSID='' dot11DesiredBSSType=infrastructure dot11OperationalRateSet=02:04:0b:16 dot11AuthenticationAlgorithmsEnable1=true dot11AuthenticationAlgorithmsEnable2=false dot11PrivacyInvoked=false dot11WEPDefaultKeyID=0 dot11ExcludeUnencrypted=false dot11MACAddress=00:02:6f:01:4c:49 dot11RTSThreshold=2347 dot11FragmentationThreshold=2346 dot11Address1=00:00:00:00:00:00 .......................................................... dot11Address32=00:00:00:00:00:00 p2MMTx=false p2Comment='' p2LogEvents=false p2CnfPortType=1 p2CnfOwnMACAddress=00:02:6f:01:4c:49 p2CnfDesiredSSID=''

p2CnfOwnChannel=3 p2CnfOwnSSID='non-spec' p2CnfOwnATIMWindow=0 p2CnfSystemScale=1 p2CnfMaxDataLength=2312 p2CnfWDSAddress=00:00:00:00:00:00 p2CnfPMEnabled=false p2CnfPMEPS=false p2CnfMulticastReceive=true p2CnfMaxSleepDuration=100 p2CnfPMHoldoverDuration=100 p2CnfOwnName='' p2CnfWEPDefaultKeyID=0 p2CnfWEPFlags= p2CnfAuthentication=0 p2CnfTxControl=512 p2CnfRoamingMode=1 p2CnfRcvCrcError= p2CnfAltRetryCount=7 p2CnfSTAPCFInfo=1 p2CnfTIMCtrl=0 p2CnfThirty2Tally=false

p2CnfShortPreamble=long p2CnfBasicRates=0,1,2,3 p2CnfSupportedRates=0,1,2,3 p2CreateIBSS=false p2FragmentationThreshold=2346 p2RTSThreshold=2347 p2TxRateControl=0,1,2,3 p2PromiscuousMode=false p2TickTime=10

Then do wlancfg set wlan0 and cut and paste the necessary variable and its value of choice. For example, for the monitor mode do:

arhontus:~# wlancfg set wlan0 p2CnfOwnChannel=6 p2CnfOwnName='31337' p2PromiscuousMode=true Ctrl-D

Congratulations, you are monitoring channel 6 (okay, we admit that the p2CnfOwnName='31337' string is not really necessary). Finally, if you do need a GUI, there is a tiny utility called WlanFE (The Linux Wireless Front End) that might come in handy (Figure 4-5) and gpe-wlancfg GUI for handhelds.

Figure 4.5. WlanFE graphical front end to wlancfg.

However, we encourage you to use the command line for a variety of reasons, some of which are revealed later.

Cisco Aironet Configuration As stated before, the configuration of Cisco Aironet PCMCIA cards can be done by editing a text file created in /proc/driver/aironet/, for example:

arhontus:~# cat /proc/driver/aironet/eth1/Config Mode: ESS Radio: on NodeName: PowerMode: CAM DataRates: 2 4 11 22 0 0 0 0 Channel: 6 XmitPower: 100 LongRetryLimit: 16 ShortRetryLimit: 16 RTSThreshold: 2312 TXMSDULifetime: 5000 RXMSDULifetime: 10000 TXDiversity: both RXDiversity: both FragThreshold: 2312 WEP: open Modulation: cck Preamble: short

Simply open your text editor of choice (shame on you if it isn't vi or emacs!) and change the needed parameters. To put the card into the RFMON mode, change the top Mode: ESS line to Mode: yna (any) bss rfmon; this will take care of the

ESSID, too. Changing the transmission power to the minimal 1 mW value is also a good idea, so change XmitPower: 100 to XmitPower: 1. You can also echo to the configuration file from your console; for example:

arhontus:~# echo "Mode: rfmon" > /proc/driver/aironet/eth1/Config

or

arhontus:# echo "Mode: r" > /proc/driver/aironet/eth1/Config arhontus:# echo "Mode: y" > /proc/driver/aironet/eth1/Config

then

arhontus:# echo "XmitPower: 1" > /proc/driver/aironet/eth1/Config

If you run iwconfig you can see that with the Cisco Aironet cards there are two wireless interfaces instead of the usual one:

eth1 IEEE 802.11-DS ESSID:"Arhont-X" Mode:Managed Frequency:2.412GHz Access Point: 00:02:2D:4E:EA:0D Bit Rate:11Mb/s Tx-Power=0 dBm Sensitivity=0/65535

Retry limit:16 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:59/10 Signal level:-90 dBm Noise level:-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:58 Missed beacon:6

wifi0 IEEE 802.11-DS ESSID:"Arh0not-X" Mode:Managed Frequency:2.412GHz Access Point: 00:02:2D:4E:EA:0D Bit Rate:11Mb/s Tx-Power=0 dBm Sensitivity=0/65535 Retry limit:16 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:59/10 Signal level:-90 dBm Noise level:-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:58 Missed beacon:6

The wifiX interface is used to direct the captured traffic in RFMON mode, not the ethX. This is important to remember when running your sniffer. When you switch from the monitoring mode to association with the network, we recommend you restart the pcmcia-cs services. Then you will have to use iwconfig or the Ciscosupplied ACU GUI to set all necessary parameters and associate. The ACU is highly intuitive (Figure 4-6) and has excellent status and statistic reporting interfaces (Figures 4-7 and 4-8). As such, it can be used as a good site surveying tool.

Figure 4.6. ACU graphical interface to Cisco cards.

[View full size image]

Figure 4.7. ACU graphical interface to Cisco cards.

Figure 4.8. ACU graphical interface to Cisco cards.

Configuring Wireless Client Cards on BSD Systems The configuration utilities that remain to be covered are ifconfig, wicontrol, and ancontrol on BSD operational systems. The manual pages for these utilities are included in Appendix D and there is not a lot we can add to them. Of course, you are interested in setting your card into a monitor mode. If you have a Prism chipset card, you cannot put it into the monitor mode with ifconfig (FreeBSD) or wicontrol. Instead use the prism2ctl tool from BSD-airtools:

arhontus:~# prism2ctl wi0 -m

If the card is Cisco Aironet and you use FreeBSD 5.0 or later, an supports the monitor mode with the -M switch:

arhontus:~# ancontrol -i -M 0-15

Set monitor mode via bit mask, meaning: 0 to not dump 802.11 packet. 1 to enable 802.11 monitor. 2 to monitor any SSID. 4 to not skip beacons, monitor beacons produces a high system load. 8 to enable full Aironet header returned via BPF. Note: it appears that an SSID must be set. It is worth mentioning that with older versions of Ethereal, bit mask 8 might be necessary. This is an example of setting a Cisco Aironet card into the monitor mode:

arhontus:~# ancontrol -i wi0 -M 1 -p 1

where -p 1 sets the transmitting power to 1 mW (battery life preservation). If you are very conservative and use older BSD versions, you'll have to apply the an.rfmon patch (see http://www.ambrisko.com/doug/an/old/) to implement the M switch.

Summary Before firing rockets and engaging the enemy, it is necessary to learn how to take off and efficiently fly the plane. Before conducting wireless security audits or site surveys, ensure that the chosen hardware is fully recognized and runs smoothly under your system of choice. Familiarize yourself with all command-line options that pertain to your wireless setup; this time clicking through the buttons won't do the job. Knowing your command-line wireless configuration utilities increases audit efficiency and allows you to write useful shell scripts, saving your time and automating your tests. Besides, such knowledge fosters a better understanding of the wireless security auditing tools presented in the next chapter.

Chapter 5. Learning to WarDrive: Network Mapping and Site Surveying "It will not do for the army to act without knowing the opponent's condition, and to know the opponent's condition is impossible without espionage." ​Du Mu After all the necessary hardware is acquired and set and you are familiar with the drivers, configuration, files and utilities, it is time to get some fresh air and survey your wireless network or map the WLANs in a neighborhood. Warwalking is good for your health and does not involve mindless stepping or weightlifting in a gym far away from the soothing green-on-black console. As long as you don't abuse the found networks' resources and don't eavesdrop on bypassing data traffic, wardriving or warwalking is not illegal. Learn the local law pertaining to recreational wireless activities to stay on the safe side and avoid legal trouble. Site surveying is very different from casual wardriving or warwalking. A surveyor concentrates on a specified network and studies it in great detail, mapping the SNR around the whole coverage area. We also suggest pinging the access point or wireless gateway and logging packet loss and delay as you move. Wardriving or warwalking doesn't have to be an activity that demands specifically devoted time and effort; it can be casual. By casual wardriving we mean "looking around" when using hotspots, carrying your PDA set to map networks (and, in the attacker's case, dump the traffic) on the way to a meeting with a client, and so on. There are also means of network discovery without deassociating from the WLAN you are using. By the end of the chapter you will become familiar with the tools necessary to implement these means. How you survey the wireless site or wardrive is a question of requirements, circ*mstances, and your personal preferences. Unlike planning a proper penetration test as outlined in Chapter 7, we cannot walk you through a wardriving procedure because there isn't one. Instead, we are going to take the "teach a man to fish instead of giving him bread every day" approach and concentrate on the available wireless network mapping and signal monitoring tools, explaining how they work and how to use them. Network discovery tools are the most abundant; the majority of them are free. Some of these tools are more than just network mapping software, and support advanced features such as WEP decryption on the fly or wireless IDS signature database. In general, all you need to detect wireless networks or hosts and log wireless traffic is to put a client card into the RFMON mode and run tcpdump on the appropriate interface. The rest of the features are often a power-consuming

luxury, helping users to visualize the discovered networks and decode traffic. Of course, reading tcpdump output might not be very intuitive, but it helps a lot in understanding 802.11 protocols and networking events. Nothing is a substitute for tcpdump / Ethereal (if you need a GUI) traffic analysis in gaining 802.11 networking experience. Another common luxury that can actually come in handy is a specific RF signal strength or other network parameters monitored by a network discovery tool (as watch -n1 "date >>/home/survey-wlan0 ;cat /proc/net/wireless |grep wlan0 >> /home/survey-wlan0"will do the job anyway). There are three ways of discovering wireless networks: active scanning, monitor mode sniffing, and searching for access points and ad-hoc cells with the iwlist scanning command, which is a form of active scanning anyway.

Active Scanning in Wireless Network Discovery Active network discovery is implemented by Netstumbler and Mini-Stumbler, Windows tools most frequently used by casual wardrivers around the world. In fact, many mistakenly equate the terms wardriving and netstumbling (which is incorrect) and recommend Netstumbler for use by IT security professionals. As we show, this is not a good recommendation to follow. Active scanning refers to sending a probe request frame and waiting for probe responses to come back. The received probe response frames are dissected to show the network ESSID, channel, the presence of WEP, signal strength, and supported bitrate. Netstumbler is close source software and there was no official information about its internal workings available at the time of writing. However, H1kari from the Dachb0den Labs has investigated how Netstumbler does its scanning and implemented the same technique in dstumbler from the BSD-airtools suite. Netstumbler appears to rely on a proprietary feature of the also proprietary hcf library provided by Lucent for Windows Hermes chipset card drivers, and apparently closed source wavelan_cs driver for Linux. Netstumbler sends a scan request to the client card, which is done by sending an inquiry command 0x11 to the card with 0xF101 as the parameter. This command instructs the card to send out probe requests and store data about hosts that respond. This method is handled asynchronously: When the 802.11 card has results, it sends an information event message "0x0080" to the interrupt handler in the driver. This is the same handler that takes care of other buffer reads such as receive or transmit. Information events are sent in a standard ltv structure made by length, code, and a data buffer, so a reverse engineer would look for ltvs with the 0xF101 code. These ltvs should have an array of structures that contain AP information resembling this:

struct wi_scan_res { u_int16_t

wi_chan;

/* dss channel */

u_int16_t

wi_noise;

/* average noise in the air */

u_int16_t

wi_signal;

/* signal strength */

u_int16_t

wi_bssid[6];

/* mac address of the ap */

u_int16_t

wi_interval;

/* beacon transmit interval */

u_int16_t

wi_capinfo;

/* capability information (bits: 0-ess, 1-bss

u_int16_t

wi_ssid_len;

/* ssid length */

u_int16_t

wi_ssid[32];

/* ssid (ap name) */

};

On the basis of this scheme, H1kari has concluded how a Netstumbler-like application can be written and proposed a cleaner implementation of such technique using Prism chipset cards: 1. A scan request rid (0xFCE1) is sent to the card:

struct wi_p2_scan_req { u_int16_t

wi_chans;

/* channels to scan (bits: 0-chan 1, 1-chan

u_int16_t

wi_rates;

/* rate to send the probe requests at (bi

2-5.5mbit, 3-11mbit) */ };

2. In half a second the card would be ready for the results query, readable from the scan result rid (0xFD88). The result buffer would be different because it would contain the Prism header info (ARPHRD_IEEE80211_PRISM). The frame would look like this:

struct wi_scan_res_hdr {

u_int16_t

wi_rsvd;

/* reserved for something in the future (i t

u_int16_t

wi_reason;

/* reason for the response (0 - error, 1 -

from the host) */ };

This is followed by an array of response frames similar to those of the Hermes / Lucent chipset cards:

struct wi_scan_res { u_int16_t

wi_chan;

/* dss channel */

u_int16_t

wi_noise;

/* average noise in the air */

u_int16_t

wi_signal;

/* signal strength */

u_int16_t

wi_bssid[6];

/* mac address of the ap */

u_int16_t

wi_interval;

/* beacon transmit interval */

u_int16_t

wi_capinfo;

/* capability information (bits: 0-ess, 1-i

u_int16_t

wi_ssid_len;

/* ssid length */

u_int16_t

wi_ssid[32];

/* ssid (ap name) */

[wep]) */

u_int8_t

wi_srates[10];

/*

list of rates the ap supports, null ter

need to get rid of the last bit (& 0x7F) and divide by 2) */ u_int8_t

wi_rate;

/* rate that the probe response was recieve

0x14 - 2mbit, 0x37 - 5.5mbit, 0x6e - 11mbit) */ u_int8_t

wi_rsvd;

/* extra padding so it fits nicely into a 1

};

H1kari has successfully implemented this methodology into dstumbler, even though dstumbler also supports RFMON mode sniffing. In addition, despite common confidence in Netstumbler being able to work with Lucent / Hermes chipset cards only, the latest version of Netstumbler works fine with Prism chipset cards, too. We verified this using a Netgear 802.11b PCMCIA card. Perhaps H1kari's research was taken into account by the Netstumbler developers. Although sending a probe response frame on receiving the probe request is a normal access point behavior as described by the 802.11 standard, it is by no means necessary in terms of practical implementation. So-called closed networks would not respond to probe request frames. Besides, in some cases frames bearing ESSIDs known to be used by the Netstumbler and similar tools can be dropped or filtered out by a knowledgeable system administrator. Thus, not all networks would be properly discovered by the Netstumbler and Co. This is made worse by the fact that for a network to be discovered by the Netstumbler, it should first be reached by the probe request frame sent by the tool. This means you can only detect networks in the transmit range of your card, which is limited if compared to the range of a powerful access point linked to a high-gain antenna (did we forget to mention an amplifier?). A wardriver with Netstumbler can stay in the middle of the Fresnel zone of a long-range point-to-point link and yet not see it; the bridges are too far. Therefore, the higher the EIRP you have, the more networks you can discover with active scanning. The downsides of this are obvious: You become easy to discover yourself (detection of Netstumbler users is discussed in Chapter 15 in detail). You waste precious battery power and limit the time you can spend scanning. In addition, don't forget that active scanning has nothing to do with sniffing and people calling Netstumbler a "wireless sniffer" should consider a serious review of wireless networking basics. Netstumbler or other similar tools do not log any wireless traffic, apart from the probe response frames, so they cannot be used for proper wireless traffic analysis and troubleshooting. It also means that using Netstumbler should be legal anywhere, because no traffic eavesdropping takes

place and anyone can transmit in the ISM band as long as the FCC power limits are not exceeded. For the reasons we have outlined, although convenient, easy to use, and wellinterfaced with common GPS receivers, Netstumbler should not be the tool of choice for professionals or anyone who is serious about proper penetration testing and troubleshooting of wireless networks. Also, advanced Black Hats are unlikely to use any active scanning tool for 802.11 network discovery; they appreciate the value of stealth, distance, and time (battery power). Of course, Netstumbler will and should remain a wardriving tool of choice for wireless amateurs not interested in discovering every single network in the area or providing professional wireless site surveying and security services. This is reinforced by the fact that Windows tools supporting the monitor mode and wireless protocols analysis are commercial and have a hefty price tag attached, whereas Netstumbler is free.

Monitor Mode Network Discovery and Traffic Analysis Tools The most common and useful group of wireless network discovery and traffic analysis tools use the RFMON mode combined with hopping through all DSSS channels. This lets you discover wireless hosts via detecting and analyzing passing traffic including all kinds of control and management frames. Your client card receiving sensitivity (dBm) becomes the only limiting factor in network discovery and it can be greatly alleviated by the use of high-gain antennas and bidirectional amplifiers. The next part of the chapter is devoted to the description of wireless sniffers that we have found to be useful while doing penetration testing while working for Arhont Ltd. Both fully blown advanced tools and simple shell scripts are outlined. Although simpler tools and scripts might not be as exciting, they have their niche in both wireless penetration testing and network troubleshooting. They are easy to incorporate into your custom scripts, consume minimal resources, and are educational, in particular for novice wireless security tools developers.

Kismet Kismet (http://www.kismetwireless.com) was our workhorse for years and is a universal 802.11 sniffer that went a long way from a wardriving tool to a fullblown wireless protocol analyzer and an IDS suite. The IDS features of Kismet are reviewed in Chapter 15; for now we'll concentrate on the network discovery and traffic dumping features of Kismet. Kismet is easy to install and configure on any UNIX-like operating system; however you can also use it in Windows running Cygwin. To do this, you should compile Kismet with:

arhontus:~# ./configure --disable-pcap --without-ethereal --disable-gps

--disable-netlink --disable-suid-root --enable-wsp100 && make && make

Pay attention to the --enable-wsp100 string in the configure command. The problem with running Kismet and any other noncommercial wireless sniffer that

uses RFMON mode in Windows is that publicly available Win32 drivers just don't support the mode and cannot be reverse engineered and rewritten without breaking the law. A way around the problem is to buy the RFGrabber from http://www.wildpackets.com/ (formerly the WSP100 Remote 802.11b Sensor of http://www.networkchemistry.com/) or the Neutrino Distributed 802.11b Sensor from http://www.networkchemistry.com/. These hardware sensors are easy to integrate with Kismet; simply put source=wsp100,"host":"port",wsp100 into the kismet.conf file. Kismet_monitor script has wsp100 configuration part:

"wsp100") echo "Enabling a wsp100 at $DEVICE for channel $CHANNEL" if test "$HOSTIP" == ""; then HOSTIP=`hostname -i`

echo "'hostname -i' thinks our IP is $HOSTIP. Set HOSTIP manually if th echo "

ie, HOSTIP=1.2.3.4 kismet_monitor"

fi WSPDEVICE=`echo $DEVICE | cut -f 1 -d:`; WSPPORT=`echo $DEVICE | cut -f 2 -d:`; # sensor::loghostaddress snmpset -c public $WSPDEVICE .1.3.6.1.4.1.14422.1.1.5 a $HOSTIP # sensor::channel snmpset -c public $WSPDEVICE .1.3.6.1.4.1.14422.1.3.1 i $CHANNEL # sensor::serverport snmpset -c public $WSPDEVICE .1.3.6.1.4.1.14422.1.4.1 i $WSPPORT # sensor::running snmpset -c public $WSPDEVICE .1.3.6.1.4.1.14422.1.1.4 i 1

;;

This would configure the sensor via SNMPv1, including setting the device IP, channel to sniff, and User Datagram Protocol (UDP) port set in kismet.conf to pass the sniffed wireless traffic. Channel hopping has to be set on the sensor manually or using kismet_hopper -s -v & if needed. The "public" community is used with the snmpset command and SNMPv1 itself has known insecurities (e.g., lack of authentication). Thus, the sensor is very vulnerable to attacks from the wired LAN side. Changing the SNMP community on the sensor is a very good idea. Don't forget to modify the kismet_monitor script appropriately after changing the community string. Overall, deploying such sensors together with Kismet might provide a good distributed network monitoring and intrusion detection solution, while keeping the Windows administrator in the Microsoft world. However, such a solution is not scalable for remote penetration testing and is a bit on the expensive side. As in many other cases, it is cheaper and easier to use Linux/BSD. We have never had any problems compiling Kismet on these systems and you can always install it from your distribution packages, although we recommend grabbing the latest sources of Kismet from the CVS and compiling them yourself. Kismet's configure script is rich in options, including --enable-wsp100 to enable WSP100 remote sensor support in the configuration files and --enable-zaurus to enable piezzo buzzer on a Sharp Zaurus PDA when a network is found. If you want to cross-compile Kismet for Zaurus use this:

arhontus:~# ./configure --host=arm-linux --disable-pcap --enable-zaurus --disable-setuid && make

For the iPAQ Familiar distribution employ this:

arhontus:~# ac_cv_linux_vers=

./configure --host=arm-linux --with-pcap=linux --disable-setuid && make

The only true dependency you need for compiling Kismet is Ethereal's wiretap and we assume that you already have the latest version installed. Ethereal is great for studying Kismet dump files. In addition, Kismet can use the Ethereal wiretap library for dumping and processing these files. If you plan to use a GPS device, you'll need to install GpsDrive (http://www.kraftvoll.at/software/), which includes the GpsDrive daemon that Kismet interfaces with. Finally, if you want to impress your clients, employers, or peers with a cool talking Kismet, you can install Festival speech generator supported by Kismet. Appropriate synthesized speech packages will have to be installed for Festival to work. After the compilation (use "gmake" and not "make" if on BSD), take a good look at /usr/local/etc/kismet.conf. You will need to do the following: Disable the MAC filter. Set an unprivileged user to run Kismet if you don't want to use your casual unprivileged user. Allow 127.0.0.1 to connect. Set maxclient=1 (unless you deploy Kismet as an IDS server for connecting many clients). Set the source for your sniffed packets (e.g., source=cisco,eth1,cisco). Enable GPS (gps=true) if needed. Adjust the write interval (seconds; use 0 if you don't dump any data). Adjust your sound using play and Festival, set metric=true unless you use obsolete distance measurement systems. Set GPS waypoints.

Check the file types for dumped or logged data (default settings are fine for us). Set noiselog and beaconlog to false (you'll still log the first beacon and will save a lot of hard disk space by not logging the rest of the beacons from the same access point). Most likely you should leave the rest of the settings as they are. Now bring up the interface you want to sniff on using ifconfig (recommended), run kismet_monitor as root, then run kismet_hopper (unless you use a Cisco Aironet card), log in as a user you set for Kismet to run, and run Kismet, perhaps giving it an interface to sniff on with a -c flag, (e.g.,

arhontus:~# kismet -c cisco,wifi0,cisco note: in the later kernels you should use arhontus:~# kismet -c cisco_wifix,eth1:wifi0,cisco_wifix).

This example is not accidental, because if you set cisco,wifi0,cisco in kismet.conf, you'll get an obvious error:

arhontus:~# kismet_monitor Using /usr/local/etc/kismet.conf sources... Enabling monitor mode for a cisco card on wifi0:

/usr/local/bin/kismet_monitor: line 136: /proc/driver/aironet/wifi0/Con or directory

/usr/local/bin/kismet_monitor: line 137: /proc/driver/aironet/wifi0/Con

or directory

/usr/local/bin/kismet_monitor: line 138: /proc/driver/aironet/wifi0/Con or directory

However, if eth1 is set in the configuration file and wifi0 is supplied with the -c switch, you should see the familiar green panel interface on your console and enjoy the wireless traffic (if there is any). Cisco Aironet drivers that come with newer Linux kernels or from the Airo-Linux Sourceforge project CVS will require a different Kismet switch. Check out the kismet.conf file that comes with your version of the tool for an appropriate command syntax. A vast variety of wireless drivers, newer madwifi and Prism54 included, are well-supported by Kismet. The amount of options available in Kismet is astonishing (use "h" for help). The most interesting options are probably these: i - Detailed information about selected network l - Show wireless card power levels d - Dump printable strings r - Packet rate graph a - Statistics p - Dump packet type Figure 5-1 shows Kismet running with the dump packet type option turned on.

Figure 5.1. Kismet ncurses utility.

[View full size image]

Familiarize yourself with the Kismet interface. It has a variety of useful information messages including warning about the factory default access point configuration (F, colored red), probe requests from lost or misconfigured clients (P, Netstumbler probe requests are flagged as N, not P), and discovering dataonly networks without any management traffic (D, usually non-802.11-compliant microwave links operating in ISM/UNII bands such as Orinoco Lynx T1/E1 or Mmwaves SDH/SONET radios). When supplied with a correct WEP key in hex (see kismet.conf), Kismet can decrypt the packets on the fly. As the IP addresses of participating networks are discovered, Kismet reports which protocol was employed to discover the IP (Address Resolution Protocol [ARP], Transmission Control Protocol [TCP], User Datagram Protocol [UDP], Dynamic Host Configuration Protocol [DHCP]). The format in which Kismet dumps log files is very convenient for analysis: The packets are stored in a pcap file format (hint: use Ethereal to open them) and the listing of found networks is stored in ASCII, .cvs, and .xml formats. GPS waypoints and information on Cisco devices running Cisco Discovery Protocol (CDP) is also stored in separate ASCII files. The format of networks reported by Kismet is as follows:

Network 1: "TheMatrixHasYou" BSSID: "00:02:2D:8E:74:5E" Type

: infrastructure

Carrier

: 802.11b

Info

: "None"

Channel

: 11

WEP

: "Yes"

Maxrate

: 11.0

LLC

: 6262

Data

: 1303

Crypt

: 1303

Weak

: 0

Total

: 7565

First

: "Tue May 20 16:42:37 2003"

Last

: "Tue May 20 16:58:41 2003"

If you want to produce a nice .html output file of Kismet logs for your Web page, Kismet Log Viewer (KLV; http://www.mindflip.org/klv/) is useful. KLV takes Kismet .xml log files and outputs a structured formatted HTML interface to browse the logs with. It also enables Snort users to generate a page of Snort output for each specific ESSID that has logged data. Besides, KLV comes with the Kismet Log Combiner script to help users merge together multiple .xml and .dump log files. The absence of a default GUI is a great advantage in Kismet, as you don't have to run X, which saves time and battery power. There is actually a GUI for Kismet called Wirekismet, which has been developed for handhelds and runs on laptops if needed. Wirekismet has extended functionality, including putting the client card into the RFMON and Infrastructure modes, connecting to the discovered networks, turning on a DHCP client, choosing a Kismet server to connect to from the list, and so on. Another excellent GUI for Kismet, which also acts as a server​client configuration tool, is kismet_qte for Trolltech's QT environment (http://sourceforge.net/projects/kismet-qte/; Figure 5-3). Finally, for the laptop environment, Gkismet (http://gkismet.sourceforge.net/) is probably the best GUI available; see Figure 5-2 and also check out the screen shots at the Sourceforge site.

Figure 5.3. Kismet_qte front end to kismet on Trolltech's QT environment.

Figure 5.2. Gkismet, a graphical interface to Kismet.

[View full size image]

Because PDAs have a good battery life compared to laptops and notebooks, using a GUI for Kismet on a handheld is a power-affordable method and provides a good way to demonstrate to "nongeeks" (e.g., management) the peculiarities and insecurities of wireless networking.

Kismet and GpsDrive Integration Sometimes it is nice to revisit an access point that was found during a wardriving tour. However, in a busy city you might find hundreds of access points within a short period of time. How do we find a particular one from the whole list of access points recorded during the trip? For this task it is best to use a GPS device connected to a laptop to track the exact position when the access point is spotted. It is also advisable to implement a tool that will place the locations of wireless networks on the map. GpsDrive can be tweaked to do this without much effort. Gpsmap, a tool packaged with Kismet, is another excellent utility that we find very useful to graphically represent a Kismet wardriving session or client site survey. The setup of Kismet, GpsDrive, and Gpsmap is detailed in this section.

For our wardriving explorations we use a Haicom GPS Receiver HI-204E, a quite efficient, yet very inconspicuous magnetically mounted GPS device that can be bought at http://www.cheeplinux.co.uk. To make it work, simply place the device on the car roof, connect it to a USB port in your laptop, modprobe pl2303 module, run gpsd -K -p /dev/ttyUSB0 or other relevant device name, and finally run Kismet. Kismet records the positions of found wireless networks in a file named something like Kismet-XXX.gps. The first task is done: We can record the latitude and longitude positions of the networks so that they can be easily revisited at will. What if we want to plot WLAN coordinates on the map? Let's use two well-known open source tools called GpsDrive and Gpsmap. Gpsmap uses Kismet-generated GPS output to download the map of the area from the Internet and plot access point positions on the map. This tool is highly flexible and can also generate an interpolated network power, estimated network range, and many other useful features that will brighten up your map, as shown in Figure 5-4.

Figure 5.4. Gpsmap-generated output.

[View full size image]

GpsDrive is yet another useful utility for GPS navigation that a war-driver can use. For simplicity reasons, we only describe Kismet-related features of GpsDrive. If you want to learn more about this tool, visit its project page at http://gpsdrive.kraftvoll.at, where you can find a lot of information about Linux and GPS setups. To integrate GpsDrive and Kismet you need a MYSQL server containing database table entries ready for the output from GpsDrive. Before launching GpsDrive, make sure the following procedures have been done: Install MySQL server. Add database and GpsDrive user. Edit GpsDrive configuration file, usually found in ~/.gpsdrive/gpsdriverc, to represent mysql settings. First launch gpsd, then Kismet, and finally GpsDrive. If all goes well, you should see a small Kismet logo in the bottom left corner of the screen. If you have difficulties with these procedures, consult the README.SQL and README.kismet files, located in the source directory of the GpsDrive tool. The GpsDrive and Kismet integration should look like Figure 5-5.

Figure 5.5. GpsDrive integration with Kismet.

[View full size image]

Once you get comfortable with these tools, you can easily revisit any of the found networks by following previous wardriving tracks and simply setting the required network as the destination point in the GpsDrive or any other GPS navigation system.

Wellenreiter If you want a very easy-to-use graphical wireless sniffer, look no further. Sparing the obvious pcmcia-cs, libpcap, and tcpdump, you'll need to install Gtk-Perl (http://www.gtkperl.org/download.html) and the Net-Pcap Perl module (http://earch.cpan.org/search?mode=module&query=net%3A%3Apcap) to run Wellenreiter (http://www.wellenreiter.net/). Then you simply launch the tool with the perl Wellenreiter.pl command. No configuration is required for Prism (wlan-ng driver), HostAP, Cisco Aironet (Sourceforge airo-linux driver), or Hermes chipset (orinoco_cs driver) cards. Scanning with Wellenreiter is straightforward and you can toggle traffic and log windows to watch flying packets and happening events in real time (Figure 5-6).

Figure 5.6. Wellenreiter utility.

[View full size image]

Additionally, you can configure the event sounds. Wellenreiter dumps logged data into the running user home directory in the form of two files: a tcpdump file ending in .dump and an ASCII network parameters list file ending in .save.

Airtraf Airtraf is an intuitive wireless network discovery and traffic and bandwidth consumption statistics monitoring tool for console users. It is easy to install: Check that you have libncurses library installed, untar the tool, and do the usual make all && make install. Then run airtraf -l to see if airtraf recognizes your wireless interfaces:

arhontus:~# airtraf -l You have (2) wireless devices configured in your system Found eth1: IEEE 802.11-DS on IRQ: 3, BaseAddr: 0x0100 Status: UP

Using Driver: (airo_cs) Filename:/lib/modules/2.4.20/kernel/drivers/net/wireless/airo_cs.o Author: "Benjamin Reed" success: above driver's compatibility verified! Found wifi0: IEEE 802.11-DS on IRQ: 3, BaseAddr: 0x0100 Status: UP Using Driver: (airo_cs) Filename:/lib/modules/2.4.20/kernel/drivers/net/wireless/airo_cs.o Author: "Benjamin Reed" success: above driver's compatibility verified!

Then use these parameters to run airtraf, or just launch the tool to answer a question about the RFMON mode and it will run. Airtraf supports Prism, Cisco Aironet, and Hermes chipset cards. If you use a Cisco Aironet card you'll have to set the interface manually, because by default airtraf would set the interface to ethX and not wifiX:

arhontus:~# airtraf -I wifi0 -C aironet

Otherwise you can simply launch airtraf and it will put your card into the RFMON mode when you tell it to. In case you want to put the card into the monitor mode without knowing the proper commands to do so, use kismet_monitor script or airtraf itself (simple monitor and unmonitor shell scripts are included in airtraf/src/scripts). Airtraf has a feature-rich menu (Figure 5-7) that lets users scan for access points in the area (Scan Channels for AP activity option), then press Esc to enter the main menu, focus on the selected access point, and monitor its activity.

Figure 5.7. Airtraf wireless network discovery tool.

[View full size image]

Two unique airtraf menus are General Protocols Statistics (Figure 5-8) and TCP Performance Statistics. The General Protocols Statistics interface breaks down the wireless bandwidth usage by various protocols, whereas TCP Performance Statistics shows TCP connections for the chosen host on a WLAN as well as all wireless hosts available and the amount of retransmitted packets, bytes, and wasted bandwidth on the network.

Figure 5.8. Airtraf General Protocols Statistics menu.

[View full size image]

You can run airtraf in a daemon mode. Obviously, you can dump the traffic statistics into a file, but this file can be viewed by airtraf only. You can easily replay the traffic when viewing the statistics dump. The main disadvantage of airtraf is that you cannot enter the WEP key and decrypt or monitor wireless traffic in real time. This is the reason you cannot see any higher layer traffic on the provided screen shots.

Gtkskan Gtkskan (http://sourceforge.net/projects/wavelan-tools/) is a simple WLAN scanner for Hermes chipset cards running a Shmoo-patched orinoco_cs driver. In our experience it can also work with Prism cards and linux-wlan-ng; just set an appropriate interface (e.g., wlan0). Gtkskan is easy and straightforward to use (Figure 5-9) and supports NMEA GPS devices.

Figure 5.9. Gtkskan.

[View full size image]

You need berkeley db (http://www.sleepycat.com) to compile and run gtkskan. It should be version 1.85, otherwise run ./configure 2.x/3.x with the --enablecompat185 flag. Gtkskan does not support Cisco Aironet cards but can be modified to do so.

Airfart The tool creators said, "Following suit with the major players in the wireless arena, we decided the 'air' prefix best categorizes airfart. Further, re-arrange the letters in 'traf' and you can get 'fart.' So, our mission is to sniff out wireless devices who broadcast a 'scent'." Airfart is another GTK+ front-end tool for WLAN discovery written in C/C++. Airfart supports Prism chipset cards run with linuxwlan-ng only. Its distinguishing feature is using the Prism headers that we have discussed (ARPHRD_IEEE80211_PRISM) to monitor signal strength on the discovered 802.11 LANs. For cards with the newer Prism3 chipset, linux-wlan-ng drivers do not present the signal strength values correctly. If you have such a card (e.g., Linksys WPC11 v3.0), then the signal strengths will be smaller in the Airfart display than they really are. Multiply the Airfart values by about 2.5 to get the real signal strength. Figure 5-10 demonstrates Airfart in action.

Figure 5.10. Airfart tool.

[View full size image]

Here and in some other cases we took an example screen shot from the tool's Web site (http://airfart.sourceforge.net/ in Airfart's case) because our screen shot would be rather boring. Only three 802.11b networks in the testing lab, and one of them (with the closed ESSID) was not detected by the Airfart.

Mognet If you like Java then you will like Mognet, as it is a compact wireless sniffer written purely in Java with handhelds in mind. To install Mognet (http://www.node99.org/projects/mognet/) you need a Java Development Kit (JDK), which is necessary to compile the jpcap library that comes with it. You can get the latest version of JDK from http://www.sun.com or http://www.blackdown.org. Check that JAVA_HOME in the install.sh script points correctly to your Java directory. After jpcap is compiled, you can run Mognet with either JDK or Java Runtime Environment (JRE): java Mognet . Alternatively, you can run Mognet in the console to dump wireless traffic:

arhontus:~# java ConsoleCapture wlan0 opening device wlan0 wrote frame 82

The frames are dumped into a pcap format log file (mognet-.log file) in the Mognet directory. Unlike Wellenreiter, Mognet does not put your wireless

interface into the monitor mode automatically; you have to do it manually before launching the tool. On the other hand, all common 802.11 client cards chipsets are supported. Figure 5-11 shows Mognet at work.

Figure 5.11. Mognet in action.

Its features include real-time capture output; support for all 802.11 generic and frame-specific headers; raw hex, and ASCII views for any frame; and loading and saving capture sessions in the libpcap format. Thus, on a PDA without an installed Ethereal, Mognet can be priceless. Please note that Sharp Zaurus has a JeodeRuntime Java environment installed by default, thus making installation and use of Mognet on these PDAs an easier task. Known issues with using Mognet include confusing IPP broadcasts with 802.11b frames, although it is actually an older libpcap versions bug. In our experience, Mognet might confuse ESSID-less beacon frames on a closed network with association request frames.

WifiScanner WifiScanner is a console tool to find 802.11 LANs (using Prism chipset cards running under linux-wlan-ng) and dump wireless traffic while creating lists of discovered access points or ad-hoc cells:

arhontus:~# ./WifiScanner -h

WifiScanner v0.8.0 (Wlan driver version >= 0.14) (c) 2002 Herv? Schaue ([emailprotected]) Call with no parameters or with the following options -F FileName

- Save output to a file as well as stdout

-H Hop

- Number of hops do for rotating channel

-S Channel

- Only listen on a specific Channel (1-14)

-V

- Write Version and quit

-W FileName

- Save sniffed data to a file in PCAP format

-D FileName

- Create a file of detected devices, in a .dot format

-d

- Write date in human readable format

-i number

- Number of the interface wlan0 = 0 (default 0)

-M number

- Max packets to capture before exit (0 = unlimited)

-N abcd

- Do not display Ack, Beacon, Control, Data

-v level

- For verbose, level 2 is debugging

(default 1)

A sample WifiScanner screenshot is shown in Figure 5-12. Please note that the tool can also show the strength of the received signal, presumably via reading the Prism headers (check out the source code).

Figure 5.12. WifiScanner console tool.

[View full size image]

The data on a screenshot is read in the following way:

Column 1 : Time since 1 January 1970 (or readable date if -d option is Column 2 : ESSID Column 3 : Channel. When is 0, it means that it's unknown Column 4 : STA or AP : Client Station or Access Point Column 5 : Strength of Signal Column 6 : Strength of noise (if it known) Column 7 : Packet Destination Address (FF:FF:FF:FF:FF:FF is broadcast) Column 8 : Packet Source Address Column 9 : BSSID Column 10: Data Rate (1, 2, 5.5 or 11Mbit/s) Column 11: Type of client Client : it's a client (in usual management or control data) AP Base: it's an AP AP Base (STA in master mode) : It's a card in Master mode AP Base (dedicated)

: It's a dedicated AP

Ad-Hoc STA STA Activity

: It's an Ad-Hoc client : It's a client emitting some Data

Column 12: Type of radio transmission Radio only Data To DS Data From DS Data AP to AP

To compile WifiScanner from source you will need some object code from linuxwlan-ng, so compile your Prism drivers and utilities without execution of the make clean command. You will also need a source code of Ethereal and a manual compilation of Ethereal wtap library. Of course, ncurses are needed, too. If you don't want to compile WifiScanner or your compilation fails, precompiled binaries are available from the http://sourceforge.net/projects/wifiscanner/ site. To run WifiScanner, a wide (minimum of 132 columns and 50 rows) terminal is needed; maximized xterm did the job for us.

Miscellaneous Command​Line Scripts and Utilities By the time the major wireless discovery and protocol analysis tools, such as Kismet or Wellenreiter, came to the market, a great variety of simpler command line tools for wardriving already existed and were widely used. The majority of these tools are custom hacks by enthusiastic individuals aimed at discovering wireless networks using the client cards at hand. A group of such tools was based on a Prismdump, a utility to dump 802.11 frames to a pcap format file. Such tools included Prismsnort, which was a combination of Prismdump with an early version of the Airsnort, and Prismstumbler, which has been described as Prismdump on steroids with added GPS (via gpsd) support and a GTK GUI. These tools are no longer supported and rely on the historic PF_NETLINK interface. At the same time, all modern 802.11 protocol analyzers have switched to using the PF_PACKET interface and the current libpcap library supports the 802.11 frame format just fine. Thus, Prismdump-based tools are on

the obsolete side. Nevertheless, we have included them in the book for historical and educational (in terms of software development) reasons. You might have difficulties compiling Prismdump-based tools against the wtap library included with the current version of Ethereal. Wtap is used by Prismdump to dump its log files:

dump_file = wtap_dump_fdopen (fileno(stdout), WTAP_FILE_PCAP, WTAP_ENCAP_IEEE_802_11, 2344, &wtap_error);

/* Now we can save the frame to the capture file */

wtap_dump (dump_file, &packet_hdr_info, NULL, &msgbuf[oi], & wtap_error

Please note that if you use Prismdump with your linux-wlan-ng driver and libpcap supports PF_PACKET, the tool will enter an infinite loop that you can't stop with Ctrl+C (but kill -9 helps). Both PF_NETLINK and PF_PACKET are kernel interfaces that provide means for passing data via sockets from the kernel space to user space. PF_PACKET supplies additional means for packets to be passed to end-user programs, such as the wireless protocol analyzers we discussed. This interface is used by the libpcap library and all tools that rely on it. Since the transition to PF_PACKET, tcpdump (and Ethereal) can be used to capture live 802.11 traffic in real time. We don't review tcpdump and Ethereal in this chapter, as they are not specifically designed as wireless sniffers. However, you should always keep these tools in mind and get good hands-on practice using them in wireless protocol analysis. The powerful features of Ethereal (Figure 5-13) make the analysis of 802.11 traffic, for those familiar with the protocols, an easy and entertaining task.

Figure 5.13. Ethereal network protocol analyzer.

[View full size image]

You can filter the beacon frames, replay TCP sessions that took place over the wireless link, sort the packets by protocols or timestamps, and so on. Please note that the beacon frame shown in the screenshot of Ethereal is reported as a "malformed packet." In fact, there is nothing wrong with that beacon, but the Ethereal decoding engine is confused by a lack of ESSID in it (closed network). Several examples of using Ethereal to flag out interesting 802.11 traffic are given in Chapter 15. Apart from the Prismdump-based tools we have described, a variety of useful scripts and utilities exist and deserve mentioning. They work with the current libpcap library and can often utilize non-Prism chipset cards. For example, Ssidsniff (http://www.bastard.net/~kos/wifi/) allows access point discovery with Prism or Cisco Aironet chipset cards and traffic logging in a pcap format traffic:

arhontus:~# ./ssidsniff -h ./ssidsniff: invalid option -- h Usage: ./ssidsniff -i Set the device to listen on

-s pcap maximum snarfed length -f pcap filter to use -c Set maximum packets to read, then exit -m Set mode of operation: live: Use live network device and capture beacons. Use to get current list. Default. file: Open libpcap file and run through it; print all beacons. acquire: Use live network device and dump out all beacons received in machine parseable format. -g Geiger counter mode. Beep for every packet received. -w tcpdump capture file for everything received -W

When capturing to file, only save 802.3 portion

-r tcpdump capture file to read packets from -l Text file to keep findings. - is stdout. -L

When capturing to text file, use machine parseable format

-v The higher, the noisier -V version number

arhontus:~# ./ssidsniff -i wlan0 -g -v 2 ./ssidsniff: datalink type 113 isn't 802.11 (105), continuing anyway ./ssidsniff: geiger mode on: EsounD sound module ./ssidsniff: Starting sniffing with filter= on wlan0 6 total, 3 beacons, 2 plaintext, 0 wep, 1 martians

The "martians" in the output refers to unknown format frames (e.g., frames corrupted by RF noise) and not green men bearing head-mounted, low-gain omnidirectional antennas. The geiger mode lets you sense when more frames are passing using your ears and might be helpful in trying to find out where the source of these frames could be. Another utility to sniff a channel in the RFMON mode, using Prism II chipset cards only, is Scanchan from http://www.elixar.net/wireless/download/download.html. Scanchan is used by airtraf, which we have already described. For an easy-to-use command-line utility for Hermes chipset cards, try Wavestumbler:

arhontus:~# ./wavestumbler --help WaveStumbler v1.2.0 by Patrik Karlsson --------------------------------------------------------usage: ./wavestumbler [options] -i*

-d*

(should be greater than 100)

-r

-m

reduce shown information to minimum

-v

be verbose (show debug info)

Wavestumbler, by default, tries to write into the /proc/hermes/eth1/cmds file and you might need to modify the tool if the corresponding file is not there (find /proc/ -name*hermes* helps). Another scanning utility for Hermes chipset cards is wlan-scan, which unfortunately comes as a precompiled binary:

arhontus:~# ./scan -h Usage: ./scan [||] arhontus:~# ./scan 2 ESSID

AgentSmith

Link

52/92 (56%)

Speed

2Mb

My HW

00:90:4B:06:15:4F ()

AP HW

00:02:2D:4E:EA:0D

()

Apart from the scan utility, wlan-scan also has a file with an OUI-to-manufacturer list and arpq parsing utility that might come in handy:

arhontus:~# ./arpq 00:00:39:BA:33:86 00:00:39:ba:33:86=Intel

Yet another utility and collection of scripts for command-line wardriving utilizing a Hermes chipset card is called Wardrive that comes from van Hauser of the The Hackers Choice (http://www.thehackerschoice.com). Wardrive was one of the very first wardriving tools to support GPS devices and sound signals on network discovery. Edit the wardrive.conf file and the shell scripts included to suit your system settings (wireless interface, GPS serial port, etc.). The sniff_wvlan.sh script runs tcpdump and Dug Song's Dsniff on the selected wireless interface:

#!/bin/sh

test -z "$DEV" && DEV="$DEVICE" test -z "$DEV" && DEV=eth0 dsniff=dsniff.$$.sniff tcpd=tcpdump.$$.sniff dsniff -i $DEV -n -m -s 2500 > $dsniff & tcpdump -l -i $DEV -n -s 2500 -w $tcpd ip or arp &

Ensure that you have these tools installed and they can be found in the $PATH. The syntax of the Wardrive utility itself can be confusing:

arhontus:~# ./wardrive --help Wardrive v2.1 by van Hauser / THC Syntax: ./wardrive [-p serport] [-d interface] [-o file] [-I script] [-i interval] [-l level] [-b level] [-B interval] [-G] [-v] Options: -d interface

wavelan interface. [eth0]

-p serport

seriell port the GPS device (NMEA) is connected to. [/d

-o file

output file to append the data to. [./wardrive.stat]

-I script

script to run initially to configure the wvlan card []

-R script

script to reset wvlan card after node was found [reset_

-W

print access point hwaddr and SSID via "iwconfig" [fals

-i interval

interval to write GPS+wavelan data in seconds, 0 =

-l level

only save data with >= this link level, 0 = all. [1]

-b level

beep if >= this link level, 0 = disable. [5]

-B interval

wait time in seconds before beeping again. [5]

-G

ignore errors from GPS, dont exit. [false]

-v

be verbose. [false]

ama

However, running the scan via start_wardrive is easy once everything is configured:

arhontus:~# ./start_wardrive eth1

enable roaming

Wardrive: GPS could not be configured, disabled support and still runni

Starting logging, saving to ./wardrive.stat; press Control-C to end log 2003-05-21 20:09:12 00:00:00.0000? 00:00:00.0000? 0 0 188 134 0 4635 0 tcpdump: WARNING: eth1: no IPv4 address assigned tcpdump: listening on eth1 dsniff: listening on eth1

2003-05-21 20:09:13 00:00:00.0000? 00:00:00.0000? 0 56 214 114 0 4638 0 2003-05-21 20:09:13 00:00:00.0000? 00:00:00.0000? WINFO - SSID:"foobar 00:02:2D:4E:EA:0D

2003-05-21 20:09:14 00:00:00.0000? 00:00:00.0000? 0 58 212 112 0 4643 0

2003-05-21 20:09:15 00:00:00.0000? 00:00:00.0000? 0 58 210 112 0 4647 0

2003-05-21 20:09:16 00:00:00.0000? 00:00:00.0000? 0 60 213 111 0 4651 0

2003-05-21 20:09:17 00:00:00.0000? 00:00:00.0000? 0 64 215 111 0 4655 0

2003-05-21 20:09:18 00:00:00.0000? 00:00:00.0000? 0 62 213 110 0 4659 0

Finally, for all you Perl lovers wanting to use (and perhaps dissect) something simpler than Wellenreiter, there is Perlskan. Perlskan uses the GPS::Garmin module (included with the tool) for interfacing with the GPS device. Thus, the GPS receiver will have to send data in GRMN/GRMN and not NMEA unless the NMEA support is implemented in the GPS::Garmin module by the time this book is released. Perlskan was written for Hermes chipset cards and is easy to compile and use:

arhontus:~# perl perlskan Usage: perlskan arhontus:~# perl perlskan eth1 eth1: 31337++ link

= 0

freq

= 2422000000

bitrate = 2000000

In the current example, Perlskan could not find our closed ESSID 802.11g LAN, which is depressing. If a Cisco Aironet card is used instead of the Hermes chipset, Perlskan still finds the access points, but shows them all as running on channel 1. This is probably because of the Aironet card's default channel 1 setting, even though the card hops automatically between channels.

BSD Tools for Wireless Network Discovery and Traffic Logging Although Linux is our workhorse in wireless security auditing, it is important to mention several wireless security testing tools for various BSD flavors. These tools are not numerous, but they are nevertheless powerful and quite important in the overall picture of wireless security. The story of BSD wireless tool development probably began from this little Perl script:

#!/usr/bin/perl -w # #resets wi0 every second. #first second we check for non-encrypted network, #next second for encrypted network, and so on use strict;

$|=1;

my $wicomm

= '/sbin/wicontrol';

my $resetcomm

= '/sbin/wicontrol -p1 -e0';

my $resetcomme

= '/sbin/wicontrol -p1 -e1';

my $n

= 0;

while (1) { print time(), "\t";

open(WICO, "$wicomm|") or die "$wicomm Error: $!"; while () { chomp;

print $1,"\t" if /^Current netname \(SSID\):\s+\[(.*)\]$/ print $1,"\t" if /^Current BSSID:\s+\[(.*)\]$/; print $1,"\t" if /^Comms.*\[(.*)\]$/; } close (WICO); print $n%2? "Y"

: "N";

print "\n";

if ($n%2) { system($resetcomm); } else { system($resetcomme); } sleep 1; $n++; }

This script was used by Francisco Luis Roque while warwalking and biking around Ann Arbor, Michigan, with a 486 laptop running OpenBSD and a Lucent Orinoco wireless card. The script does not put the wi0 interface into the monitor mode. Over time, a few simple BSD wireless scanning tools such as airosniff and wicontrol have surfaced and disappeared. Currently, Dachb0den Labs BSDairtools is the main and the most well-known wireless security auditing suite for BSD systems. Dstumbler is the main network discovery tool included in the suite; we mentioned it previously when we discussed the Netstumbler's internal workings. When run in the RFMON mode, Dstumbler provides the following unique capabilities:

Detects if an infrastructure network uses shared or keyed authentication Detects if bss nodes are set to connect to any network or a specified one Partial detection of 40-bit or 104-bit WEP encryption These features alone make Dstumbler a very valuable addition to any wireless penetration testing tools collection. Dstumbler will also report default ESSIDs, estimate beacon interval of detected access points, show hosts on infrastructure networks, and record the maximum supported bitrate on both APs and hosts. You'll need to install BSD-airtools source-mods and recompile the BSD kernel to be able to set Prism chipset cards into the RFMON mode, unless you run OpenBSD 3.2 or later OpenBSD versions in which the monitoring mode for wi and an interfaces is supported by default. After the kernel recompilation, installing Dstumbler is easy, but remember that you'll need to run it as root. Launching Dstumbler in monitor mode is also straightforward:

arhontus:~# dstumbler wi0 -o -l allyourbase.txt

Two other relevant tools included in the BSD-airtools suite are prism2ctl and prism2dump. Prism2ctl is really an interface to the prism2 debug kernel modules provided in the BSD-airtools source-mods package. It allows you to set a Prism2 chipset card into any of the 14 various debug modes. The monitor mode is one of them. For your reference, these modes are as follows:

-r: reset device -i: initialize device -s: put device into sleep mode or wake it up arguments:

0 - wake 1 - sleep -f: switch device to specified frequency channel arguments: channel number (1-14)

-d: this mode suppresses "post back-off delays" with transmitted frames better throughput -t: this mode makes the device suppress any errors with transmitted frames -m: enable monitor mode -l: enable led test arguments: :x - blinks the power led at a rate of x usec on and x usec off 2:x - blinks the activity led at a rate of x usec on and x usec off -c: continuously transmits the supplied 16-bit parameter arguments: 16-bit hex pattern -h: disables the following modes: delay suppression transmit error suppression monitor mode continuous transmit continuous receive

set signal state -e: puts the device into a continuous receive state

-g: sets the signal mask for the device (don't use this unless you know and have proper documentation) -a: issues a calenable to the baseband processor -b: enables or disables automatic level control on transmit frames arguments: 0 - disable 1 - enable

To set a wi0 interface into the RFMON mode, just run prism2ctl wi0 -m. Prism2dump is a tcpdump or its Linux cousin Prismdump-like utility for logging 802.11 traffic. To do it properly, first put your Prism2 card into monitor mode and then run prism2dump -v . The levels of verbosity supported include the following:

0: only prints the 802.11 frame information 1: prints the 802.11 frame info as well as basic data/mgmt/control protocol info 2: prints all protocol information

You also need to run prism2dump as root.

Apart from the BSD-airtools, an interesting tool that deserves mentioning is wistumbler, originally written for NetBSD wireless network discovery. To compile wistumbler you will need gtk+-1.2.10 and glib-1.2.10nb1 or later. Wistumbler supports both wi and legacy (PrismI) awi interfaces and can communicate with NMEA-supporting GPS receivers. You can run wistumbler with a command like this:

arhontus:~# wistumbler wi0 -f wehaveyouall -g /dev/dty01 -d

where "wehaveyouall" is a logfile, /dev/dty01 is the GPS serial port, and the -d flag sets the debugging mode.

Tools That Use the iwlist scan Command It would seem strange if such tools did not exist, and indeed in this section we cover two of them. The main advantage provided by these tools is the possibility to discover access points in the area without disconnecting from the network you are already associated with. The first tool is a Perl script called aphunter.pl. Aphunter reformats output of the iwlist scan command for doing a wireless site survey using a curses interface and can also support RFMON mode if needed. It is quite an advanced script that supports automatic association to the discovered network if that is what you need. If such association takes place, aphunter can get the WEP key from a defined file (wireless.opts by default if /etc/pcmcia is present, otherwise from $HOME/.aphunter-keys) and tries to obtain the IP address via DHCP. The default aphunter dhcpcd command is /sbin/dhcpcd -n -d -N -Y -t 999999, but you can supply your own parameters with the -d switch. Aphunter can autoassociate with the first available network (-c switch) and if there are several of them, the one with the best signal strength will have selection priority. A network is considered to be available if its access point can be detected and it does not use an unknown WEP key. You can set how often the networks are scanned (-T switch) and for how long lost access points should be displayed (-k switch). And, of course, Aphunter automatically recognizes whether or not the wireless interface supports the iwlist scan function. If you need to generate a report batch about your site survey, use the /bin/sh c "aphunter 2> report.aph" command (C shell), and if you want a compact 802.11 monitor try something like xterm -geometry 40x10 -e aphunter &. There are also keyboard hotkeys for interacting with the script when running it. Do perldoc -t ./aphunter to read the full documentation for the tool (you'll need perldoc installed) or simply browse to the end of the script to see it. We tried aphunter.pl -v with a Cisco Aironet 350 card; see Figure 5-14.

Figure 5.14. Aphunter.pl.

Alas, the real channels are 3 and 11, not 4 and 12​we don't live in a perfect world. Please note the hex hash in place of an ESSID of our closed testing network. Don't rush to your hex-to-ASCII conversion table, though. That hex value has nothing to do with the real cloaked ESSID and probably comes from the infamous /dev/urandom device. Apradar is a tool very similar to aphunter, but it goes further by providing a GUI, listing available access points, and connecting to WLANs with known WEP under Linux with a single mouse click. Launching Apradar from the terminal shows in the background its underlying function events:

AP Scan requested. going into select loop eth1

Scan completed : NEW AP from accesspoint scan ESSID:"Arh0nt-X" Mode:Managed 2 Frequency:2.427GHz Encryption key:

ccode module returning AP list of size 1 #0 BSSID 0:2:2D:4E:EA:D ESSID 0x80904d0 mode: 2 wep: 1

Syncing old APList size 2 addr:0x8084b58 with new AP list size 1 addr:0 oldit aplist->begin() Already have AP bssid: 0:2:2D:4E:EA:D New AP bssid: 0:2:2D:4E:EA:D SyncAPs finish. aplist->size() 2 getting IP for eth1 getting IP for eth1 failed. pinging 127.0.0.1 127.0.0.1 ping send error == Timer started AP Scan ==

This output is self-explanatory but the same frequency detecting error, as with aphunter, takes place and we have not yet found the reasons behind this error. If you manage to figure out the problem, please get in touch with us at [emailprotected].

RF Signal Strength Monitoring Tools These tools are not sniffers or graphical network mappers that show all wireless networks in sight, but because they do discover WLANs (at least at the level of RF signal being present), we briefly review them in this section. Although a wardriver might not be interested in measuring the signal strength or SNR, for wireless site surveying this task is essential and having a tool to automate this task can save a lot of time. These utilities implement two basic methods to monitor signal and noise strength on the 802.11 channel: watch -n1 -d 'cat ' and parsing an appropriate directory in /proc (e.g., /proc/net/wireless) or greping ARPHRD_IEEE80211_PRISM frame headers when using Prism chipset cards. Please note that the latter method appears to be used by both Airfart and WifiScanner and many higher-end tools such as Kismet that also report signal strength on the sniffed channels. As already mentioned, the main use of signal strength monitoring tools is site surveying, the importance of which can never be underestimated in a wireless security audit and proper wireless network design and deployment. Although signal strength detecting tools can indicate the presence of RF interference or jamming (high level of noise and low SNR where in accordance with your RF calculations the SNR or signal strength must be much higher), they are by no means a substitute for a proper RF frequency analyzer.

The RF Basics: Free Space Path Loss and Interference Free space path loss is the biggest cause of energy loss on a wireless network. It happens due to the radio wave front broadening and transmitted signal dispersion. Free space path loss is calculated as 36.56 + 20Log10(Frequency in GHz) + 20Log10(Distance in miles). Online calculators mentioned previously include free space path loss estimators and there are also applications that can do the same locally. Of course, free space path loss presumes free space​any obstacle would significantly attenuate the RF signal. A simple glass window would decrease the strength of ISM band signal by approximately 2 dBm. Any (unlucky) wardriver without an external antenna who tries to open the car window while wardriving can spot the difference. An approximate table of obstacle-caused signal loss for ISM band signal is included in Appendix E. If you subtract the free space path loss and estimated obstacle-related loss from your EIRP you should get the approximate signal strength in the area of measurement. If the signal is much weaker than estimated, check your EIRP with the same signal strength monitoring tool by placing it very close to the antenna. If the EIRP appears to be in the range of your estimated value, look out for the interference caused by obstacles (multipath) or any RF transmitting devices. The multipath problem refers to the interference caused by an RF signal from the same transmitter being reflected from the obstacles along its path. Because of that, it arrives to the receiver end at the different times. Traditional ways of alleviating the multipath problem are antenna diversity and proper antenna positioning to avoid obstacles. The interfering transmitters can include other 802.11, 802.15, and non-802-compliant wireless networks; 2.4-GHz cordless phones; baby monitors; wireless surveillance cameras; microwave ovens; and jammers intentionally deployed by attackers. It is ironic that the 802.11b/g channel 6 (2.437 ± 0.011 GHz) used as a default by many access points, badly overlaps with one of the most common interference sources, microwave ovens. A microwave oven's magnetron emits at 2.445 ± 0.01 GHz in theory, but has a rather wide microwave irradiation pattern in practice. However, we do not recommend frying your frequency counter in the microwave oven to find the answer. On the other hand, the 801.11a UNII band is relatively free from interference as compared to the ISM frequency range. An older method of avoiding interference on 802.11 networks was switching from 802.11 DSSS to 802.11 FHSS; now try switching to 802.11a if your local regulations permit using the UNII band frequencies.

RF signal monitoring tools come as separate utilities or plug-ins for various window managers. Our favorite signal strength monitoring tool is wavemon (see Figure 5-15), which has a nice signal strength level histogram (F2), lists all discovered access points (F3), and is relatively configurable (F7).

Figure 5.15. Wavemon wireless signal monitoring utility.

By default it supports Prism cards and linux-wlan-ng, but that is simply because of the preset wlanX interface; change the interface on ethX and so on to make it work with other chipset card drivers. Another useful tool is wlanmeter, which can monitor signal, noise, and link levels on all available wireless interfaces (three interfaces at the same time). Yet another useful tool is Wireless Power Meter for Linux (wpm), which uses Linux Wireless Extensions and will run on any terminal capable of displaying ANSI color (the Linux console, ETerm, Gnome Term, XTerm, Color RXVT). Alternatively, there is xnetworkstrength (surprisingly, it uses X), Cisco ACU for Aironet cards (recommended), and a variety of wireless link monitoring applets such as wmwave for Windowmaker or gwireless_applet for Gnome and the famous wireless plug-in for gkrellm. Wireless Network Meter for QT on Embeddix makes a good addition to Kismet + kismet-qte on your Sharp Zaurus, enhancing the use of this brilliant handheld as a wireless site survey tool. On the Windows side we recommend AirMagnet (not to be confused with the Java Mognet 802.11b/g sniffer) on an iPAQ. AirMagnet software is bound to the card that comes as part of the AirMagnet package; this card has proprietary firmware modifications that allow AirMagnet to detect and graphically display 802.11b/g channel overlapping. AirMagnet is a great (although somewhat expensive) allaround wireless security evaluation tool that is "fluffy" and easy-to-use. Of course, both AiroPeek and NAI Sniffer Wireless can also monitor network signal strength, among other features presented by these powerful commercial tools. For site surveying tasks, you can get PDA versions of both sniffers written for the Windows CE platform.

Summary Wardriving can be done just for fun. Nevertheless, for some it can be the gates to the world of wireless networking and security and a jumpstart for a new career. When taken seriously, wardriving builds up skills necessary for a professional wireless site survey. Learning to discover and map wireless networks is essential to running a professional wireless security audit that includes surveying the site, discovering rogue wireless devices, and determining the best physical positions that potential attackers can take up. It is also necessary to physically trace real attackers using triangulation methods. In a nutshell, before thinking of wireless cryptanalysis, man-in-the-middle attacks, traffic injection, and other advanced wireless penetration techniques, learn to wardrive first. In this chapter we have presented a whole arsenal of network discovery and mapping tools for all your wardriving and site surveying needs. Try them out, read their source code, and modify them to make your tasks easier and more automated. Whereas a casual wardriver can get away with using a single tool, wireless hacking assumes a broad knowledge and constant search for alternative approaches, techniques, and software.

Chapter 6. Assembling the Arsenal: Tools of the Trade "In regard to the warrior knight, that path involves constructing all sorts of weapons and understanding the various properties of weapons. This is imperative for warriors; failure to master weaponry and comprehend the specific advantages of each weapon would seem to indicate a lack of cultivation in a member of a warrior house." ​Miyamoto Musashi It is time to move from wardriving and harmless wireless exploration to assembling a formidable arsenal of tools for proper professional penetration testing on 802.11 networks. Just as with hardware selection, a structured and logical approach to the choice of wireless security-related tools is essential. Again, as in the hardware and drivers case, we are surprised that no classification of such tools exists. Here we offer a brief classification of 802.11 attack and manipulation software based on its function and follow with a detailed description of specific tools. All wireless penetration testing-specific tools can be split into several broad categories: 1. Encryption cracking tools 2. 802.11 frame-generating tools 3. Encrypted traffic injection tools 4. Access points management software Although the last category isn't strictly security related, such tools can come in handy when trying to reconfigure the remote access point via Simple Network Management Protocol (SNMP) and guessing its access credentials. You don't need to use or have all the tools described in this chapter; just pick up those that suit your specific aims, taking into consideration the hardware at your disposal. Many tools support only a specific 802.11 client card chipset, some have to be heavily modified to run on handhelds, and some are easy-to-tweak scripts that can be educational and help you write useful programs for your own tasks. Practically all tools we review are open source; thus a developer can learn a lot about the way they function and, perhaps, get help in his or her personal advancement or initiating his or her own project.

Encryption Cracking Tools By definition, this section is devoted to tools created to break 802.11-specific Layer 2 cryptographic protection. This is by no means limited to cracking WEP. The spread of 802.11i-related wireless security solutions has brought other, different challenges to the hacking community and right now there are tools "in the wild" designed to attack 802.1x authentication. Although these attacks are currently limited to cracking Cisco EAP-LEAP​based authentication systems, there is no doubt that attacks against other EAP types will eventually surface. The most basic form of 802.1x authentication is based on a weak EAP-MD5 method, which can be attacked without using any specific cracking tools. We review such attacks in the next chapter. At the moment, there are no tools designed to attack more secure replacements for WEP, namely TKIP and CCMP. Nevertheless, there are hints that successful attacks against TKIP preshared key (PSK) authentication are possible (see Chapter 8). Even with the "ultrasecure" AES-based CCMP there is always a possibility of dictionary and brute force attacks and the potential for development of cracking tools to launch these attacks. As always, humans ("wetware") remain the weakest link. As to the "good old" practical WEP cracking, now it goes much further than Wepcrack and AirSnort. There are means to accelerate cracking WEP and make even the most idle wireless networks give away their precious WEP keys. The tools, capable of smashing WEP into pieces rather than waiting for enough data to passively crack the key, have existed for quite a while; however, we have yet to see a literature source describing them in detail (apart from the one you are holding in your hands, of course). Currently, there are four classes of wireless encryption cracking tools: WEP crackers Tools to retrieve WEP keys stored on the client hosts Traffic injection tools accelerating WEP cracking and making network reckon without knowing WEP key possible Tools to attack 802.1x authentication systems Within each class there are different methodologies and approaches, dictating several tools per class in the majority of cases. In the description of these classes, we walk through the properties of each tool to build the knowledge base necessary for constructing the logical framework of penetration test and attack that we outline in Chapters 7 and 8.

WEP Crackers For a variety of reasons we outlined in Chapter 1, WEP is with us to stay, no matter how good and secure the replacements for WEP are. Just to refresh your memory, a few of these reasons are as follows: WEP is easy to set up and any 802.11-compliant system supports it. Legacy hardware might not support new security protocols and companies might not want to throw it away after investing millions in acquiring it and setting it up. Newer hardware will fall back to the security level of legacy hardware to interoperate. Many users and system administrators are security-ignorant or just plain lazy and won't upgrade their firmware and drivers to support more secure replacements for WEP. There is more effort and cost involved in setting up newer wireless security systems, forcing users to upgrade and invest in personnel training. Some companies might opt against it for financial or administration reasons. Implementing the final 802.11i/WPAv2 CCMP will require a complete hardware upgrade that won't be considered reasonable by many. There is still a circulating opinion that WEP is sufficiently secure for small office and home office networks. Unfortunately, there are "security professionals" unfamiliar with the reality who still support this opinion. For these reasons, attacks against WEP are not obsolete even if WEP is; the tools to run these attacks should be reviewed with a great attention.

AirSnort The most commonly used WEP cracking tool is AirSnort from the Shmoo group (http://airsnort.shmoo.com; see Figure 6-1).

Figure 6.1. Shmoo group AirSnort in action.

[View full size image]

AirSnort has a very intuitive GTK+ interface and is straightforward to use for both network discovery and WEP cracking. It supports both Prism and Hermes chipset cards with the applied Shmoo patch. AirSnort can dump the logged data in a pcap file format, as well as open and crack pcap-format files collected using other tools like Kismet. This opens a variety of interesting possibilities linked to WEP cracking; for instance, packet collection using a PDA followed by cracking the WEP key on the auditor's desktop that lacks wireless interfaces. Alternatively, you might try to port AirSnort to StrongArm CPU and embedded Linux distributions. The majority of CF 802.11b cards are Prism-based, which should be a great help to anyone trying to port AirSnort to Intimate, OpenZaurus, Familiar, or Embeddix.

Wepcrack Although AirSnort is the most popular WEP cracking tool that uses the Fluhrer, Mantin, and Shamir (FMS) attack against WEP, Wepcrack was the first tool to implement the theoretical attack described by these famous cryptologists in practice. Wepcrack is a collection of Perl scripts that includes WEPcrack.pl, WeakIVGen.pl, prism-getIV.pl, and prism-decode.pl. Prism-getIV.pl takes a pcap-format file as an input (e.g., perl prism-getIV.pl ) and collects packets with initialization vectors (IVs; see Chapter 11) that match the pattern known to weaken WEP keys. It also dumps the first byte of the encrypted output and places it and the weak IVs in a log file called IVFile.log. IVFile.log is used as an input to crack WEP with WEPcrack.pl. Real-time WEP cracking a la AirSnort using Wepcrack is straightforward:

arhontus:~# tcpdump -i wlan0 -w - | perl prism-getIV.pl

Then edit your crontab (crontab -e) to run perl WEPcrack.pl command at the chosen interval (e.g., every three minutes). To be analyzed by prism-getIV and WEPcrack scripts, the dumped file should be generated using a libpcap library that understands 802.11 frame format. This is not a problem for current versions of libpcap (get it from http://www.tcpdump.org/#current). Although AirSnort is considered to be a more advanced WEP cracking tool than the Wepcrack scripts, there are several advantages to using Wepcrack: It is educational. If you want to know how the FMS attack works, reading the code of Wepcrack scripts is probably the best way to learn about it. In fact, WeakIVGen.pl is included as a proof-of-concept tool that generates a weak IVs file from a given decimal-format WEP key value. Thus, by reading its code you can learn how the weak IVs come about. Also, the prism-decode.pl script demonstrates how pcap() format dump files can be decoded to display the 802.11 header information, which could be useful for anyone developing a 802.11 sniffer in Perl or otherwise (also see Perlskan.pl). You can run Wepcrack scripts without X-server and GUIs (similar to the older AirSnort 0.9 version). This has multiple advantages, including preserving CPU cycles, battery power, and endless scripting possibilities. It is flexible and enables you to implement possible improvements to the FMS attack and integrate with other wireless security auditing tools, such as Kismet and Wellenreiter. You don't care about the card chipset as long as you can put it into the RFMON mode (think of WEP cracking on 802.11a networks, WEP cracking using HostAP drivers, etc.). You can run Wepcrack on PDAs as long as Perl is installed. At the same time, no port of AirSnort to Intimate, Familiar, or Embeddix running on StrongArm CPU architecture machines exists at the moment. Thus, the very first publicly available WEP cracking tool remains very useful and cannot be dismissed by a serious wireless security auditor or enthusiast.

Dweputils

A part of the BSD-airtools suite, Dweputils consist of dwepdump, dwepcrack, and dwepkeygen. Dweputils employ an improved FMS attack as outlined in the H1kari's "Practical Exploitation of RC4 Weaknesses in WEP Environments" article at http://www.dachb0den.com/projects/bsd-airtools/wepexp.txt. Because this chapter is devoted to utilities and not the description of attack methodology, we return to this article and other details of improved WEP attacks in the appropriate section of Chapter 8. Dwepdump is a prism2dump-like pcap-format file dump utility, specifically written to provide data for dwepcrack and non-FMS brute-forcing attacks against WEP. Current specific features of dwepdump include: Logging only weak keys for use with the dwepcrack -w option. Ongoing statistics showing how many weak IVs have already been found (n.x -> n:x when x >= 60 you can attempt cracking). Ability to specify the maximum packet size, so you only capture small packets. This makes cracking via key space brute-forcing faster. You do not need to specify an interface, so that multiple pcap files can be filtered together into a single one. This is useful if you have a lot of standard pcap files dumped with tcpdump, and so on, and want to filter out the weak IVs or converge weak IV dumps for cracking. Use of advanced IV filtering methods beyond the standard FMS attack for faster capture time. Thus, when cracking WEP with dwepcrack, using dwepdump for data collection is preferable to using prism2dump or any other pcap-format file-dumping tools such as tcpdump or Ethereal. Dwepcrack is a WEP cracking utility created for all kinds of known attacks to determine a WEP key. It implements several techniques in a single package, which lets you run a full test of WEP key security using all currently available methodologies for WEP cracking. In particular, dwepcrack supports the following: The optimizations of FMS attack described in the "Practical Exploitation of RC4 Weaknesses in WEP Environments" article An ability to crack WEP using both FMS and brute-force attacks An ability to brute-force the entire key space and use dictionary lists

Optimized method of 40-bit keys brute-forcing Symmetric multiprocessing support with the -j option Please note that in the modular dwepcrack source code weakksa.c an improved FMS attack implementation and brute.c WEP brute-forcing implementation are separate. This makes the analysis of the attacks and possible additional modifications easier. Dwepcrack is straightforward to run:

arhontus:~# dwepcrack -h usage: -j -b -e -w -f -s [wordfile] -j: number of processes to run (useful for smp systems) -b: brute force key by exhausting all probable possibilities -e: search the entire key width (will take a while) -w: use weak ksa attack (= modified FMS attack - Authors)

-f: fudge the probability scope by specified count (might take a whi -s: file uses 104-bit wep

For the last option, use dwepstumbler to try and determine WEP key size or you can just assume it is 104-bit; the majority of modern WEP keys are.

Wep_tools Wep_tools is Mike Newsham's original toolkit for WEP keyspace brute-forcing and dictionary attacks. It is particularly efficient against the original standard 40-bit WEP keys, because it implements a specific attack on a common 40-bit WEP-frompassphrase generation routine. When cracking 128-bit WEP keys with Wep_tools, you are limited to the dictionary attack in practical terms. Wep_tools are straightforward to compile and run on Linux machines:

arhontus:~# ./wep_crack Usage:

./wep_crack [-b] [-s] [-k num] packfile [wordfile]

-b

Bruteforce the key generator

-s

Crack strong keys

-k num

Crack only one of the subkeys without using a key generator

Wordfile must be specified when -b is not used. "Packfile" refers to a pcap-format file, wordfile is a Dictionary.txt file, and the "strong keys" option refers to 128(104)-bit WEP (there were times when people considered it to be strong). Please note that you select between the brute-force and dictionary attacks and can't run both simultaneously (with a single wep_crack process anyway). Once the key is obtained, use wep_decrypt utility to decipher the pcap-format traffic dumps:

arhontus:~# ./wep_decrypt usage:

./wep_decrypt [-g keystr] [-k hexkeystr] [-s] [infile [outfile]

-g keystr

String to derive keys from

-k hexkeystr

Hex keys, separated by spaces or colons

-s

Use stronger 128-bit keys

A key must be specified with -g or -k.

By default, wep_decrypt reads from stdin and outputs to stdout. The key to decrypt the file can be specified as a string of hex characters, optionally separated by spaces or colons, or as an ASCII string. If an ASCII string is used, the actual keying material will be generated using the string in the weak fashion (used by older drivers), which creates easy-to-crack 40-bit WEP keys. Because many vendors now mitigate this vulnerability, we do not recommend using an ASCII format key with wep_decrypt.

802.11 Basics: WEP Key Length If you are not familiar with 802.11 networking you might be confused by our mention of 40-bit, 64-bit, 104-bit, and 128-bit WEP keys. Officially the keys are defined as 64-bit and 128-bit and this is the length you are likely to encounter in your vendor manuals for obvious marketing reasons. In reality, the first 24 bits are the IV, and IVs are transmitted in cleartext. Thus, the real shared secret is 40 and 104 bits. In this book the length values mentioned are interchangeable. Please note that the same principle would apply to proprietary WEP implementations with a larger key length. Always check how much of this key space is actually given to the IV (the more, the better).

WepAttack WepAttack is an open source tool similar to Wep_tools, but with significant improvements. Just like Wep_tools, WepAttack uses brute-forcing or dictionary attacks to find the right key from the encrypted data pcap dump file. However, the project page states that only a single captured WEP-encrypted data packet is required to start an attack. The WepAttack project page is located at Sourceforge (http://sourceforge.net/projects/wepattack/). The full documentation of WepAttack operation theory is available in German from the project page. WepAttack is very simple to install and use. It requires Zlib and LibPcap libraries that can be found at http://www.gzip.org/zlib/and http://www.tcpdump.org, respectively. After installing the libraries and downloading wepattack sources, you should simply change to src directory and run make. To run the brute-force attack on a Kismet-XXX.dump file using a dictionary file located in /usr/share/dict/british-english-large use the following command:

arhontus:~$./wepattack -f Kismet-XXX.dump -w /usr/share/dict/british-en

The output should look similar to this:

Extraction of necessary data was successful!

Founded BSSID: 1)

00 30 BD 9E 50 7C / Key 0

1 network loaded... Accepting wordlist data... ++++++++++ Packet decrypted! ++++++++++ BSSID: 00 30 BD 9E 50 7C / Key 0

WepKey: 43 30 44 45 31 45 45 37 43 3

(C0DE1EE7C0FFE) Encryption: 128 Bit time: 0.003213 sec

words: 21

The possibility to crack WEP without collecting massive amounts of encrypted data makes the dictionary attacks against 802.11 networks still using WEP a serious threat. An attacker can easily integrate WepAttack with Kismet, running it against the pcap dump file automatically while wardriving. As long as a few encrypted packets can be captured, the network can be attacked using this tool. Thus, a wardriver can collect a few weak WEP keys in addition to the casual network discovery without the need to park nearby and sniff the attacked WLAN for hours.

Tools to Retrieve WEP Keys Stored on the Client Hosts At the moment the only such tool we are aware of is the LucentRegCrypto utility. Lucent Orinoco Client Manager saves WEP keys in the Windows registry under a crackable encryption and obfuscation. Known examples of where the key might be stored include the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class \{4D36E972-E325-11CE-BFC1-08002BE10318}\0009\

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class \{4D36E972-E325-11CE-BFC1-08002BE10318}\0006 HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Class \{4D36E972-E325-11CE-BFC1-08002BE10318}\0006 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class \{4D36E972-E325-11CE-BFC1-08002BE10318}\0006 String Value: Encryption

LucentRegCrypto can be used to encrypt WEP keys to reg value or to decrypt reg value back into a WEP key. If you use Lucent Orinoco Client Manager, employ LucentRegCrypto to check if attackers can obtain the value of your network WEP from a machine to which they might have had temporary physical access or on which they managed to plant a backdoor. Using LucentRegCrypto is straightforward:

>_LucentRegCrypto -e [] -d [] -f ]

Use the leading slash for hex secret value. On Linux machines the WEP key is usually stored unencrypted in /etc/pcmcia/wireless.opts:

# Generic example (describe all possible settings) # Encryption key : 4567-89AB-CD, s:password

KEY="value"

The security of a key stored in such a way relies exclusively on the wireless.opts file permissions (check them on your system), which is clearly not sufficient. Developing a utility to encrypt the WEP key value in wireless.opts is a useful and a worthwhile task.

Traffic Injection Tools Used to Accelerate WEP Cracking As you probably know or have already guessed, the more wireless traffic you collect, the higher your chances are of obtaining the correct WEP key and the less time is needed to get it. Nothing stands in the way of rein jecting traffic into the WEP-protected WLAN without even being connected to it. This is because the original implementation of WEP, unlike TKIP and CCMP, does not include any traffic replay protection tools. You'll need to be able to monitor the traffic and reinject WEP-encrypted packets back into the network. To perform this task you will need a card in the RFMON mode, listening to the packets flying by and retransmitting the packets that pass a certain sanity check. That's right, we are going to use a card in a monitor mode to transmit data. A common myth is that 802.11 devices cannot transmit in the RFMON mode. In reality it is possible to transmit in the monitor mode, but you won't be able to ACK the replies coming back. Thus, normal bidirectional communication is impossible. In terms of traffic injection to accelerate WEP cracking or cause a DoS flood attack, ACKing is not important. A tool specifically designed to reinject traffic for improved WEP cracking efficiency is reinj from the Wnet suite for BSD written by H1kari, an author of BSD-Airtools. We review the complete Wnet suite later in the chapter when dealing with wireless frame-generating tools, as creating custom 802.11 frames is the main function and design purpose of the Wnet library and utilities. Here we briefly review the reinj utility. When launched, reinj injects ARP requests and TCP ACKs into the attacked WLAN. Both content and length of these packets are known and they generate known encrypted responses (ARP reply or TCP RST) as well. This makes the behavior of the tool very predictable and traffic generation more reliable. Of course there are other highly predictable response-generating packet types to try if a similar technique is being used (e.g. TCP SYNs or DHCP requests). Reinj is easy to use (reinj ) and will monitor the responses received in an attempt to determine if the injection

technique has worked (i.e., the additional traffic has been generated). If there is no reply, reinj will sniff for a better packet to reinject. Of course, you need to know the BSSID to inject the traffic, so you'll first need to sniff it out. When reinj detects what it considers to be an ARP or a TCP ACK packet, it attempts to reinject it into a network to generate more traffic. It does this five times in a row to verify the responses, and then starts injecting at the interval you specified in the command line. Of course, the duplicates reinj adds to the WLAN do not weaken the network cryptographically, but the responses these duplicate packets are aimed to initiate do. Thus, when reinj locks on the target and starts forcing the hosts on a WLAN to transmit encrypted data, cracking WEP becomes an easier and less time-consuming task, especially when using an improved FMS attack as implemented by dwepcrack. Even idle wireless networks can be successfully cracked, and (thanks to certain chatty network protocols) we have yet to see an idle WLAN. A tandem use of BSD-airtools and Wnet reinj makes OpenBSD (under which both tools compile and run) a superb platform for advanced WEP cracking. How about Linux? Unfortunately, there is no known Linux tool implementing an improved dwepcrack-style FMS attack against WEP. As for traffic injection aimed at decreasing WEP key cracking time, you can use WepWedgie, run from a looping shell script, and set to ping the target network on a presumed broadcast address. This should generate enough traffic to saturate the target network until the key is broken. Because WepWedgie is a complex and very advanced tool that does far more than simple traffic duplication and reinjection, it is covered in great detail in a separate section devoted to encrypted traffic injection and its use in penetrating WLANs without knowing the WEP key.

802.1x Cracking Tools With the advent of 802.1x (the detailed protocol description is provided in Chapters 10 and 13), the appearance of attacks and specific tools targeting this security protocol is inevitable. At the moment 802.1x authentication using Cisco EAP-LEAP takes the heaviest impact from the hacking community. The reason for this is probably the abundance of EAP-LEAP supporting networks due to the widespread use of Cisco wireless equipment and the fact that LEAP, like older EAP-MD5, relies on password and not certificate-based authentication. The main target of attacks against EAP-LEAP is its reliance on MS-CHAPv2 for user authentication. Thus, the attacks against EAP-LEAP are actually attacks against MS-CHAPv2 used in the clear and any other wireless authentication method employing it would be just as vulnerable. The purpose of this chapter is to describe the tools available to the hacking community; thus the peculiarities of the attack against EAP-LEAP (well, MS-CHAPv2) are outlined in Chapter 8. Right now you will learn about two utilities designed to snatch and crack user passwords

from the LEAP challenge/response exchange and a simple Perl script for LEAP authentication brute-forcing.

Asleap-imp and Leap The first tool is Asleap-imp, presented by Joshua Wright at Defcon 11. The "imp" in the tool name stands for improved. At the time of writing, Asleap-imp was not released to the general public, but we expect that as the book comes out it will be widely available. Asleap-imp consists of two programs. The first program, genkeys, produces a list of MD4 hashes from a password list. The list is built as a "password ^Tab^ hash" table and can be used for dictionary-type attacks against any protocol or password file generated with MD4. The second program, asleap, implements the attack itself in the following sequence: 1. The data is read from a wireless interface in the monitor mode or a pcapformat dump file (e.g., a Kismet dump). 2. EAP-LEAP challenge/response frames are captured. 3. The last two bits of the NT hash are calculated using a flaw in MS-CHAP authentication (see Chapter 8). 4. Match these and remaining bits with the password:hash list produced by keygen and report cracked passwords. Because waiting for EAP-LEAP logins can take a lot of time, Asleap-imp bypasses the problem by knocking the authenticated users off the WLAN. To do this, the tool scans through all 802.11 channels, identifies active clients, and sends a spoofed EAP-LEAP Logoff frame to the target. This frame is followed by a spoofed deauthentication frame to disconnect the target host from the wireless network. Thus, a new challenge/response exchange is triggered. This exchange is saved in a pcap-format file to allow password cracking on a different machine (e.g., the auditor's desktop with more CPU power, disk space, and very long password list). The second tool is leap by DaBubble, Bishop, and Evol. Unlike Asleap-imp, it was released to the general public via the Packetstorm Web site (http://www.packetstormsecurity.org) at the time of writing. The principle behind leap and Asleap-imp action is the same; however, leap lacks documentation and does not automate challenge/response grabbing and host deauthentication and deassociation. Also, you will need to generate the password:hash list yourself. To produce the list, you can modify chaptest.c, which comes with the tool, or use the MD4 reference implementation code (RFC 1320) modified to run against a word list. After the list is produced and challenge/response strings are captured,

place them into bfnthash.c at:

//Enter challenge response here char *challengeResponse = ""; //Enter challenge here char *challenge

= "";

Two other variables you might want to modify are NUM_HASHES (the maximum amount of hashes to read from the password:hash list, default = 10,000) and the limit of bfnthash threads to run (defaults to < 200). Compile bfnthash, launch it giving the password:hash list file name and the amount of threads to run as an input, and hope that the user password is on the list.

Leapcrack Both attack tools against 802.1x/EAP-LEAP implement improved and intelligent dictionary attacks against the protocol's authentication mechanism. Plain old EAPLEAP user password brute-forcing is another option to consider. The tool to accomplish it is Leapcrack written for the BSD operating system. Leapcrack consists of the Francisco Luis Roque network discovery script shown in the BSD tools for wireless network discovery and traffic logging section and another Perl script, anwrap.pl. Anwrap.pl is a wrapper for the ancontrol BSD command, which acts as a dictionary attack tool against LEAP-enabled Cisco-hardware-based wireless networks. The script traverses the supplied user and password lists, attempts the authentication, and logs the results to a file. To run anwrap.pl you need a Cisco Aironet card, a brought-up interface, and an installed libexpect-perl library. Using the script is easy:

arhontus:~# perl anwrap.pl Usage : anwrap.pl

Ron Sweeney Brian Barto

Keep in mind that running anwrap.pl against NT networks with implemented lockout policies will severely disrupt the performance of RADIUS authentication.

Wireless Frame-Generating Tools Because 802.11 management and control frames are neither authenticated nor encrypted, being able to send custom 802.11 frames gives a wireless attacker an unlimited opportunity to cause Layer 2 DoS attacks on a targeted WLAN. Even worse, a skilled attacker can spoof his or her attacking machine as an access point, wireless bridge, or client host on the unfortunate infrastructure or managed network or as a peer on the independent or ad-hoc WLAN. Then a DoS attack can be used to deassociate WLAN hosts from a legitimate access point or bridge and force them to associate with the attacker's machine. There are two main tools that allow custom 802.11 frame generation: AirJack suite (Linux) and the more recent Wnet dinject utilities collection (OpenBSD). To an extent, HostAP drivers for the Prism chipset cards can also be considered as 802.11 frame-generating tools, because access point functionality involves transmitting beacons and sending probe response frames. FakeAP from Black Alchemy, which is run on top of HostAP and uses Linux Wireless Extensions to generate custom beacons, underlines such functionality and can be employed in several 802.11 attacks as well as for its intended use as a wireless honeypot. Void11 is another frame-generating tool that uses HostAP and is designed for data link DoS attacks on 802.11 networks, including mass DoS attacks.

AirJack The AirJack suite was originally made up of a custom driver for Prism II chipset cards and a few end-user utilities that use the airjack_cs module's custom 802.11 frame-generation capabilities to launch a variety of attacks against WLANs. An expected but delayed second release of AirJack should support wireless hardware with chipsets other than Prism. Here we describe the first versions of AirJack, extensively tested and tried at the moment of writing. The attack utilities included with the two first versions of AirJack contain DoS by sending deauthentication frames, closed ESSID disclosure attack via forcing host reauthentication, and Layer 2 man-in-the-middle attack with an additional possibility of a specific man-in-the-middle attack against FreeSWAN-based Wavesec wireless IPSec implementation. Later versions of AirJack include only the closed ESSID disclosure attack utility. Nevertheless, the utilities from earlier versions, written to implement the attacks just mentioned, work fine with the later AirJack versions. The main functionality of AirJack is based around its ability to send deauthenticate 802.11 frames. For those interested in how AirJack generates deauthenticate frames, here is an example of the frame-building code:

void send_deauth (__u8 *dst, __u8 *bssid) { struct { struct a3_80211 __u16

hdr;

reason;

}frame; memset(&frame, 0, sizeof(frame)); frame.hdr.mh_type = FC_TYPE_MGT; frame.hdr.mh_subtype = MGT_DEAUTH; memcpy(&(frame.hdr.mh_mac1), dst, 6); memcpy(&(frame.hdr.mh_mac2), bssid, 6); memcpy(&(frame.hdr.mh_mac3), bssid, 6); frame.reason = 1; send(socket, &frame, sizeof(frame), 0); }

Despite being developed for Prism II chipset cards, AirJack end-user utilities use Hermes chipset cards in man-in-the-middle attacks, providing the orinoco.c.patch included with the suite is applied. This patch was designed for pcmcia-cs services version 3.1.31 and you might want to see if it will work with later versions of the card services to use a Hermes chipset card with the AirJack man-in-the-middle utilities. Our experience in applying the patch to pcmcia-cs3.2.1 wasn't successful, so you might be forced to downgrade to version 3.1.31 or rewrite the patch.

The code of AirJack is GNU and available for download at both http://802.11ninja.net/airjack/ and Sourceforge; several crippled copies of AirJack can be found on the Web and you'll need some C knowledge to fix them. To compile AirJack do make; if you are plagued by the 'cmpxchg' undefined symbol error message, change the AirJack Makefile CFLAGS line from

CFLAGS= -O2 -Wall -Werrow -DMODULE -D__KERNEL__$(INCLUDES)

to

CFLAGS= -O2 -Wall -DMODULE -D__KERNEL__ $(INCLUDES)

Then copy the airjack_cs.o module to your modules path (should be /lib/modules//pcmcia) and run depmod. After that use the linux-wlan-ng-generated /etc/pcmcia configuration files and replace all bind "prism2_cs" strings in wlan-ng.conf and config by bind "airjack_cs". Alternatively, you can use the ready configuration files supplied on the accompanying Web site. Unplug your wireless card and restart the card manager. Plug the card back in and do lsmod. You should see something like this in its output:

Module airjack_cs

Size 16712

Used by

Tainted: P

Then do ifconfig -a and check if there is an aj0 interface:

arhontus:~# ifconfig -a aj0

Link encap:UNSPEC

HWaddr 00-DE-AD-C0-DE-00-00-00-00-00-00-00-00-0

UP BROADCAST RUNNING MULTICAST

MTU:1600

Metric:1

RX packets:1754241 errors:17589 dropped:0 overruns:0 frame:17589 TX packets:0 errors:19624 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:120758718 (115.1 MiB)

TX bytes:0 (0.0 b)

Please note that iwconfig will not show any data about the aj0 interface, because no wireless extensions are present within this device. Bring up the aj0 interface with ifconfig aj0 up. Go to the airjack-v0.6.2-alpha/tools directory and do make. Then do make monkey_jack. Congratulations, your AirJack should be ready for use. If you want to employ a Hermes chipset card for man-in-the-middle attacks, first patch the pcmcia-cs sources:

arhontus:~#cp /airjack-v0.6.2-alpha/patches/orinoco.c.patch \ /usr/src/pcmcia-cs-3.1.31/wireless/ arhontus:~# patch -p0 < orinoco.c.patch arhontus:~# ./Configure ​force

Back up your existing PCMCIA modules and install the patched pcmcia-cs. Check that both Prism II and Hermes chipset cards can fit into your PCMCIA slots

simultaneously (having both cards with MMCX connectors and without built-in dipole antennas is a good idea). The end-user attack utilities for AirJack include the following: essid_jack, which forces wireless hosts to reauthenticate with an AP on a closed network and sniffs the hidden ESSID in the process wlan_jack, the deauthentication spoofed MAC address frames flooder monkey_jack, the man-in-the-middle attack tool (which inserts the AirJackrunning host between the access point and a target machine on a WLAN) kraker_jack, a modified monkey_jack capable of inserting the attacking host between Wavesec client and server Wavesec (http://www.wavesec.org) is a wireless-specific mobile implementation of the Linux FreeSWAN IPSec client. The peculiar thing about Wavesec operation is the way it arranges the trust required between the wireless client and the IPSec gateway. Wavesec does it by exchanging public keys during the DHCP address assignment. The client provides its forward hostname and public key in a DHCP request. The DHCP server then inserts both into the DNS server for the reverse zone (the IP to hostname mapping) using dynamic DNS update. Kraker_jack attacks these specific key exchange features of Wavesec to insert the attacking host between the Wavesec client and server on a second layer (monkey_jack), replace the client key by its own, and decrypt bypassing data. Thus, kraker_jack does not attack the FreeSWAN and IPSec protocol per se, and FreeSWAN IPSec settings based on the shared secret or x509 certificates we describe in Chapter 14 are not vulnerable to the kraker_jack attack. Other utilities included among the AirJack tools are setmac and set_channel for the Hermes chipset card when used in man-in-the-middle attacks (selfexplanatory) and dump_core, which allows you to monitor raw output from the aj0 interface (pipe it into a file and use strings to see the ESSIDs of present wireless networks, etc.).

File2air File2air is a tool written by Joshua Wright to allow custom frame generation using the AirJack drivers. File2air reads binary output from a file and sends it to the air, as the tool's name suggests. This means that virtually any frame, including 802.1x frames, can be sent to the wireless network for whatever reason you

might have to send it. It also means that you will have to possess a good knowledge of 802.11 (or other) protocols to write your custom frames in binary format to be fed to File2air and spend a sufficient time in front of your favorite hex editor (e.g., Gnome's Ghex). On the other hand, this gives you a good incentive to learn the protocol suite and enjoy complete freedom in what you send. The first version (v0.1) of File2air, which came out just as the draft of this book entered the final stage, included three binary sample frames in the ./packets directory: deauthenticate, probe response, and eap-authentication-failure (deauth.bin, proberesp.bin, and eap-failure.bin, respectively). See the README file for examples of attacks using these sample binaries. Doubtless, the number of binary frame files submitted by users will grow like an avalanche and the functionality of the tool will dramatically expand. For the users' convenience, variable fields in the frames such as source and destination MACs and ESSIDs can be overwritten from the command line when File2air is run:

arhontus:~# ./file2air -h

file2air v0.1 - inject 802.11 packets from binary files 192.168.22.10.80: S 3860910504:386091 5840 (DF) 20:33:09.722845 192.168.11.6.67 > 192.168.22.10.80: R 0:0(0) ack 1 win

20:33:10.398257 192.168.11.6.25 > 192.168.22.10.80: S 3862759594:386275 5840 (DF) 20:33:10.492642 192.168.11.6.68 > 192.168.22.10.80: R 0:0(0) ack 1 win

In the case of UDP scanning, you should receive an ICMP port unreachable packet if the port is closed. Bear in mind that the UDP scan is slow and unreliable. To get a reliable result, you will have to run the UDP scan several times, analyzing all the received responses once again and comparing them with the previous results. The Wepwedgie UDP scan tcpdump output on the helper host should look similar to this:

20:38:17.898804 192.168.11.6 > 192.168.22.10: icmp: 192.168.11.6 udp po [tos 0xc0]

20:38:18.069897 192.168.11.6 > 192.168.22.10: icmp: 192.168.11.6 udp po

[tos 0xc0]

20:38:18.270881 192.168.11.6 > 192.168.22.10: icmp: 192.168.11.6 udp po [tos 0xc0]

20:38:18.423484 192.168.11.6 > 192.168.22.10: icmp: 192.168.11.6 udp po [tos 0xc0]

When using the Wepwedgie toolkit, we strongly recommend reading through the source code and understanding how it works, as you are likely to modify it for your particular needs rather than use it straight out of the box, since it is still in the alpha stage.

Access Point Management Utilities Although access point manufacturers usually provide necessary configuration utilities, or, most likely, the access point will have an easy-to-use configuration interface accessible via a casual Web browser, there are some utilities that can come in handy while auditing access point security. Our favorite set of such tools is Wireless Access Point Utilities for UNIX (ap-utils) by Roman Festchook, which allows both configuration and monitoring of access points from a UNIX machine via the SNMP protocol. Ap-utils support most Atmel chipset-based access points with ATMEL Private MIB. No Wires Needed APs (IEEE 802.11 MIB and NWN DOT11EXT MIB) are also supported. The list of access points supported by ap-utils is included in the utilities README file and is quite extensive, including common access points produced by Linksys, Netgear, and D-Link. All you need to do is to launch ap-config, enter the IP address of an access point, and know (or guess) the appropriate SNMP community. Ap-config allows you to undertake a huge range of activities, ranging from searching for connected access points to enabling or disabling antennas in addition to the following: Hide ESSID in broadcast messages Enable device test mode Get information about the AP software and hardware Dynamically update Ethernet and wireless ports statistics List associated stations and visible APs (with an option to save MAC addresses of current associated stations to file) Execute other supported commands on the AP It can save you a lot of time spent with snmpget, snmpset, and Co (besides, NetSNMP utilities do not provide friendly ncurses-based interfaces). Apart from apconfig, ap-utils include ap-mrtg and ap-trapd. Ap-mrtg gets statistics from ATMEL-based access points and returns the output in the Multi Router Traffic Grapher (MRTG) format. Ap-mrtg can get and show Ethernet statistics in bytes, WLAN statistics in packets, and the number of associated hosts and link quality and signal strength statistics from AP in a client mode. Although these parameters are not directly security related, they can be helpful in determining the general WLAN health and baselining WLAN traffic, which helps in detecting anomalies on your network, DoS attacks, or bandwidth theft. Ap-mrtg includes the following options:

arhontus:~# ap-mrtg -h Usage: ap-mrtg -i ip -c community -t type [-b bssid] [-v] [-h] [-r] Get stats from AP and return it in MRTG parsable format: -i ip

- AP ip address

-c community - SNMP community string -t type

- statistics type ireless, thernet, associated ta

quality in client mode -b bssid

- mac address of the AP to which get link quality, only if

-v

- report MRTG about problems connecting to AP

-r

- reset AP when getting LinkQuality stats

-h

- print this help screen

Ap-trapd is a daemon to receive, parse, and log SNMP trap messages from access points. It interfaces with syslog (logging level 0) and can log the following common SNMP traps: Trap Reassociation: This trap message is sent when a station reassociation request is received from an access point. Trap Association: This indicates the reception of an association request packet and the sender station's successful association with the access point. Trap Disassociation: This trap message is sent when a disassociation notification packet is received from a station.

Trap Reset: This trap message is sent when an access point resets. Trap Setting IP Address with Ping: This trap message is sent when the access point IP address is set with the transmission of a ping message. Trap Start Up: This trap message is sent when the access point starts up. Trap Failed to Erase Flash: This trap message is sent when an access point failed to erase flash. Some of these traps provide security-relevant information, for example, Trap Setting IP Address with Ping and Trap Disassociation. Ap-trapd can be run with ap-trapd [ -i device ] [-u user ] options that allow you to specify the device to listen for traps (Linux only) and set an unprivileged user for ap-trapd to run as (the default is "nobody"). Apart from ap-utils, there are several other useful access-point-specific configuration and monitoring utilities. For example, SNR is a Perl tool that collects, stores, and shows SNR changes for Lucent access points using SNMP. You'll need librrds-perl, libunix-syslog-perl, libappconfig-perl, and libsnmp-perl libraries to install and run SNR. For tweaking with Apple AirPort access points there is a Python Airconf utility, which was tested under different flavors of UNIX with Python 2.2, but should also work with Python 2.x on MacOS 9, and Microsoft Windows. To install Airconf, do:

arhontus:~# install -c -m 755 -d airport_aclupdate /usr/local/bin arhontus:~# install -c -m 600 -d airport.acl /usr/local/etc arhontus:~# install -c -m 600 -d airport.bases /usr/local/etc arhontus:~# python setup.py install arhontus:~# rehash

The major feature of Airconf is configuring the access control lists on several Apple AirPort Base Stations at once. Airconf can also be used for specific detection of the Apple AirPort Base Stations (white and graphite) using the python

airport_detect.py command as well as reading, printing, and remotely changing their configuration (only graphite). Another tool you might want to use for controlling and monitoring Apple AirPort access points is airctl. Before using it, check that the correct address and port number for your AP are placed in the airctl preprocessor directive.

Summary The available number of useful wireless security auditing tools is staggering. Even better, the majority of the most powerful tools are open source and free, which allows you to experiment with them as much as you like and modify the source to suit your specific requirements. If you are a software developer, you most likely won't need to write your new wireless security tool or library from scratch; there is a fair amount of great code you can use and learn from. Study, categorize, and update your wireless penetration-testing armory with great care and attention. Always remember that Black Hats can use the same tools and they do know why, when, and how to use them. Outlining the planning and sequence of a successful attack against an 802.11 network to understand the "why, when, and how" is the main aim of the next two chapters.

Chapter 7. Planning the Attack "It is best to thwart people by intelligent planning." ​Wang Xi The majority of specific IT security literature sources would list the available tools and appropriate commands and call it a day. We call it an early caffeinated morning. Knowing the basics of wireless networking and which tools to use to discover access points, dump the traffic, crack WEP, and so on is not enough. In fact, it only brings the attacker to the "script kiddie" level, whereas a wireless security professional should be far above it. You should understand how the protocols involved and the available attack methodologies work (something that is slowly uncovered through this book). Apart from that, you should also have a precise calculated plan of your penetration testing procedure, taking into account all known peculiarities of the network you are after.

The "Rig" By now, a penetration testing kit should be properly assembled and tested on your lab WLAN to avoid any unpleasant surprises (unresolved symbols when inserting the modules, card service version incompatibility, unreliable pigtails, etc.) in accordance with the almighty Murphy's Law. If you are serious about your business, your kit is likely to include the following components: 1. A laptop with a double PCMCIA card slot and Linux/BSD (or both) properly configured and running. 2. Several PCMCIA client cards with external antenna connectors and different chipsets: Cisco Aironet for efficient wireless traffic discovery and easy-to-perform multichannel traffic logging and analysis Prism for WEP cracking, including traffic injection cracking acceleration; DoS via FakeAP, Wnet, or AirJack; Layer 1 man-in-the-middle attacks with HostAP and a second Prism chipset card (!); Layer 2 man-in-themiddle attacks with AirJack and Hermes chipset card; or Layer 2 man-inthe-middle attacks using Wnet, HostAP mode, and a second Prism chipset card on the OpenBSD platform Hermes/Orinoco for WEP cracking excluding traffic injection cracking acceleration and Layer 2 man-in-the-middle attacks using AirJack and a Prism chipset card Atheros chipset card for 802.11a security auditing 3. At least two external antennas (an omnidirectional and high-gain directional) with all appropriate connectors and possibly a mounting tripod. 4. Specific wireless security tools of your choice set and ready. You must be able to perform the following: Network discovery and traffic logging in the RFMON mode Wireless traffic decoding and analysis WEP cracking and 802.1x brute-forcing (where applicable) Custom Layer 2 frame generation and traffic injection Setting at least one of your cards to act as a rogue access point

5. Non-wireless-specific attack tools set and ready. We cover this aspect in Chapter 9. Optional toolkit components might include the following: A GPS receiver plugged into your laptop's serial port A PDA loaded with Kismet or Wellenreiter and some signal strength monitoring utility More antennas, including semidirectionals Spare batteries Amplifier(s) A rogue wireless backchannel device if you plan to test wireless and physical security. The best example of such a device is a preconfigured small 802.11 USB client that can be quickly and covertly planted on the back of one of the company servers or workstations. Maps of the area (electronic or paper) Binoculars (to spot antennas on roofs, etc.) Transportation means (feet, car, bike, boat, plane, zeppelin, or hot air balloon) Before doing anything, test that you can capture and decode traffic, crack WEP, and transmit frames (sniff them out) in the testing lab network conditions. Pay special attention to the antenna connectors and their resilience to moving the equipment around. When you are sure that everything works as intended and will work as intended in the field, you can proceed to the next phase. This phase does not involve driving, walking, sailing, or flying around the tested site with protruding antennas. It involves thinking and "Googling."

Network Footprinting Do an in-depth Internet search about the target area or corporation. Never underestimate the power of Google. The area you are going to map for expected WLANs could've been mapped by someone else before, with results published on the Web on some wardriving site, message board, or blog. There are plenty of wireless community sites that publish information about public and enthusiast wireless network locations and names. An example of such a site in the United Kingdom is http://www.consume.net. A Royal London example of a consume.net community WLAN map is shown in Figure 7-1 (but there are far more wireless networks in that part of London than shown on a given map, trust us). An interesting link about wireless network mapping in the United States with further links to more specific community sites is http://www.cybergeography.org/atlas/wireless.html. Check it out. The most broad and comprehensive list of wireless community networks worldwide is published at WiGLE (http://www.wigle.net) that contains more than 1,000,000 WLANs worldwide and http://www.personaltelco.net/index.cgi/WirelessCommunities. You are likely to find some in your evaluation area simply by browsing the list. Apart from finding the known site wireless networks by online searching, you might also find useful information about possible sources of RF interference in the area such as radio stations operating in microwave range, large industrial complexes, and so on.

Figure 7.1. Public networks in London according to Consume.net.

[View full size image]

Conduct an extensive search and find out as much as you can about the specific target and client network(s), both wireless and wired sides. This is a normal footprinting procedure that must precede any penetration testing mission independent of the network type. Is the wireless network somehow accessible from the Internet? What is its topology? Size? Which protocols are used? Which departments in the enterprise use it? Who set the network up and who is the network administrator or manager? Is he or she known in the wireless world, certified in wireless networking, or has he or she earned a relevant degree? Did he or she ever post any questions, comments, or advice to relevant message boards or newsgroups? You might be surprised how much information could be available about the network you target. Of course, you should extract as much information about the target network from your client management and administration and never miss an opportunity to use social engineering to find out what they won't tell an outside consultant. You don't have to be called "Kevin" to be a good social engineer; check the tips at http://packetstormsecurity.nl/docs/social-engineering/ and use common sense and situational adaptation to succeed.

Site Survey Considerations and Planning After the data-gathering phase is complete, decide how you are going to survey the area and position yourself. The possibilities include the following: Warwalking Warcycling Wardriving Warclimbing Each tactic has its own advantages and disadvantages. Warwalking does not cover a large area, but a large amount of dumped data is guaranteed. You can stop at any point to check the signal strength, check the network traffic in real time, attempt to connect to the network, launch DoS or man-in-the-middle attacks, and so on. Besides, you have the advantage of physically surveying the area to spot the following: Antenna positions and type Outdoor access points "No Bluetooth" or "no cordless phones" signs Warchalking signs "No Bluetooth" or similar signs are a clear indicator of a wireless network with a system administrator understanding the concept of interference and taking care to prevent it. Warchalking refers to marking the sidewalks and walls to indicate nearby wireless access points. A good source on warchalking is http://www.warchalking.org. It is essential that you familiarize yourself with warchalking signs and their significance. To assist you, we have gathered a small collection of warchalking signs and placed it in Appendix F. Depending on the area, two different warchalking signs might mean the same thing, and there is even a sign for FHSS networks. Thus, do not consider the relative obscurity of your non-802.11 DSSS network such as HomeRF or 802.11 FHSS WLAN to be an ultimate protection against possible intruders. Someone must be out there scanning for them and we won't be surprised if new warchalking signs ("Bluetooth PAN," "non-802.11 standard point-to-point link," as well as "WEPPlus WLAN," "802.1x in use, EAP type is ...," "802.11i-enabled network," "TKIP," "TurboCell,"

etc.) decorate the streets soon. Warwalking has some obvious disadvantages: You have to carry all your equipment around (antennas present the largest problem) and have power limited to the battery power of your laptop or PDA and the amount of spare batteries you can carry. It is unlikely you can take a very high-gain directional antenna or an amplifier on a warwalking trip. Most important, a warwalker and his or her equipment are exposed to the adverse effects of the elements. Laptops do not really enjoy rain, and wet RF connectors mean a significant loss that might persist afterward due to rusting. Wardriving, on the contrary, provides good protection against the elements and a good source of power in the form of a car battery and a generator. You can discover all networks in the area, and it doesn't matter how fast you drive: The beacon frames are sent every 10 milliseconds and you won't miss one while passing by or through the WLAN. Of course, you won't dump a lot of traffic unless you drive really slowly and will have difficulties in observing and analyzing the packets in the air and launching various attacks unless you can park in the appropriate place. This is often impossible in the center of a large city or on a private corporate premises. Another obvious problem when wardriving is the antenna. You'll need to place an external antenna outside of the car to avoid a significant loss caused by the car frame. Remember that even a normal glass brings around 2 dBm of loss. Of course, placement of an external antenna would mean an RF cable with connectors, which brings more loss. Typical wardriver kits or "rigs" include a magnetic-mount, ground plane, omnidirectional antenna with about 5 dBi gain and a thin pigtail-style cable that might cause more loss than the gain produced by the little omnidirectional on the top of the car. Mounting anything better on your car roof would present an additional technical challenge and you won't be able to use high-gain directional antennas unless you wardrive in a convertible. Thus, an appropriate combination of wardriving and warwalking is usually required. Warcycling presents an intermediate solution between warwalking and wardriving. You are power-limited, exposed to elements, and slow, but some traffic can be dumped in the process, there is no metal cage around, parking is easy, and no one can stop you from hanging a covered high-gain omnidirectional over your shoulder. The use of directional antennas while warcycling does not make any sense and your hands are usually too busy to type any commands. A PDA fixed between the bike handlebars might provide a good solution for real-time traffic and signal strength monitoring when warcycling. "Warclimbing" is a term we use at Arhont to define discovering, analyzing, and penetrating wireless networks from a stationary high position. Why go and look for a network if the network might come knocking at your door? In summer 2002, from the top of the Cabot Tower in Bristol (Figure 7-2) we discovered 32 wireless networks using a 19 dBi directional grid or half that number of networks using 15

dBi Yagi. Some of these networks were in Bath and across the Welsh border, quite an impressive reach! Even with a 12 dBi omnidirectional we were still able to detect about a dozen networks in the area; I guess the number has grown significantly since then.

Figure 7.2. Cabot Tower in Bristol, United Kingdom.

A high place from which to search and connect might be a tall building roof, top of a hill, or a room on the top floor of an appropriately placed hotel where a determined wireless attacker could stay for a day or two to get into the target corporate wireless network. The advantages of warclimbing are derived from the stationary position of an attacker and the distance and link quality obtained by using a high-directional antenna and having a clear line of sight (LoS). Of course, appropriate warclimbing sites have to be present and the best site found by checking the signal strength of a targeted network. In terms of penetration testing, finding all such sites in the area and being aware of their positions

beforehand can be a great help should one ever need to triangulate and find an advanced attacker armed with a high-gain directional antenna and confident of his or her invincibility, like Boris in Golden Eye. We do not cover more exotic methods of enumerating wireless networks such as warflying. As someone pointed out at Slashdot, "How do you chalk from 12,000 feet high?" Surely the networks could be discovered, but if you manage to log a single data packet, consider yourself lucky. Nevertheless, we are planning a trip in a hot air balloon with a decent directional antenna, a hybrid of warclimbing and warcycling, perhaps. When planning your site survey and further penetration testing, take into account the things you might already know from the data-gathering phase; for example, the area landscape and network positioning: Which floors of the buildings are the access points or antennas on? Where are the antenna masts? What are the major obstacles in the area? From what material are the building walls constructed? How thick are the walls (see the Obstacles/Loss table in Appendix E)? Are any directional antennas used for blasting through the obstacles present? How good is the physical security of the site? How are the guards and closedcircuit TV (CCTV) cameras positioned?

Proper Attack Timing and Battery Power Preservation Another very important part of planning a wireless penetration test is timing. First of all, an appropriate time should be established with the client company or organization so that disruptive testing (e.g., DoS attack resilience tests) does not interfere with client business operations. However, some forms of wireless security testing, including site surveying and WEP cracking, must be done at the peak of WLAN usage. Estimate when users are most likely to log in to the target network and when it is used the most. This will help not only in WEP cracking (remember, the more traffic the better), but also in post-decryption attacks, which involve user credentials and password collection. Such attacks are very important to demonstrate to management both the severe consequences of a wireless security breach and the necessity of using secure protocols on a WLAN in a manner similar to protecting an insecure WAN connection through a public or shared network. An issue closely related to timing is battery power management and estimation. How much time do you need to perform what you've planned to do? Would you have enough battery power to accomplish it? WEP cracking is often a timeconsuming process, and when traffic injection is used to accelerate WEP cracking and preserve time, additional battery power is spent transmitting the injected packets. Thus, in terms of real-world cracking, traffic injection can be a doubleedged sword unless the cracker has a decent additional power source (e.g., car battery). As a penetration tester you would usually be able to plug your laptop into the corporate grid, but it might not have to be the case. An ultimate penetration test is doing what the crackers do, and no one would (or at least should) let a cracker plug his or her laptop into the company power socket (although a cracker might use a socket in a pub or restaurant across the street). Let's take a look at ways of preserving battery power in field conditions. There are a couple of simple measures you can take to save your laptop's power. Kill all services you do not need when mapping the network (and you do not actually need them; we only leave syslog running). Do not run X Windows; running GUIs lays batteries to waste! In fact, close the laptop so that the screen is powered down. If you can, decrease the transmission power of your wireless card to the minimum (possible with Cisco Aironet and some other PCMCIA cards). We have found that if normally the laptop batteries last for slightly less than two hours while wardriving or walking, when everything just outlined is done, the batteries survive for possibly two-and-a-half hours (with Kismet and tcpdump running in the background). Consider dumping all the data to the RAM and setting the hard disk to turn off after a short period of inactivity. Most modern laptops have a decent amount of memory that should satisfy your packet dumping needs. Just don't forget that it is volatile storage, so leave enough battery power to sync the data back to the hard disk when done or shortly before the battery dies. Stick to the command line and you will save time and power and improve your typing

skills. In addition, you can optimize your efficiency by writing necessary shell scripts beforehand or compiling the lists of commands for quick cutting and pasting with a need to replace only a few variables such as IPs, MAC addresses, or DSSS channels. As previously mentioned, avoid active scanning unless absolutely necessary (e.g., to test the IDS system or produce IDS signatures). The arguments presented here provide additional reasons supporting the preference for UNIX-like systems in wireless security auditing.

Stealth Issues in Wireless Penetration Testing A final issue you might need to consider is the level of stealth while penetration testing. In some cases a high level of stealth can be required to test the value of a deployed IDS system. Stealth in wireless network attacks can be reached by doing the following: Avoiding active scanning for networks Using highly directional antennas Decreasing the transmission power when dumping traffic Intelligent MAC address spoofing Removing specific wireless attack tools' signatures from the code (reviewed in Chapter 15) DoS attacks directed to knock out wireless IDS sensors (scroll to Chapter 8 for more information). Of course, higher (third and upper) layer IDS avoidance measures (partially covered in Chapter 9) are important when the postassociation attacks are carried out. Watch for these pesky probe requests! Cisco Aironet cards might still send probe requests when in RFMON mode. Although the issue has been solved in the Aironet modules eqipped with the 2.4.22 and higher Linux kernel versions, it might be possible that under other operating systems the probe requests are still sent. Besides, you might still use an older kernel version.

An Attack Sequence Walk-Through To summarize our observations, a well thought out professional attack against a wireless network is likely to flow in the following sequence: 1. Enumerating the network and its coverage area via the information available online and from personal contact and social engineering resources. Never underestimate the power of Google and remember that humans are and always will be the weakest link. 2. Planning the site survey methodology and attacks necessary to launch against the tested network. 3. Assembling, setting, configuring, and checking all the hardware devices and software tools necessary to carry out the procedures planned in the step 2. 4. Surveying the network site and determining the network boundaries and signal strength along the network perimeter. At this stage use the omnidirectional antennas first, then semidirectionals, then high-gain directional grids or dishes. Establish the best sites for stationary attacks against the target network. Considerations when finding such sites include the LoS, signal strength and SNR, physical stealth factors (site visibility, reachability by security guards and CCTV), comfort for the attacker in terms of laptop and antenna placement, and site physical security (watch out for rough areas; laptops are expensive!). 5. Analyzing the network traffic available. Is the traffic encrypted? How high is the network load? Which management or control frames are present and how much information can we gather from them? Are there obvious problems with the network (high level of noise, channel overlapping, other forms of interference, lost client hosts sending probe requests)? 6. Trying to overcome the discovered safeguards. This might involve bypassing MAC and protocol filtering, determining close ESSIDs, cracking WEP, and defeating higher layer defensive countermeasures, such as the wireless gateway traffic filtering, RADIUS-based user authentication, and VPNs. 7. Associating to the wireless network and discovering the gateway to the Internet or border router, possible wireless and wired IDS sensors, centralized logging host(s), and all other detectable hosts on both wired and WLANs. 8. Passively enumerating these hosts and analyzing security of protocols present on the wireless and connected wired LANs. 9. Actively enumerating interesting hosts found and launching attacks against them aimed at gaining root, administrator, enable, and other privileges.

10. Connecting to the Internet or peer networks via the discovered gateway and testing the ability to download and upload files from the Internet or peer network to the wireless attacker's host. Give this scheme a try, and you might find that your wireless penetration testing efficiency has improved dramatically, even though you did not introduce any additional tools apart from the ones you are using already. To conclude this chapter, we recommend you review a pared-down version of the wireless network security and stability audit template used by Arhont's wireless network security and troubleshooting team as a part of a casual wireless audit practice. The template opens Appendix G; simply browse to its section on wireless penetration testing and check out the general wireless networking considerations and site survey procedures on the way. It should give you an idea about a proper wireless security audit plan that you can further improve and incorporate into your everyday work environment. Some points on the template that might not be clear for you right now are going to be explained later in the book. Of course, you might have developed a similar plan already. We are open to all propositions and additions to the template.

Summary Planning and documenting the attack is as important as having all necessary hardware and software tools. Efficient planning preserves your time and effort, provides useful clues before the actual audit begins, and ensures that no unpleasant surprises (e.g., running out of power in the middle of the scan) will occur during the test. "The battle should be won before it starts." (Sun Tzu)

Chapter 8. Breaking Through "To advance irresistibly, push through their gaps." ​Sun Tzu If you have already read the wireless penetration testing section of the template in Appendix G, you will find that this chapter is a more detailed walk-through. If you understand how WLANs work, comprehend the general wireless security principles, and have researched both tools of the trade and test and attack planning chapters, you might skip this one. Otherwise, stay with us and read the answers to your questions.

The Easiest Way to Get in The first thing any attacker looks for is "low-hanging fruit." An inexperienced attacker will search for it because he or she can't get into anything else, whereas an experienced Black Hat will look for it to save time and to be sure that (unless it's a honeypot) no IDS and egress filtering is present and hosts on the network are easy to break into for further backdoor planting. Despite the opinion of a few "security experts," the amount of wide-open wireless networks is incredible. By "wide open" we mean no WEP, no MAC filtering, no closed ESSID, no protocol filtering, and most likely AP management interface accessible from the WLAN. There are a variety of reasons why this situation exists, the major one being the users' (or even system administrators') laziness and ignorance. When attacking such networks, a cracker has only three main concerns: physical network reachability, connectivity to the Internet, and the (rare) possibility of a honeypot trap. Let's explore each in further detail. Physical network reachability: Even if a network is wide open, it is no good (for a cracker) if the only way to connect to it is to sit with a laptop right under the office window. Connectivity to the Internet: Is it present and how "fat" is the "pipe"? Honeypot trap: Is trouble on the way? The first issue, reachability, is addressed by a high-gain antenna. A high-gain omnidirectional might look like a walking stick or a pool cue and will not raise any suspicions. The majority of Yagis can pass for poster holders and even the directional dishes would not surprise anyone as long as the cracker passes himself or herself off as telecom engineer troubleshooting a link or even an amateur radio enthusiast. It is truly amazing when you sit in the park with a huge antenna in the middle of nowhere and present yourself as a university student doing research. The second issue, connectivity, can be sorted via multiple means; for example, by looking at the DHCP traffic present, a gateway IP would be shown. We have to admit, we like Ettercap. Press "p/P" for the Ettercap plug-ins available. The plug-in that discovers LAN gateways is called triton. The last issue, the honeypot trap, is difficult to solve. Use your intuition and skill to determine whether this low-hanging fruit is poisoned. Looking for sniffers helps; check out the hunter plug-in in Ettercap (Figure 8-1).

Figure 8.1. Ettercap hunter plug-in.

[View full size image]

Of course, as a corporate penetration tester you can simply ask if there are honeypots, but that would spoil both fun and the challenge, would it not?

A Short Fence to Climb: Bypassing Closed ESSIDs, MAC, and Protocols Filtering Let us explore slightly more protected WLANs. How about so-called closed networks? ESSID makes a bad shared secret. The reason is that it is not removed from all management frames. For example, reauthenticate and reassociate frames will contain the ESSID value. Thus, a network with roaming hosts will not benefit from the closed ESSIDs at all and sending a deauthenticate frame to one or more hosts on the closed WLAN is easy:

arhontus:~# ./essid_jack -h

Essid Jack: Proof of concept so people will stop calling an ssid a pass

Usage: ./essid_jack -b [ -d ] [ -c SSH -> Tunnels. 2. Under Add new forwarded port, enter the port number that your computer is going to listen to as the Source port. 3. For the Destination, enter localhost:5777. 4. Make sure the Local button is selected and click the Add button. 5. The newly added port forwarding rule should show up in the Forwarded ports box. If you need to remove the forwarded port, select it and click the Remove button. 6. Save your changes by going back to the Session page and clicking Save. 7. Now we have defined the port forwarding tunnel. To make it active, simply log in to the SSH server. The number of possible examples of SSH port forwarding use is endless and we won't dwell on it any further. Just make sure that you use SSHv2 protocol if you can and your SSH server and clients are up to date and don't have known security

holes (or face the possibility of being r00ted by Trinity in years to come). Be as paranoid as we are. We have mentioned that the default ciphers selection in the Linux/etc/ssh/ssh_config is

#Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cb

We recommend replacing it with the unhashed

Ciphers aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,cast128-cbc, 3des

and adding the following lines to the file:

MACs hmac-ripemd160,hmac-sha1,hmac-md5,hmac-sha1-96,hmac-md5-96 HostKeyAlgorithms ssh-dss,ssh-rsa

The reasons behind such advice are revealed in the next chapter, where practically all of the ciphers involved are discussed and compared in detail. Of course, there will be cryptographers who will find our suggestions subjective, but this is expected. To summarize, SSH port forwarding provides a quick and easy add-on to the traditional weak wireless safeguards such as WEP and MAC filtering. Although for some specific environments this might be sufficient (compare it to the use of protocol filtering, as mentioned in Chapter 8), if you are looking for a more complete wireless security solution above the data link layer, we strongly recommend considering IPSec.

Secure Wireless Network Positioning and VLANs The next point in our security policy checklist is network positioning and separation. If there is a single access point or wireless bridge on the network, its deployment is straightforward: Plug the IP address into the WAN interface of an appropriately configured firewalling device. Such a device can be a sophisticated commercial wireless gateway, a configured common OS-based firewall, or even a SOHO firewall such as Cisco PIX 501 or Nokia SonicWall. However, if multiple access points are deployed and users are allowed to roam freely between these APs, the configuration becomes more complicated. One possibility is to deploy Mobile IP across the corporate network. However, this will make the implementation of Layer 3 and higher VPNs a significant problem. Solutions for this problem do exist, but certain levels of security are likely be sacrificed to provide seamless client roaming. Recall the Wavesec case and kraker_jack attack. A more common and sensible solution is to place all access points on the same broadcast domain using VLANs. To implement this solution, corporate network switches have to support at least static VLAN configuration. Thus, the wireless network design should be an initial part of the overall network design; otherwise, significant additional resources might have to be spent on getting VLAN-enabled switches at the stage of WLAN deployment. We can't describe detailed VLAN setup technicalities in this chapter because the commands will differ depending on your switch manufacturer. However, we do provide you with examples considering VLAN deployment and secure wireless network positioning and deployment using various Cisco equipment. This is a matter of personal experience and we are not affiliated with Cisco in any way.

Using Cisco Catalyst Switches and Aironet Access Points to Optimize Secure Wireless Network Design An interesting proprietary VLAN enhancement feature is the private VLANs supported by Cisco Catalyst 6000 switches. Imagine that you have wireless cells A, B, C, and D on the same VLAN, but want to restrict roaming between the cells so that users can roam either A and B or C and D only and can access the wired LAN only if associated with cell A. This way you can segment the WLAN between the company departments and different physical locations without introducing additional VLANs and routers and making the Layer 3 logical network structure more complicated. All these wonderful things are possible with private VLANs, which allow Layer 2 restriction placement: VLANs within VLANs. There are three kinds of private VLAN ports:

Promiscuous ports that communicate with all other private VLAN ports. These ports are usually used to connect to the gateway or router. Isolated ports that can communicate with only the promiscuous port. Community ports that can communicate with ports in the same community and the promiscuous port. Not surprisingly, there are three types of private VLANs. Primary VLANs carry data from promiscuous ports to isolated, community, and other promiscuous ports. Isolated VLANs carry data from isolated to promiscuous ports. Finally, community VLANs carry traffic between single community ports and promiscuous ports.

In addition to the security provided by private VLAN segmentation, there is also the option to write VLAN access control lists (VACLs) mapped separately to primary or secondary VLANs. You don't need a router to implement VACLs; having a Policy Feature Card (PFC) for your Catalyst will suffice. To learn more about private VLANs and VACL configuration on Cisco 6000 Catalyst switches, browse to http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note0918 and http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_g Interestingly, ARP entries learned on Layer 3 private VLAN interfaces are "sticky ARP" entries that do not expire and cannot be altered. Imagine an AP plugged into the switch port on a private VLAN that connects to the gateway via the promiscuous port. An attacker manages to associate with the WLAN and launches an ARP spoofing attack against the gateway. With a sticky ARP in use, the CAM table would not be modified by such an attack and a log message would be generated. Note that to avoid using Mobile IP and provide roaming, we intentionally make an awful security-wise wireless network deployment mistake. We plug the access point into a switch, not a secure wireless gateway or at least a decent router with firewal capability. The sticky ARP partially corrects this issue by preventing both ARP-based man-in-the-middle and CAM table overflow attacks. However, this feature is limited to a particular switch brand on the expensive side. On other switches you have to configure MAC filtering and port security, which means hard-coding the MAC addresses and limiting the number of hosts allowed to connect on a port. Note that switch port security and MAC filtering and access point MAC address filtering are similar, but not the same. Both switch and AP MAC address filtering can be bypassed by knocking a legitimate wireless host offline and assuming its MAC address. However, switch port security provides an additional layer of defense by protecting against spoofed MAC address ARP floods.

We like Cisco Catalyst switches because they are very hackable (in the sense of "configurable"), so we give you an example of switch port security configuration using Catalysts. On the IOS-style command-line interface (CLI) switches such as Catalyst 1900, use permanent MAC entries to build a switch CAM table:

abrvalk(config)#mac-address-table permanent 0040.1337.1337 ethernet 0/4

Enter all addresses you need​let's say 20. Then bind the amount of allowed connections to the number of permanent MACs and define the action taken if that number is exceeded:

abrvalk(config)#port security action trap abrvalk(config)#port security max-mac-count 20 abrvalk(config)#address-violation suspend

With such a configuration the port would be suspended when receiving an illicit MAC address frame and re-enabled when a valid MAC address frame is received. An SNMP trap reporting the violation would be sent. Of course, an attacker can cause a DoS attack by constantly flooding the port by random MAC addresses, but being temporarily disconnected is better than letting the crackers in, and the flashing alarms will be triggered. The number of MAC addresses you can enter per port on IOS-style CLI Catalyst switches is 132. On the Set/Clear CLI switches such as Catalyst 5000, use the set port security command:

eblec>(enable)set port security 2/1 enable eblec>(enable)set port security 2/1 enable

0040.1337.1337

Enter all 20 MAC addresses you want to allow and fix that number with

eblec>(enable)set port security 2/1 maximum 20

Define the security violation action:

eblec>(enable)set port security 2/1 violation restrict

This command tells the switch to drop the packets coming from illicit MAC address hosts but the port will remain enabled. Thus, a MAC address flood DoS attack against such switches is impossible, if properly configured. Check the port security configuration and statistics with

eblec>(enable)show port security 2/1

The amount of static ("secure" in a "ciscospeak") CAM table entries on Set/Clear CLI Cisco switches is 1,024 plus one additional secure MAC address per port. This pool of static MACs is shared between all switch ports, so if there are 1,024 static MAC entries on a single port, the rest of the ports will have to use a single static MAC entry. If there are 512 entries, the rest of the ports must share the remaining 512 plus static MACs. Another interesting aspect of using Cisco equipment for both VLAN configuration and wireless networking is per-VLAN WEP or TKIP deployment on Cisco access points. That's right, you can set different WEP or TKIP keys and define different TKIP broadcast key rotation intervals for different VLANs. For example, to set a 128-bit WEP key on a Cisco Aironet 1200 access point to be used on VLAN 13 only, enter

aironet#configure terminal aironet(config)#configure interface dot11radio 0 aironet(config-if)#encryption vlan 13 mode cipher wep128 aironet(config-ssid)#end

By splitting the wireless network onto different VLANs and assigning multiple WEP keys, you can decrease the amount of traffic encrypted by a single WEP key, making WEP cracking more difficult. However, we strongly recommend using TKIP instead. The following example configures a Cisco Aironet 1200 access point to use the WPA TKIP protocol described later in this chapter and rotate the broadcast key every 150 seconds on VLAN 13 only:

aironet#configure terminal aironet(config)#configure interface dot11radio 0 aironet(config-if)#encryption vlan 13 mode cipher tkip aironet(config-if)#broadcast-key vlan 13 change 150

aironet(config-ssid)#end

The opportunity to have various keys on wireless VLANs and change them at different intervals provides better VLAN separation and segmentation and gives additional flexibility to the security-minded wireless network designer.

Deploying a Linux-Based, Custom-Built Hardened Wireless Gateway Next we have to ensure the security of the gateway that separates our AP or bridge or wireless-connected VLAN from the wired side. As was already mentioned, such gateways are nothing more (or less) than a flexible stateful or proxy firewall that treats the interface connected to the WLAN side as an interface connecting the LAN to an insecure public network. The only specific requirement for the gateway is a capability to forward VPN traffic if VPN is implemented on the WLAN. Alternatively, the gateway can be a VPN concentrator if you want to cut spending on network security (usually not a good idea). If the VPN lies on the transport layer (e.g., cIPe), forwarding the traffic is straightforward: Open the ports used by the VPN protocol and let it go. Forwarding IPSec traffic is trickier. You have to allow protocols 50 or 51 through as well as have the UDP 500 port open for the IKE exchange. An example from the Linux Netfilter script allowing IPSec traffic through is shown here:

iptables -A INPUT -i $EXT -p 50 -j ACCEPT iptables -A INPUT -i $EXT -p 51 -j ACCEPT iptables -A INPUT -i $EXT -p udp --sport 500 --dport 500 -j ACCEPT

A good idea is to set static ARP table entries for all access points and critical servers connected to the gateway. Place the following lines into your /etc/rc.local if applicable:

arp -s arp -s

.............................................. arp -s arp -s arp -s

You can also use the gateway as a DHCP server. Edit the /etc/dhcpcd.conf file to contain something like this:

# dhcpd.conf # # Configuration file for ISC dhcpd (see 'man dhcpd.conf') #

deny unknown-clients; one-lease-per-client true; authoritative; default-lease-time 604800; max-lease-time 604800;

option subnet-mask 255.255.255.192; option domain-name "domain.name";

subnet 192.168.1.0 netmask 255.255.255.192 { option broadcast-address 192.168.1.63; option routers 192.168.1.2; option domain-name-servers 192.168.1.2, 192.168.1.3; option smtp-server 192.168.1.2; option pop-server 192.168.1.2; option netbios-name-servers 192.168.1.3;

#Sales Department laptops

host toad1 { hardware ethernet ; fixed-address 192.168.1.1; option

host toad2 { hardware ethernet ; fixed-address 192.168.1.2; option

host toad3 { hardware ethernet ; fixed-address 192.168.1.3; option

host toad4 { hardware ethernet ; fixed-address 192.168.1.10; optio

#Accounting Department laptops

host gebril1 { hardware ethernet ; fixed-address 192.168.1.11; opt "gebril1"; }

host gebril2 { hardware ethernet ; fixed-address 192.168.1.12; opt

"gebril2"; }

#Brokering Department laptops

host tsetse1 { hardware ethernet ; fixed-address 192.168.1.15; opt "tsetse1"; }

host tsetse2 { hardware ethernet ; fixed-address 192.168.1.16; opt "tsetse2"; }

host tsetse3 { hardware ethernet ; fixed-address 192.168.1.17; opt "tsetse"; }

In this example the IP addresses are assigned on the MAC address basis so that the attacker will have to spoof the MAC address of a legal host to obtain an IP address from the DHCP server. This might confuse a low-level attacker for a while: The server is there, DHCP traffic is flowing, but no IP address is assigned. What if the access point, gateway, firewall, authentication server, and VPN concentrator are combined on a single machine? Under Linux it is possible. It is also possible to use a BSD platform to create such a host, but writing about anything we don't have hands-on experience with is not the path we follow. Setting a secure access point using HostAP is far more of a real network hacking challenge than setting a rogue AP on a Linux laptop, as described in Chapter 8. The reason for this is that there are many advanced HostAP features that are usually unnecessary when setting up a basic rogue AP but that come in very handy when deploying a proper AP. Such capabilities include the following: MAC filtering Closed ESSIDs (yes, it's possible with HostAP) 802.1x authentication support Wireless distribution system (WDS)

You can even plug more PCI or PCMCIA cards into a custom-built universal wireless gateway and run them using the same HostAP driver to provide access on three different channels for round-robin load balancing using Netfilter. Alternatively, one of the plugged cards can be put into the monitoring mode and used to run a network monitoring or IDS tool (see the Chapter 15 for more details). In this chapter we do not discuss WDS deployment and other HostAP features not directly relevant to security. Playing with these settings is great hacking fun, though. Just check how many private wireless extensions can be supported by your card firmware and what configuration feats can be performed with prism2_param and hostapd. The discussion of authentication mechanisms and VPN implementations on a Linux wireless gateway belongs in Chapters 13 and 14. Here we concentrate on AP security and the capabilities of our custom-built wireless gateways. To enable your wireless gateway access point startup, add the AP parameters to the appropriate startup file. As an example, on Debian we'll use /etc/network/interfaces and add something like this:

auto wlan0 iface wlan0 inet static address 0.0.0.0 up /sbin/iwconfig wlan0 essid Arh0nt-X /sbin/iwconfig wlan0 channel 11 /sbin/iwconfig wlan0 mode Master auto eth0 iface eth0 inet static address 0.0.0.0 auto br0 iface br0 inet static

address 192.168.1.1 network 192.168.1.0 netmask 255.255.255.0 broadcast 192.168.1.255 bridge_ports wlan0 eth0 up

Because it's Linux, there are always multiple ways to do it (e.g., see Bruce Potter's and Bob Fleck's "802.11 Security" for a different approach). Pick the one you like the most. MAC filtering with HostAP is done using its private wireless extensions:

iwpriv wlan0 maccmd 0: open policy for ACL (default) 1: allow policy for ACL 2: deny policy for ACL 3: flush MAC access control list 4: kick all authenticated stations

iwpriv wlan0 addmac add mac addr into access control list

iwpriv wlan0 delmac

remove mac addr from access control list

iwpriv wlan0 kickmac kick authenticated station from AP

To create an ACL use iwpriv wlan0 maccmd . The README suggests keeping two ACLs: one for accepted and one for explicitly denied MAC addresses. This could be a good idea. Alternatively, you can always use the Netfilter for MAC filtering:

$IPTABLES -N macfilter

$IPTABLES -A macfilter -i $WLAN_INTERFACE -m mac -mac-source de:ad:be:e $IPTABLES -A macfilter -i ! $WLAN_INTERFACE -j ACCEPT $IPTABLES -A macfilter -j LOG $IPTABLES -A macfilter -j DROP $IPTABLES -A FORWARD -j macfilter

However, we recommend HostAP filtering: It's very straightforward to use and you can kick out suspicious authenticated hosts with ease. To improve your custom-built AP security, use the prism2_param wlan0 enh_sec 3 command to employ hidden ESSID and ignore probe requests with the ANY ESSID. The AP Prism chipset card must have the latest STA firmware to support the enh_sec extension. Check which wireless extensions your current firmware supports by running the iwpriv wlan0 command and verify the firmware version with prism_diag wlan0. Look for the output line saying "(station firmware)." To

update the firmware, you must have HostAP compiled with the PRISM2_DOWNLOAD_SUPPORT function. This can be done by directly modifying the driver/modules/hostap_config.h header file or compiling HostAP with make pci || pccard EXTRA_CFLAGS="-DPRISM2_DOWNLOAD_ SUPPORT". Do make install, run depmod -a, and use the prism2_srec utility to update your firmware:

arhontus:# ./prism2_srec Usage: prism2_srec [-vvrfd] Options: -v

verbose (add another for more verbosity)

-r

download SREC file into RAM (volatile)

-f

download SREC file into flash (non-volatile)

-d

dump SREC image into prism2_srec.dump

-i

ignore incompatible interfaces errors Warning! This can result in failed upgrade!

The -r and -f options cannot be used together. If -r or -f is not specified, image summary is shown and compatibility with the WLAN card is verified without downloading anything. Check that the -f option is supported properly with your HostAP utilities version; otherwise, it will be necessary to do the firmware update with -r each time the card is reset. You can get the newer STA firmware hex images from http://www.intersil.com/design/prism/ss/p2smtrx.asp or http://www.netgate.com/support/prism_firmware/. Then run

prism2_srec -f wlan0 /path/to/firmware/

and check if the update is successful with prism2_diag wlan0. To enable 802.1x support, the Authenticator functionality in the hostapd daemon has to be employed. The Authenticator in hostapd relays the frames between the supplicant and the authentication server, which has to be RADIUS only. To use the authenticator, compile the HostAP driver with make pci || pccard EXTRA_CFLAGS="-DPRISM2_HOSTAPD" or edit driver/modules/hostap_config.h before the compilation. An external RADIUS server is configured with

arhontus:/#prism2_param wlan0 ieee_802_1x 1 arhontus:/#hostapd -x -o -a AP-auth.serv.> wlan0

The authenticator in hostapd can automatically select a random default and broadcast WEP key shared by all authenticated stations. The selection is done with -b5 (64-bit WEP) or -b13 (128-bit WEP) flags passed to hostapd. In addition, the -i5 or -i13 option can be used to set individual unicast keys for stations. This demands individual key support in the station driver. Set the individual keys using the hostap_crypt_conf utility:

arhontus:# ./hostap_crypt_conf

Usage: hostap_crypt_conf [-123456789tpl] [addr] [alg] [key] Options: -1 .. -9

key index (for WEP); only one index per command

-t

set TX key index (given with -1 .. -9)

-p

permanent station configuration (do not expire data)

-l

list configured keys (do not use addr or alg)

device

wlan#

addr

station hwaddr or ff:ff:ff:ff:ff:ff for default/broadcast

alg

crypt algorithm (WEP, NULL, none)

key

key data (in hex, e.g. '0011223344', or s:string)

Algorithms: WEP

40 or 104 bit WEP

NULL

NULL encryption (i.e., do not encrypt/decrypt); used to configure no encryption for given station when using default encryption

none

disable encryption

Although you can also set HostAP client WEP keys using iwconfig, you won't be able to configure the individual keys for hostapd unicast key support using this command. Setting a perfect access point using HostAP and ensuring that this AP supports all the features just described is not an easy task. However, it is a great way to learn

about wireless and can save your business or wireless community a lot of money. Just check out how much a commercial wireless gateway supporting all capabilities a Linux-based custom-built gateway or AP can possess would cost. You will be surprised. Do not forget that the majority of high-end commercial wireless gateways do not have AP functionality and you will have to buy extra access points to build your network. The major disadvantage of the "all-in-one" solution is a single point of failure. Thus, we suggest you unload some functions on a second machine. In particular, this applies to the RADIUS authentication server. The wireless gateway should have the minimal number of ports opened to the wireless side. Regarding the security of the gateway itself, we recommend the following hardening measures: Enable access to the gateway to administrators only. Remove unnecessary user accounts. Do not run the X Window server. Close all unnecessary ports. Firewall the SSH administrative access from the wireless side. Remove GCC and other compilers from the gateway. Remove interpreted languages such as Perl. Apply the OpenWall or Grsecurity security patch to the kernel. Configure and run the StJude kernel module. Use logrotate and send logs to the remote syslog server via TCP using syslogng. Install, configure, and run Snort. For the truly paranoid, there is always LIDS and security-enchanced Linux distributions such as National Security Agency (NSA) SELinux or Immunix. A properly configured and looked-after Linux machine is as secure as can be; do not blame the system when the real flaw is the system administrator's laziness and ignorance.

Proprietary Improvements to WEP and WEP Usage The final parts of the chapter before we move forward into discussing applied cryptography and implementing secure authentication and VPNs on wireless networks is devoted to the proprietary and standards-based improvements for currently vulnerable 802.11 safeguards. The most publicized 802.11 vulnerability is the insecurity of WEP. We have already reviewed the cryptographic weaknesses of WEP linked to the key IV space reuse and insecure key-from-string generation algorithm. There are also wellknown WEP key management issues: All symmetric cipher implementations suffer secure key distribution problems. WEP is no exception. In the original design, WEP was supposed to defend small, single-cell LANs. Wireless networks of the 21st century often involve thousands of mobile hosts, making manual distribution and change of WEP keys a nightmare. The WEP key supplies device and not user-based authentication. If a cracker steals or finds a lost device, he or she steals access to the WLAN this device is configured to connect to. All hosts on the LAN have the same WEP key. Sniffing WLAN is as easy as sniffing shared Ethernet, and other devastating attacks can be launched, as demonstrated in Chapter 9. Remember that internal malcontents among employees present even more of a threat than external attackers. Users on the wireless network who share the same WEP key belong to the same data domain, even if the wireless network is split into different broadcast domains. All the internal attacker who knows WEP needs to do to snoop on traffic belonging to different WLAN subnets is to put his or her card into the promiscuous mode. Both cryptographic and key management issues were addressed (or, at least, attempted to be addressed) by the IEEE standards committee and various WLAN equipment and software vendors. The first response by many vendors was increasing the standard implemented WEP key length to 128 bits (so-called WEP2) or higher. As you should already know, such an approach will not help against anything but simple brute-forcing unless the IV space is increased. The first real fixes for the WEP insecurities were probably the RSA propositions considering use of per-packet keying and elimination of the first keystream bytes. These suggestions are briefly reviewed in Chapter 11. It appears that the

Agere/Proxim WEPPlus has implemented the elimination of first keystream bytes or a similar solution with the release of the eigth version of the Agere/Proxim WLAN card firmware. We have tested WEPPlus against AirSnort using the AP 2000 Orinoco access point and Orinoco Gold 802.11a/b ComboCards (Figure 10-2), which used WEPPlus, and we can confirm that in a three-day traffic dumping session we didn't discover a single interesting IV frame. Of course, if some of the clients on the WLAN do not implement WEPPlus, the whole purpose of the countermeasure will be defeated because a fallback to the standard WEP will occur.

Figure 10.2. Proxim gear used.

Cisco SAFE blueprints implement key rotation policies that can be centrally configured at the Windows-based access control server or UNIX-based access registar. Of course, modern Cisco SAFE is fully WPA-compliant, but here we refer to the initial and still widely used Cisco Centralized Key Management (CCKM). CCKM ensures that the WEP key change occurs transparently for end users. With CCKM, it is possible to configure key rotation policies at the Cisco Aironet access points and use recording, auditing, and even charging for WLAN usage employing RADIUS accounting records. CCKM is set on a per-SSID basis and requires configured EAP-based authentication on the network. A CCKM-enabled access point on your WLAN acts as a wireless domain service (WDM) and maintains a

cache of security credentials for all CCKM client devices on the subnet. Cisco has also developed its own improvements to WEP and basic WEP integrity check. These improvements include Cisco Key Integrity Protocol (CKIP) and Cisco Message Integrity Check (CMIC), which are based on the early developments of the 802.11 task group "i." They can be enabled on Cisco Aironet access points using encryption mode cipher ckip, encryption mode cipher cmic, and encryption mode cipher ckip-cmic commands on a per-VLAN basis. Thus, even the pre-WPA Cisco SAFE blueprints provide a sufficient level of 802.11 security to rely on. Of course, they still suffer from the same problem as any other proprietary security solution: You must have a uniformed Cisco Aironet WLAN. With public wireless access spots or conference WLANs, this is not possible.

802.11i Wireless Security Standard and WPA: The New Hope Thus, the main hope of the international 802.11 community and network administrators lies with the 802.11i standard development. Sometimes 802.11i is referred to as the Robust Security Network (RSN) as compared to traditional security network (TSN). The "i" IEEE task group was supposed to produce a new wireless security standard that should have completely replaced legacy WEP by the end of 2003. In the meantime, some bits and pieces of the incoming 802.11i standard have been implemented by wireless equipment and software vendors to alleviate known 802.11 vulnerabilities before 802.11i is out. Wireless Protected Access (WPA) Certification promoted by the Wi-Fi Alliance (http://www.wifialliance.org/OpenSection/Protected_Access.asp) is a subset of the current 802.11i draft and is technically very similar to the current 802.11i advancements. Some of the 802.11i developments not included in the current WPA specification include secure ad-hoc networking, secure fast handoff, secure deauthentication and deassociation, and to use of the AES encryption algorithm. As the 802.11i standard gets released, WPA will be upgraded to WPA2, implementing the final 802.11i security features. Due to the space limitations and structure of this book, we cannot completely cover all peculiarities of the 802.11i standard in this chapter. Please bear in mind that many components integrated into the standard are described elsewhere in the book. For example, we have already outlined some attacks against 802.11ienabled networks. AES cipher, CCM mode, TKIP key mixing, and MIC one-way hash are covered in Chapters 11 and 12, and the practical aspects of 802.1x use are walked through when we deal with user authentication on WLANs. The best literature source on the 802.11i standard and the WPA at the moment of writing is Real 802.11 Security: Wi-Fi Protected Access and 802.11i by Jon Edney and William A. Arbaugh (Addison-Wesley, 2004, ISBN: 0321136209). We suggest consulting it if you have a deep interest in 802.11i development and standardization. 802.11i architecture can be divided into two "layers": encryption protocols enhancements and 802.11x port-based access control protocol.

Introducing the Sentinel: 802.1x The 802.1x standard (http://standards.ieee.org/getieee802/download/802.1X2001.pdf) was initially designed to provide Layer 2 user authentication on switched wired networks. We have already mentioned the honorable Cisco Catalyst 6000 switches in this chapter; the ability to configure 802.1x support on a Catalyst 6000 is one of the requirements of the CCIE Security exam. As stated, this discussion of the 802.1x standard is introductory: A more detailed description

of 802.1x, including packet structure, handshaking procedure, and practical implementation examples, follows in Chapter 13, which is entirely devoted to authentication. On WLANs, 802.1x has the additional functionality of dynamic key distribution. Such functionality is supplied by the generation of two key sets. The first set is session or pairwise keys that are unique for each association between a client host and the access point. Session keys provide for the privacy of the link and remove the "one WEP for all" problem. The second set is group or groupwise keys. Groupwise keys are shared among all hosts in a single 802.11 cell and are used for multicast traffic encryption. Both session and pairwise keys are 128 bits in length. Pairwise keys are derived from the 256-bit-long pairwise master key (PMK). The PMK is distributed from the RADIUS server to each participating device using the RADIUS MS-MPPE-Recv-key attribute (vendor_id=17). In a similar manner, groupwise keys are derived from the groupwise master key (GMK). When deriving these keys, the PMK or GMK is used in conjunction with four EAPOL handshake keys, also referred to as the pairwise transient key. To find out more about the pairwise transient key and 802.1x keying in general, check out the EAP Keying Framework IETF draft (http://www.ietf.org/internetdrafts/draft-aboba-pppext-key-problem-06.txt). In SOHO environments or home networks the deployment of a RADIUS server with an end-user database is an unlikely event. Thus, only the preshared (manually entered) PMK is used to generate the session keys. This is similar to the original WEP use. Because there are no physical ports on 802.11 LANs, the association between the wireless client device and the access point is considered to be a network access port. The wireless client is designated as the supplicant (peer) and the AP as the authenticator. Thus, in 802.1x standard definitions, the access point takes the position of an Ethernet switch on the wired LANs. Obviously, there is a need for an authentication server on the wired network segment to which an access point is connected. Such functionality is commonly delivered by a RADIUS server integrated with some form of user database, including native RADIUS, LDAP, NDS, or Windows Active Directory. High-end commercial wireless gateways can implement both authentication server and authenticator functionalities. The same applies to custom-built Linux gateways, which can support 802.1x with HostAP as described and have RADIUS server installed. 802.1x user authentication is provided by Layer 2 Extensible Authentication Protocol (EAP; RFC 2284,) developed by the Internet Engineering Task Force (IETF). EAP is an advanced replacement for CHAP used by PPP, developed to run over LANs. EAP over LAN (EAPOL) defines how EAP frames are encapsulated within 802.3, 802.5, and 802.10 frames. EAP frame exchange between the 802.1x entities is briefly summarized in Figure 10-3.

Figure 10.3. EAP frame exchange.

There are multiple EAP types designed with the participation of various vendor companies. This diversity adds to 802.1x implementations' compatibility problems and makes the selection of appropriate equipment and software for your WLAN a more difficult task. The EAP types you are likely to encounter when configuring user authentication for your wireless network include the following: EAP-MD5 is the mandatory baseline level of EAP support by the 802.1x standard and the first EAP type to be developed. In terms of its operation, EAP-MD5 duplicates CHAP. We do not recommend using EAP-MD5 for three reasons. First of all, it does not support dynamic WEP key distribution. It is also vulnerable to the man-in-the-middle rogue AP or authentication server attack described in Chapter 8 because only the clients are authenticated. Besides, during the authentication process the attacker can sniff out both the challenge and the encrypted response and launch a known plaintext or ciphertext attack (see Chapter 8). EAP-TLS (Transport Layer Security, experimental RFC 2716) supplies mutual certificate-based authentication. EAP-TLS is based of the SSLv3 protocol and requires a deployed certificate authority. Because EAP-TLS is the most commonly supported and deployed EAP method, a detailed discussion on practical implementation of EAP-TLS is presented in Chapter 13. EAP-LEAP (Lightweight EAP or EAP-Cisco Wireless) is a Cisco Systems proprietary EAP type, implemented of Cisco Aironet access points and wireless clients. A full EAP-LEAP method description was posted to http://lists.cistron.nl/pipermail/cistron-radius/2001-September/002042.html and remains the best source on LEAP functionality and operations. LEAP was the first (and for a long time the only) 802.1x password-based authentication scheme. As such, LEAP gained tremendous popularity and is even supported by Free-RADIUS despite being a proprietary Cisco solution. LEAP is based on a

straightforward challenge-password hash exchange. The authentication server sends a challenge to the client, which has to return the password after first hashing it with the challenge string issued by the authentication server. Being a password-based authentication method, EAP-LEAP has the strength of user and not device-based authentication. At the same time, the vulnerability to dictionary and brute-forcing attacks absent in the certificate-based EAP methods becomes apparent. Very detailed information on hands-on configuration of EAP-LEAP is provided by Cisco at http://www.cisco.com/warp/public/707/accessregistrar_leap.html. Less commonly implemented types of EAP include PEAP (Protected EAP, an IETF draft standard) and EAP-TTLS (Tunneled Transport Layer Security EAP, developed by Certicom and Funk Software). That situation might soon change, because these EAP methods are both powerful and have strong support from the manufacturers, such as Microsoft and Cisco. EAP-TTLS requires only an authentication server certificate, so the need for the supplicant certificate is eliminated and deployment becomes more straightforward. EAP-TTLS supports a variety of legacy authentication methods, including PAP, CHAP, MS-CHAP, MS-CHAPv2, and even EAP-MD5. To use these methods securely, EAP-TTLS builds an encrypted TLS tunnel, inside of which the less secure legacy authentication protocol runs. An example of practical EAP-TTLS implementation is the Odyssey WLAN access control software solution from Funk Software (Windows XP/2000/98/Me). EAP-PEAP is very similar to EAP-TTLS, although it does not support legacy authentication methods like PAP and CHAP. Instead it supports PEAP-MS-CHAPv2 and PEAP-EAP-TLS inside the secure tunnel created in a similar manner to the EAP-TTLS tunnel. EAP-PEAP support is implemented by the Cisco Wireless Security Suite and incorporated into the Cisco Aironet Client Utility (ACU) and Windows XP Service Pack 1. It is actively promoted by Cisco, Microsoft, and RSA Security. Two other EAP types are EAP-SIM and EAP-AKA for SIM and USIM-based authentication. Both are IETF drafts at the moment and are not reviewed here because they are mainly used for authentication on GSM, but not 802.11 wireless networks. Nevertheless, EAP-SIM is supported by Cisco Aironet access points and client devices.

Patching the Major Hole: TKIP and CCMP The second layer of 802.11i defense is cryptographic improvements of the original WEP that should finally result in a complete WEP replacement. Temporal Key Integrity Protocol (TKIP) and Counter Mode with CBC-MAC Protocol (CCMP) are the new 802.11i encryption implementations, designed to eliminate the flawed

WEP from 802.11 LANs. TKIP is an upgrade to WEP, which is supposed to address all known WEP vulnerabilities. Current WPA cryptographic security is based on TKIP use. TKIP employs 48-bit IVs to avoid the IV reuse exploited by the FMS attack. The estimated weak IV frames appearance interval with TKIP is about a century, so by the time a cracker collects the necessary 3,000 or more interesting IV frames, he or she would be 300,000 years old. Unfortunately, what is easy in theory can be hard to implement in practice. Legacy hardware that still dominates the market won't go away in a week and cannot understand 48-bit IVs. To bypass this problem, 48-bit TKIP IV is split into 16-bit and 32-bit parts. The 16-bit part is padded to 24 bits to produce a traditional IV. The padding is done in a way that avoids the possibility of weak IV generation. Interestingly, the 32-bit part is not used for the transmitted IV generation; instead, it is utilized in the TKIP per-packet key mixing. TKIP performs per-packet key mixing of the IVs to introduce additional key confusion (see Chapter 11 for an explanation of the term). The per-packet key generation process consists of two phases and utilizes several inputs, such as the transmitting device MAC address, the 32 bits of the IV already mentioned, the first 16 bits of the IV, and the temporal session key. The first phase involves mixing the temporal session key, 32 IV bits, and the transmitter's MAC. In the second phase the output of the first phase is mixed with the temporal session key and 16 bits of the IV. Phase 1 eliminates the use of the same key by all connections, and the second phase reduces the correlation between the IV and per-packet key. Note that the key mixing results in different keys for each direction of communications over each link. Because the per-packet key mixing function is basically a tiny but complete Feistel cipher, its operation is reviewed in Chapter 11 after all necessary terminology is introduced. Another novel implementation of the IV in TKIP is using it as a sequence counter. Recall that there are replay attack tools that use traffic reinjection to accelerate WEP cracking or even portscan wireless hosts (reinj, WEPWedgie). There is nothing in the traditional WEP to stop these attacks from succeeding, as there is no standard defining how the IVs should be selected. In the majority of cases this selection is (pseudo?) random. On the contrary, the TKIP IV is incremented sequentially with all out-of-sequence IV packets discarded. This mitigates the replay attacks but introduces a problem with some quality of service enchancements introduced by IEEE 802.11 task group "e." In particular, ACKing every received frame as defined by the original CSMA/CA algorithm is inefficient. Thus, an improvement called burst-ACK was proposed. In accordance with this improvement, not every single frame, but a series of 16 frames is ACKed. If one of the frames out of the 16 sent didn't reach the destination, selective ACKing (similar to the selective ACK in TCP options) is applied to retransmit the lost frame and not all 16 in a row. Of course, a TKIP sequence counter would reject the retransmitted frame if frames with higher IV numbers were already received.

To avoid such inconvenience, TKIP employs a replay window that keeps track of the last 16 IV values received and checks if the duplicate frame fits into these values. If it does and it wasn't received already, it is accepted. TKIP also provides a message integrity code (MIC or Michael) checksum instead of the basic and insecure WEP integrity check vector (ICV) computation. The complete description of MIC follows in the one-way hashes part in Chapter 11: Introducing you to the foundations of applied cryptography is necessary before discussing the structure of this particular hash. TKIP is not mandatory for the planned final 802.11i standard, but it is backward compatible with old WEP and does not require wireless hardware upgrades. On the contrary, CCMP will be compulsory when 802.11i eventually is implemented. CCMP employs the Advanced Encryption Standard (AES (Rijndael)) cipher in a counter mode with cipher block chaining and message authenticating code (CBC-MAC) implementation. The counter mode (CCM) was created for use in 802.11i but later submitted to NIST for general use of the AES cipher. The AES key size defined by the 802.11i standard is 128 bits, and we wonder why the 256bit key was not chosen instead. In a way similar to TKIP, CCMP employs a 48-bit IV (called a packet number or PN) and a variation of MIC. The use of the strong AES cipher makes creating per-packet keys unnecessary, thus CCMP does not implement per-packet key derivation functions. CCMP uses the same perassociation key for both data encryption and checksum generation. The 8-octet message integrity checksum provided by CCMP is considered to be much stronger than TKIP's Michael. Because the separate chip hardware implementation of AES is planned to reduce the burden of encryption on 802.11, network speed, and throughput, a complete 802.11 hardware overhaul is expected when CCMP-supporting products hit the market. Besides, there are still some issues not covered by the 802.11i standard at present. These issues include securing ad-hoc networks, fast handoff, and deauthentication and deassociation processes. Thus, the practical widespread implementation of 802.11i is not going to be an easy task, and WEP (hopefully, in the improved form of TKIP) will be with us for a long time. This might prompt wireless network managers to search for reliable, version and vendor independent security solutions on the OSI layers above the data link layer.

Summary A reasonable 802.11 defense level is possible, but it won't be achieved with a few mouse clicks. Wireless security is a complex process that starts with developing a sound security policy and most likely never ends. Do not underestimate the importance of Layer 1 security. Position your access points behind a hardened gateway, and get the best you can out of the simple defensive methodologies such as MAC address and protocol filtering. Remember that you don't have to buy expensive, high-end wireless gateways to stay secure; a Linux or BSD box and a bit of tweaking is all you need to deploy a reasonably secure and cheap gateway or AP for your WLAN. Finally, the 802.11i standard is getting close to its release date and will alleviate many wireless security-related headaches. We do not expect that 802.11i and the second version of WPA will be perfect and spread overnight; the improved data confidentiality and integrity brought by the new standard will also force the attackers to search for pre-802.11i networks. This, in turn, would be a good stimulus to upgrade to 802.11i-compatible hardware, firmware, and software. In the next chapter, we introduce the subject of applied cryptography, which is essential for understanding how AES, MIC, CCM, TKIP perpacket key mixing, and RC4 used by the 802.11i standard work and why they were selected. We hope that many terminology-related questions you might have had while reading the previous chapters are answered in the next one. Besides, you will learn about the ciphers and principles you need to know to deploy wireless VPNs and strong authentication means efficiently and with minimal impact on your network performance.

Chapter 11. Introduction to Applied Cryptography: Symmetric Ciphers $$%$##%$C$#&00#C$#$$$$%%F01%9##3$$$%$$$01FE3E1%0 ​Karamazoff bro Cryptography underlies network security, yet many system administrators and IT security consultants know little about its inner workings, strength and efficiency of various ciphers available, and optimal conditions for their implementation. Almost all publications on cryptography are split into two large categories: Those that explain the mathematical side of cryptography in great detail and are difficult to digest for a system administrator or IT consultant. Those that try to explain cryptography without a single formula and simply feed the ideas resulting from the mathematical machinery at work without an explanation and are oversimplified. The next two chapters are an attempt to bridge this gap. Besides, we hope that it makes interesting bedtime reading for experts on the networking and system administration side and IT consultants. Furthermore, this is probably the only publication on cryptography that does not mention Bob and Alice (apart from this very sentence). What a relief!

Introduction to Applied Cryptography and Steganography One can set up a reasonably secure wireless or wired network without knowing which ciphers are used and how the passwords are encrypted. This, however, is not an approach endorsed by us and discussed here. Hacking is about understanding, not blindly following instructions; pressing the buttons without knowing what goes on behind the scenes is a path that leads nowhere. Besides, security and quality of service are tightly interwoven, and as you will see later in this chapter, incorrect selection of the cipher and its implementation method can lead to a secure but sluggish and inefficient network. Although the achieved security enhancements are unlikely to be mentioned by the network users, low throughput and high delay would surely get reported to the IT team and, possibly, to management. Before getting down to ciphers, modes, and protocols, let's get some definitions right. Cryptography defines the art and science of transforming data into a sequence of bits that appears as random and meaningless to a side observer or attacker. The redundancy of data is also removed by compression data. However, whereas compressed data is easy to decompress, decrypting data requires a key that was used to bring the "randomness" to the plaintext. On a side track, because both encryption and compression increase the entropy of data compressed, encrypted data might actually expand in size after the compression, which makes compression unfeasible. If you have to implement both encryption and compression of data, apply the compression first. Cryptanalysis is the reverse engineering of cryptography​attempts to identify weaknesses of various cryptographic algorithms and their implementations to exploit them. Any attempt at cryptanalysis is defined as an attack. Exhaustive key search (or brute-forcing) is not a form of cryptanalysis, but it is still an attack! Cryptology encompasses both cryptography and cryptanalysis and looks at mathematical problems that underlie them. Encrypting data provides data confidentiality, authentication, data integrity, and nonrepudiation services. Data availability could be affected by incorrect implementations of cryptographic services, for example when bandwidth consumption and packet delay are above the acceptable limit due to improperly implemented cryptographic solutions. Also, for local DoS attacks, preceding authentication is necessary. Many sources that claim that cryptography does not affect the availability part of the "CISSP triad" (confidentiality, integrity, availability) are therefore incorrect. Additionally, encrypted viruses that decrypt themselves to self-activate are common, as well as backdoors that use encrypted channels of communication with crackers (most of the latest distributed DoS tools

do). These are the examples of Black Hat cryptography implementations. At the same time, secure authentication of access to antiviral software and encryption of virus signature databases can protect the antivirus software from tampering by both malware and malicious users. Thus, sources indicating that encryption has nothing to do with malware protection aren't exactly right either. The first ciphers, in use were simple substitution and transposition algorithms. Imagine that you have a pack of cards. Changing the position of cards in the pack in a predetermined way known to you but not others (one of the ways to cheat!) rather than just shuffling them would be an example of a transposition cipher. The cards remain the same, but their order is changed. Having an agreement that a king is really a jack, a 6 is an ace, or diamonds are now spades and vice versa are examples of substitution ciphers. Textbook examples of substitution ciphers are shift ciphers in which the data is shifted to the side by a predefined number of positions. For example, a Caesar's cipher involves assigning a number to every letter and then shifting the position of each letter by a predefined number k (in Caesar's case, k = 3). Thus, A becomes D, B becomes E, and so on. A variety of Caesar's cipher called ROT13 is still used by some software and involves a shift by 13 characters: P = ROT13 (ROT13 (P)), so encrypting text with ROT13 twice gives you the original text. The substitution and shift ciphers are easy to break. For example, if the opponent wanted to break Caesar's cipher, he or she could choose a single encrypted word from a long text, give it to 22 soldiers (because there are 23 letters in the Latin alphabet), and ask the first soldier to shift all letters in the word by one position, the second soldier by two positions, and so forth, obtaining the value of k in no time. In the current case, the k value is the key, and a very weak key indeed: one integer with modulo 23 = less than 5 bits of data in all possible combinations! To break more sophisticated substitution ciphers with seemingly random agreement on which letter substitutes for another, as well as the transposition ciphers, statistical cryptanalysis is used. Every language has a defined frequency distribution of used letters, and by analyzing this distribution in a ciphertext, a machine can easily deduce the plaintext, and finally a key. In a nutshell, the most abundant letter in the English alphabet is e, so the most common letter or symbol in the English plaintext-derived ciphertext must be e, and so on. Substituting digrams or trigrams (two- and three-letter sequences) was tried to bypass statistical analysis and failed; now the frequencies of digrams and trigrams for various languages are documented. In the case of encrypted source code, frequencies of various operators and statements from different programming languages are documented and used in conjunction with spoken language statistical analysis. For example, in C we would expect a high frequency of #define and #include occurrences in the beginning of the source code. Encrypted binaries have similar problems, making them vulnerable to statistical cryptanalysis: functions, loop structures, and so on. Regarding the encrypted traffic on the network collected by tcpdump or some other (tcpdump-based or

ridiculously expensive) network analyzer, should we mention the similarities and repetitiveness of fields in frames, packets, segments, and datagrams? We do know their precise length and where exactly these fields are. In attempts to create a cipher superior to substitution and transposition algorithms, various approaches have been tried. One working approach was concealment ciphers​security through obscurity that actually works. Historical tricks included invisible inks, grilles covering some characters but not others, and so on. More recently, spread spectrum military radio technology, now actively used by various 802.11 LANs and Bluetooth, came as an example of concealment security​weak wideband radio signals that appear to be nothing but noise for a casual radio frequency scanner. Unfortunately or not, due to the compatibility and usefulness issues, this security through obscurity does not work in our WLAN case. Besides, an attacker with a decent (expensive) spectrum analyzer can still detect and dissect spread spectrum signals. See http://www.tscm.com/spectan.html for some examples of spread spectrum bugs signal detection and analysis. Steganography is another new player in the concealment field. It is based on replacing the least significant bit in image, music, or video files with the concealed message data, using tools such as Steghide (http://steghide.sourceforge.net; see also http://www.outguess.org/detection.php for the opposite). Mimic functions are another form of steganography, an offspring of the "hardware" grilles mentioned earlier. These functions modify the message so that it appears to be something else, usually casual and inconspicuous. An example of something very casual and inconspicuous (if annoying!) constantly flowing through the Internet is SPAM. You can check http://www.spammimic.com or download a Perl script the site uses to hide the messages under the disguise of junk mail from http://packetstormsecurity.org/UNIX/misc/mimic.zip. Another example, somewhat close to steganography, is hiding suspicious traffic in data streams that do not usually raise network administrators' suspicions. A variety of backdoors use inconspicuous ICMP packets (e.g., echo reply) or IGMP traffic to hide a communication channel with the backdoor (e.g., http://packetstormsecurity.org/UNIX/penetration/rootkits/icmp-backdoor.tar.gz or http://packetstormsecurity.org/UNIX/penetration/rootkits/sneaky-sneaky1.12.tar.gz). We have already mentioned using such backdoors to mask a wireless attacker behind a legitimate host in Chapter 8. Interestingly, similar covert channels can be employed to transmit highly confidential data over an insecure physical medium (wireless) as part of an advanced defense-in-depth strategy. Running key ciphers involves a sequence of physical actions to obtain the key. For example, an agreed-on message might say bk10.3L.15.36.9, which states "The key is in a book on shelf 10, 3 books to the left, page 15, 36th line, 9th word." You open the book and the word is, of course, "Microsoft" (no pun intended!). Although running key ciphers can be reasonably secure, they aren't really

applicable in network and host security. Finally, there is a perfect encryption scheme that cannot be broken, no matter how much processing power is at the attacker's disposal. Ironically, this scheme is of very little use for IT security, just like running key ciphers. You probably gathered that we are talking about one-time pads. A one-time pad is a large matrix of truly random data. Originally it was a one-time tape for teletype transmission. Each pad is XORed with plaintext to encrypt it and is used only once on both communication ends. Irrecoverable destruction of the pad follows use. Such a data transmission scheme is perfectly secure from the cryptanalysis viewpoint, providing the entropy source for the pad is truly random. However, secure pad distribution and storage and sender​receiver synchronization prove a tremendously difficult task. Because the superpowers usually have sufficient resources to accomplish such a task, one-time pads were employed to secure the hotline between the Cold War giants and were frequently used by spies on both sides of the Iron Curtain. A Russian submarine radio operator in the movie K-19 Widowmaker appears to use a one-time pad to encrypt his message before the radio transmission takes place. Looking back at the options just presented, we are left with two choices. One choice is continuing to fortify substitution and transposition ciphers until their cryptanalysis becomes computationally unfeasible. Another choice is to come up with novel encryption schemes different from classical methodologies described (we discuss this more when we come to asymmetric ciphers). Yet another choice is steganography. This chapter does not dwell on steganography because it is not widely used to secure wireless networks. However, stegtunnel from SYN ACK Labs (http://www.synacklabs.net/projects/stegtunnel/) is an interesting free tool one can employ for wireless traffic protection. If you have a particular interest in this subject, we suggest checking out a variety of online sources, such as http://www.cl.cam.ac.uk/~fapp2/steganography/ or http://www.jjtc.com/Steganography/, as well as books currently on the market (Information Hiding: Steganography and Watermarking​Attacks and Countermeasures by Johnson, Duric & Amp, 2000, Cluwer Academic Publishers, ISBN: 0792372042; Disappearing Cryptography: Information Hiding: Steganography; Watermarking by Wayner, 2002, Morgan Kaufmann, ISBN: 1558607692; and Information Hiding: Techniques for Steganography; Digital Watermarking by Katzenbeisser, 2000, Artech House Books, ISBN: 1580530354). Now it is time to return to the substitution and transposition ciphers we started with. Before dealing with the modern-day substitution and transposition cipher offspring, there is a common misconception to deal with first. This misconception is that you have to be a brilliant mathematician to understand cryptography. As far as our experience goes, understanding what a function is, and understanding binary arithmetic, matrices, modular arithmetic, and Boolean logic operators, will

get you by without significant problems. Some revision of the latter is, perhaps, a good idea. We find truth tables to be particularly good for Boolean logic memory refreshment:

NOT. NOT (!= in C) truth table is:

INPUT

OUTPUT

1

1

OR ( || in C, as in {if ((x>0) || (x0) && (x the data block is split on the "right" and "left" sides, 32 bits each. The initial permutation is followed by 16 rounds of substitution and transposition. If we define the cipher function as f, key scheduling function as Ks, and subkeys generated by Ks as Ki, the 16 rounds can be described as follows:

xi = Li Ri ;

Li = Ri

- 1

;

Ri = Li ^= f (Ri-1, Ki) while i =< 16

This means that as the data goes through these rounds, the right side of data passes the cipher function and the left side is XORed with the function output on the right to give new function input on the right. The process then repeats itself until i reaches 16. What happens inside of the f (Ri-1, Ki) box? First of all, we mentioned that only 48 bits of key space is eventually used. In practical terms it means Ki = 48 bits. However, the data block size after the IP(x) is 32 bits. Thus, the first step in a round is an expansion permutation E(Ri), which expands the right side of the data from 32 to 48 bits (apparently, it is the reason why the right side of data passes the cipher function). How does one magically turn 32 bits into 48?

Split 32 bits of data into 4-bit input blocks. Then shift the data in input blocks so that the last bit of each 4-bit block becomes the first bit of the next output block and the first bit of each input block becomes the last bit of the last output block. Thus, using this shift, each input block donates 2 additional bits to each output block. Providing that the original 4 bits in every input block is passed into a corresponding output block, we get 8 x 6-bit output blocks out of 8 x 4-bit input blocks. Problem solved! Even more, the expansion permutation exhibits a very effective cryptographic property called the avalanche effect. Because the expansion permutation presence efficiently generates more ciphertext output from less plaintext input, small differences in plaintext produce vastly different blocks of ciphertext. Once we get our 48 blocks, we can XOR them with the subkeys: E(Ri) ^= Ki. However, the round does not end with this XORing. Remember that we have to get 64 bits of encrypted data from 64 bits of plaintext at the end, so we need to get back to two 32-bit blocks of data, essentially reversing the expansion permutation function after it did its job. This is accomplished by splitting 48-bit blocks of data into 8 x 6-bit blocks and feeding them into so-called S-boxes, which produce 4-bit output from each 6-bit data block. In the S-box, the first and last bits of the 6 bits supplied form a binary number to select a row. The inner 4 bits are used to select a column. Thus, an S-box is simply a table with 4 rows and 16 columns. Four inner bits form a number positioned in the table and selected via row determined by 2 "external" bits and column determined by 4 "internal" bits. Thus, 2 outer bits are cut away (but participate in the 4 inner bits selection) and the remaining 4-bit numbers are reshuffled in a predetermined matter. The function of the S-box is the most nonlinear event in the whole process of DES iteration and is responsible for the lion's share of DES security. Total memory requirement for all eight S-boxes used is 256 bytes. The 4-bit output from each S-box is concatenated back into 32 bits of data before putting these 32-bit blocks through another permutation. This time the permutation is defined as "straight"; no bits are "reused" to expand the data and no bits are ignored. Basically, 32 bits of data is fed into a P-box with 2 rows and 32 columns, and numbers between rows exchange places. Did you already forget that everything we just discussed applies only to the right side of the initial 64-bit block? After the P-box spits out 32 bits of data, they are XORed with the left 32-bit half of the initial input. Then both halves switch places and the next round can begin. Following Round 16, the left and right halves are not exchanged. Instead they are concatenated and fed into the final permutation, which exchanges halves and concatenates them together in a way opposite to the initial permutation IP.

The last thing to consider inside of the function box is K => Ki​in other words, where the subkeys come from. First, the 8 parity bits are subtracted and the remaining 56 bits are split in half. This split is similar to IP(x) and is referred to as fixed permutation PC1(K) = C0D0. Afterward, the halves are circularly (modulo 28) shifted by either 1 or 2 bits depending on a round number: Ci = LSi (Ci-1) ; Di = LSi (Di-1). Between Rounds 3 and 8 and 10 and 15, 2-bit left shifts are done, otherwise it is a 1-bit shift. After the shift, Ciand Di are concatenated, and we are left with 56 bits of key data that must be XORed with 48 bits of data produced by the expansion permutation on the right side. Thus, we need a compression permutation function PC-2 for the keying material to match the corresponding (permutated) "plaintext": Ki = PC-2 (CiDi). PC-2 does not use any specific algorithm to shift the positions of bits or drop some bits to get 48-bit output. Instead it uses a predefined table with numbers of bit positions. Bits are assigned their new positions in accordance with their position in the table. For example, position one from the beginning of the PC-2 table is 14, so the 14th bit is assigned the first position in PC-2 output. The table for PC-2 is widely published in the literature (see p. 274 in Schneier's Applied Cryptography). As a result of PC-2 we get a 48-bit Ki ready for XORing. Because of the rounddependent left shifts, different parts of the initial key material are used to create each subkey. This is the element of confusion at work. The images of cipher structures from John Savard's home page cryptography section (http://home.ecn.ab.ca/~jsavard/crypto/entry.htm) are so wonderful that we could not resist borrowing them for this chapter. Sometimes, a picture can be worth a thousand lines of code! Figure 11-1 summarizes all we went through, with the left scheme representing the whole iteration of DES and the right scheme representing a single round.

Figure 11.1. DES structure and operation.

[View full size image]

Kerckhoff's Rule and Cipher Secrecy You might have wondered, if DES is a U.S. government standard, why were its inner workings given away to the general public? The answer is this: Keeping the cipher closed from scrutiny does no good for the cipher, its developers, and its users. As early as 1883, Jean Guillaumen Hubert Victor Fransois Alexandre Auguste Kerckhoff von Nieuwenhof (yes, some people have rather long names) wrote that the key used and the cipher's function must be two separate entities and cryptosystems should rely on secrecy of keys, but not algorithms. Some 111 years later, a proprietary secret algorithm, RC4, was published on the Internet by an unknown hacker who posted its source code to the Cypherpunks mailing list. Opening the RC4 structure quickly led to the development of several attacks on the cipher (however, these attacks aren't related to the weakness of WEP, which uses RC4). Whereas the developers of RC4, RSA Data Security, Inc., are wellreputed cryptographers who created a variety of strong product ciphers, many small companies that claim to develop highly efficient and secure secret encryption algorithms often do not offer anything more than a variety of ROT13 with a single "round" of XORing. It appears that open sourcing ciphers, just like open sourcing software, has advantages when it comes to security, public scrutiny being one of them.

Another advantage of DES openness is that now you have learned about S-boxes, subkeys, expansion, and compression, and straight permutations, using a classical and still practical (considering the use of 3DES and still running legacy cryptographics software and hardware) example. Now it is much easier to explain how post-DES ciphers work, not to mention saving a lot of space and our time.

The 802.11i Primer: A Cipher to Help Another Cipher As a very relevant example, the per-packet key mixing function in TKIP is a small Feistel cipher on its own, developed by Doug Whiting and Ronald Rivest. The purpose of this function is producing a per-packet key from a temporal key and the IV or TKIP sequence counter (TSC). This per-packet key then serves as a secure WEP seed, eliminating the risk of an FMS-style attack. Such a WEP seed can be computed before it is used, which positively affects the network performance. Let's walk through the per-packet key mixing function in detail, as defined by the 802.11i standard drafts available at the time of writing. As mentioned in the previous chapter, there are two phases of per-packet key mixing function operation. However, both Phase 1 and Phase 2 of per-packet key generation rely on the S-box that substitutes one 16-bit value with another 16-bit value. The substitution function is nonlinear and is implemented as a table lookup. The table lookup can be implemented as a single large table with 65,536 entries and a 16bit index (128 KB of table) or two different tables with 256 entries and an 8-bit index (1024 bytes for both tables). When the two smaller tables are chosen, the high-order byte is used to obtain a 16-bit value from one table and the low-order byte is used to obtain a 16-bit value using the other table. The S-box output in this case would be the XOR of the two 16-bit values selected. The inputs taken by the first phase are 80 bits of the 128-bit temporal session key (TK), the transmitter MAC address (TA), and the 32 bits of the IV = TSC. Its output (TTAK) is also 80 bits in length and constitutes an array of five 16-bit TTAK0, TTAK1, TTAK2, TTAK3, and TTAK4 values. The description of the Phase 1 algorithm treats these values as 8-bit arrays: TA0..TA5 and TK6..TK12. XOR, ADD, and bitwise AND operations are used in the Phase 1 computation. A loop counter i and an array index temporary variable j are also employed and a single function called Mk16 is applied in the process. The function Mk16 produces a 16-bit value from two given 8-bit inputs: Mk16(X,Y) = 256*X+Y. The Phase 1 algorithm consists of two steps. The first step does an initialization of TTAK from both IV and MAC address, but without the temporary key. The second step employs the S-box we outlined earlier to mix the keying material into the 80-bit TTAK and sets the PHASE1_LOOP_COUNT value to 8:

Input: transmit address TA0...TA5, temporal key TK0..TK12, and TSC0..TS Output: intermediate key TTAK0..TTAK4

PHASE1-KEY-MIXING(TA0...TA5, TK0..TK12, TSC0..TSC2)

PHASE1_STEP1: TTAK0 13 dBm dBm

SMA 13 dBm

None

12​15 dBm 13​20 dBm (50 mW max)

Reverse SMA

Compaq

PCMCIA

None

Compaq

PCI

Reverse threaded SMA

20 mW typ. / 100 mW max 20 dBm

max CellVision

Demarc

PCMCIA

Diversity RP-MMCX

100 -91 mW dB or 20 dBm

​91 dB

Demarc

PCMCIA

Diversity RP-MMCX

D-Link

PCI

Reverse SMA

D-Link

PCMCIA

Yes, with nice switch

D-Link

PCMCIA

200 mW or 23 dBm

Hackable

​78 14 or or 17 ​84 dBm dBm

Lid snaps off/has socket

​80 14 or to 18 ​88 dBm dBm

D-Link

Compact Flash

Linksys

PCMCIA

Linksys

PCI

RP-SMA

Musenki

PCI

Reverse SMC

​87 18 dBm dBm

14 dBm 16 dBm

Musenki

PCMCIA

Dual MMCX

23 ​89 dBm dBm (200 mW)

Proxim

PCMCIA

Dual reverse MMCX

​83 13 dBm dBm

Proxim

PCMCIA

Single unknown connector (SSMB?)

​83 13 dBm dBm

Dual (RP?)-MMCX

200 mW ​89 max dBm (23 dBm)

SMC

PCMCIA

SMC

PCMCIA

Hackable

50 ​76 mW dBm max (17 dBm)

SMC

PCI

Unknown but strange solder pads on PCI card

50 mW ​76 max dBm (17 dBm)

Teletronics

PCMCIA

Dual reverse MMCX

​83 15 dBm dBm

Zcomax

PCMCIA

Dual reverse MMCX

​83 13 dBm dBm

Zcomax

PCMCIA

None

​83 13 dBm dBm

Zcomax

PCMCIA

Dual MMCX (probably reverse)

Zcomax

PCMCIA

Dual reverse MMCX

​85 15 dBm dBm

Zcomax

PCMCIA

Dual reverse MMCX

​83 100 dBm mW

Zcomax

PCMCIA

Dual reverse MMCX

180 mW

ZoomAir

PCMCIA

RP-SMA

14 dBm

Appendix C. Antenna Irradiation Patterns

Omni-Directionals: Figure C.1. Horizontal pattern: 360° beamwidth.

Figure C.2. Vertical pattern: 7​80° beamwidth.

Semi-Directionals: Figure C.3. Sectored/Panel-horizontal pattern: 30​180° beamwidth.

Figure C.4. Sectored/Panel vertical pattern: 6​90° beamwidth.

Figure C.5. Yagi horizontal patter: 30​70° beamwidth.

Figure C.6. Yagi vertical pattern: 15​65° beamwidth.

Highly-directionals Figure C.7. Horizontal pattern: 5​25° beamwidth.

Figure C.8. Vertical pattern: 5​20° beamwidth.

Appendix D. Wireless Utilities Manpages

1 Iwconfig Name: iwconfig Configure a wireless network interface. Synopsis:

iwconfig [interface] iwconfig interface [essid X] [nwid N] [freq F] [channel C] [sens S] [mode M] [ap A] [nick NN] [rate R] [rts RT] [frag FT] [txpower T] [enc E] [key K] [power P] [retry R] [commit] iwconfig --help iwconfig --version

Description: Iwconfig is similar to ifconfig(8), but is dedicated to the wireless interfaces. It is used to set the parameters of the network interface that are specific to the wireless operation (for example, the frequency). Iwconfig may also be used to display those parameters, and the wireless statistics (extracted from /proc/net/wireless). All these parameters and statistics are device dependent. Each driver will provide only some of them depending on the hardware support, and the range of value may change. Please refer to the man page of each device for details.

Parameters essid

Set the ESSID (or Network Name​in some products it may also be called Domain ID). The ESSID is used to identify cells that are part of the same virtual network. As opposed to the NWID, which defines a single cell, the ESSID defines a group of cells connected via repeaters or infrastructure, where the user may roam. With some cards, you may disable the ESSID checking (ESSID promiscuous) with off or any (and on to reenable it). Examples:

iwconfig eth0 essid any iwconfig eth0 essid "My Network"

nwid/domain Set the Network ID (in some products it is also called Domain ID). As all adjacent wireless networks share the same medium, this parameter is used to differentiate them (create logical colocated networks) and identify nodes belonging to the same cell. With some cards, you may disable the Network ID checking (NWID promiscuous) with off (and on to reenable it). Examples:

iwconfig eth0 nwid AB34 iwconfig eth0 nwid off

freq/channel Set the operating frequency or channel in the device. Values below 1000 are the

channel number, values over this are the frequency in Hz. You must append the suffix k, M, or G to the value (for example, "2.46G" for 2.46 GHz frequency), or add enough '0'. Channels are usually numbered starting at 1, and you may use iwpriv(8) to get the total number of channels and list the available frequencies. Depending on regulations, some frequencies/channels may not be available. Examples:

iwconfig eth0 freq 2.422G iwconfig eth0 channel 3

sens Set the sensitivity threshold. This is the lowest signal level for which we attempt a packet reception; signals lower than this are not received. This is used to avoid receiving background noise, so you should set it according to the average noise level. Positive values are assumed to be the raw value used by the hardware or a percentage; negative values are assumed to be dBm. With some hardware, this parameter also controls the defer threshold (lowest signal level for which we consider the channel busy) and the handover threshold (lowest signal level where we stay associated with the current access point). Example:

iwconfig eth0 sens -80

mode

Set the operating mode of the device, which depends on the network topology. The mode can be Ad-hoc (network composed of only one cell and without Access Point), Managed (node connects to a network composed of many Access Points, with roaming), Master (the node is the synchronization master or acts as an Access Point), Repeater (the node forwards packets between other wireless nodes), Secondary (the node acts as a backup master/repeater), Monitor (the node acts as a passive monitor and only receives packets), or Auto. Examples:

iwconfig eth0 mode Managed iwconfig eth0 mode Ad-Hoc

ap Force the card to register to the Access Point given by the address, if it is possible. When the quality of the connection goes too low, the driver may revert back to automatic mode (the card finds the best Access Point in range). You may also use off to reenable automatic mode without changing the current Access Point, or you may use any or auto to force the card to reassociate with the current best Access Point. Examples:

iwconfig eth0 ap 00:60:1D:01:23:45 iwconfig eth0 ap any iwconfig eth0 ap off

nick[name] Set the nickname, or the station name. Most 802.11 products do define it, but this is not used as far as the protocols (MAC, IP, TCP) are concerned and is completely an accessory as far as configuration goes. In fact only some diagnostic tools may use it. Example:

iwconfig eth0 nickname "My Linux Node"

rate/bit[rate] For cards supporting multiple bit rates, set the bit-rate in b/s. The bit-rate is the speed at which bits are transmitted over the medium. The user speed of the link is lower due to medium sharing and overhead. You must append the suffix k, M, or G to the value (decimal multiplier : 10^3, 10^6 and 10^9 b/s), or add enough '0'. Values below 1000 are card specific, usually an index in the bit-rate list. Use auto to select the automatic bit-rate mode (fallback to lower rate on noisy channels), which is the default for most cards, and fixed to revert back to fixed setting. If you specify a bit-rate value and append auto, the driver will use all bits lower than and equal to this value. Examples:

iwconfig eth0 rate 11M iwconfig eth0 rate auto

iwconfig eth0 rate 5.5M auto

rts[_threshold] RTS/CTS adds a handshake before each packet transmission to make sure that the channel is clear. This adds overhead, but increases performance in case of hidden nodes or large number of active nodes. This parameter sets the size of the smallest packet for which the node sends RTS, a value equal to the maximum packet size disables the scheme. You may also set this parameter to auto, fixed, or off. Examples:

iwconfig eth0 rts 250 iwconfig eth0 rts off

frag[mentation_threshold] Fragmentation splits an IP packet in a burst of smaller fragments transmitted on the medium. In most cases this adds overhead, but in very noisy environments this reduces the error penalty. This parameter sets the maximum fragment size. A value equal to the maximum packet size disables the scheme. You may also set this parameter to auto, fixed, or off. Examples:

iwconfig eth0 frag 512

iwconfig eth0 frag off

key/enc[ryption] Used to manipulate encryption or scrambling keys and encryption mode. To set the current encryption key, just enter the key in hex digits as XXXX-XXXX-XXXXXXXX or XXXXXXXX. To set a key other than the current key, prepend or append [index] to the key itself (this won't change which is the active key). You can also enter the key as an ASCII string by using the s: prefix. Passphrase is currently not supported. To change which key is the current active key, just enter [index] (without entering any key value). Off and on disable and reenable encryption, open sets the system in open mode (accept nonencrypted packets), and restricted discards nonencrypted packets. If you need to set multiple keys, or set a key and change the active key, you need to use multiple key directives. Arguments can be put in any order; the last one will take precedence. Examples:

iwconfig eth0 key 0123-4567-89 iwconfig eth0 key s:password [2] iwconfig eth0 key [2] open iwconfig eth0 key off iwconfig eth0 key restricted [3] 0123456789 iwconfig eth0 key 01-23 key 45-67 [4] key [4]

power Used to manipulate power management scheme parameters and mode. To set the

period between wake up, enter period 'value'. To set the timeout before going back to sleep, enter timeout 'value'. You can also add the min and max modifiers. By defaults, those values are in seconds. Append the suffix m or u to specify values in milliseconds or microseconds. Sometimes, those values are without units (number of dwell or the like). Off and on disable and reenable power management. Finally, you may set the power management mode to all (receive all packets), unicast (receive unicast packets only, discard multicast and broadcast), and multicast (receive multicast and broadcast only, discard unicast packets). Examples:

iwconfig eth0 power period 2 iwconfig eth0 power 500m unicast iwconfig eth0 power timeout 300u all iwconfig eth0 power off iwconfig eth0 power min period 2 power max period 4

txpower For cards supporting multiple transmit powers, set the transmit power in dBm. If W is the power in Watts, the power in dBm is P = 30 + 10.log(W). If the value is postfixed by mW, it will be automatically converted to dBm. In addition, on and off enable and disable the radio, and auto and fixed enable and disable power control (if those features are available). Examples:

iwconfig eth0 txpower 15

iwconfig eth0 txpower 30mW iwconfig eth0 txpower auto iwconfig eth0 txpower off

retry Most cards have MAC retransmissions, and some allow you to set the behavior of the retry mechanism. To set the maximum number of retries, enter limit 'value'. This is an absolute value (without unit). To set the maximum length of time the MAC should retry, enter lifetime 'value'. By default, this value is in seconds. Append the suffix m or u to specify values in milliseconds or microseconds. You can also add the min and max modifiers. If the card supports automatic mode, they define the bounds of the limit or lifetime. Some other cards define different values depending on packet size, for example in 802.11 min limit is the short retry limit (non-RTS/CTS packets). Examples:

iwconfig eth0 retry 16 iwconfig eth0 retry lifetime 300m iwconfig eth0 retry min limit 8

commit Some cards may not apply changes done through Wireless Extensions immediately (they may wait to aggregate the changes or apply them only when the card is brought up via ifconfig). This command (when available) forces the

card to apply all pending changes. This is normally not needed, because the card will eventually apply the changes, but can be useful for debugging.

Display For each device that supports wireless extensions, iwconfig will display the name of the MAC protocol used (name of device for proprietary protocols), the ESSID (Network Name), the NWID, the frequency (or channel), the sensitivity, the mode of operation, the Access Point address, the bit-rate, the RTS threshold, the fragmentation threshold, the encryption key, and the power management settings (depending on availability). (See preceding for explanations of what these parameters mean.) If the label for bit-rate is followed by '=', it means that the parameter is fixed and forced to that value, if it is followed by ':' it is only the current value (device in normal auto mode). If /proc/net/wireless exists, iwconfig will also display its content: Link quality Quality of the link or the modulation (what is the level of contention or interference, or how good the received signal is). Signal level Received signal strength (how strong the received signal is). Noise level Background noise level (when no packet is transmitted). invalid nwid Number of packets received with a different NWID. Used to detect configuration problems or adjacent network existence. invalid crypt Number of packets that the hardware was unable to decrypt. invalid misc Other packets lost in relation with specific wireless operations. Author: Jean Tourrilhes ([emailprotected]) Files: /proc/net/wireless See also: ifconfig(8), iwspy(8), iwlist(8), iwpriv(8), wavelan(4), wavelan_cs(4), wvlan_cs(4), netwave_cs(4).

2 Iwpriv Name: iwpriv Configure optionals (private) parameters of a wireless network interface. Synopsis:

iwpriv [interface] iwpriv interface private-command [private-parameters] iwpriv interface private-command [I] [private-parameters] iwpriv interface --all iwpriv interface roam {on,off} iwpriv interface port {ad-hoc,managed,N}

Description: Iwpriv is the companion tool to iwconfig(8). Iwpriv deals with parameters and settings specific to each driver (as opposed to iwconfig which deals with generic ones). Without any argument, iwpriv lists the private commands available on each interface, and the parameters that they require. Using this information, the user may apply those interface specific commands on the specified interface. In theory, the documentation of each device driver should indicate how to use those interface-specific commands and their effect.

Parameters private-command [private-parameters] Execute the specified private-command on the interface. The command may optionally take or require arguments, and may display information. Therefore, the command-line parameters may or may not be needed and should match the command expectations. The list of commands that iwpriv displays (when called

without argument) should give you some hints about those parameters. However you should refer to the device driver documentation for information on how to properly use the command and the effect.

private-command [I] [private-parameters] Idem, except that I (an integer) is passed to the command as a Token Index. Only some commands will use the Token Index (most will ignore it), and the driver documentation should tell you when it's needed.

-a/- -all Execute and display all the private commands that don't take any arguments (i.e., read only).

roam Enable or disable roaming, if supported. Call the private command setroam. Found in the wavelan_cs driver.

port Read or configure the port type. Call the private commands gport_type, sport_type, get_port or set_port found in the wave- lan2_cs and wvlan_cs drivers.

Display For each device that supports private commands, iwpriv will display the list of private commands available. This includes the name of the private command, the number or arguments that may be set and their type, and the number or arguments that may be displayed and their type. For example, you might have the following display:

eth0

Available private ioctl: setqualthr (89F0): set

1 byte & get

gethisto (89F7): set

& get 16 int

This indicates that you may set the quality threshold and display a histogram of up to 16 values with the following commands:

iwpriv eth0 setqualthr 20 iwpriv eth0 gethisto

Author: Jean Tourrilhes - [emailprotected] Files: /proc/net/wireless See also: ifconfig(8), iwconfig(8), iwlist(8), iwspy(8), wavelan(4), wavelan_cs(4), wvlan_cs(4), netwave_cs(4).

3 Iwlist Name: iwlist Get wireless statistics from specific nodes Synopsis:

iwlist interface freq iwlist interface ap iwlist interface scan iwlist interface rate iwlist interface key iwlist interface power iwlist interface txpower iwlist interface retry iwlist --help iwlist --version

Description: Iwlist is used to display some large chunk of information from a wireless network interface that is not displayed by iwconfig. This is typically a list of parameters.

Parameters freq/channel

Gives the list of available frequencies in the device and the number of defined channels. Please note that usually the driver returns the total number of channels and only the frequencies available in the present locale, so there is no one-to-one mapping between frequencies displayed and channel numbers.

ap/accesspoint Gives the list of Access Points in range, and optionally the quality of link to them. This feature is obsolete and now deprecated in favor of scanning support (below), and it will disappear in the future.

scan[ning] Gives the list of Access Points and ad-hoc cells in range, and optionally a great deal of information about them (ESSID, quality, frequency, mode, etc.). The type of information returned depends on what the card supports. Triggering scanning is a privileged operation (root only) and normal users can only read leftover scan results. By default, the way scanning is done (the scope of the scan) will be impacted by the current setting of the driver. Also, this command is supposed to take extra arguments to control the scanning behavior, but this is currently not implemented.

rate/bit[rate] Lists the bit-rates supported by the device.

key/enc[ryption] Lists the encryption key sizes supported and displays all the encryption keys available in the device.

power Lists the various Power Management attributes and modes of the device.

txpower Lists the various Transmit Power available on the device.

retry Lists the transmit retry limits and retry lifetime on the device.

- -version Displays the version of the tools, as well as the recommended and current Wireless Extensions version for the tool and the various wireless interfaces. Files: /proc/net/wireless See also: iwconfig(8), ifconfig(8), iwspy(8), iwpriv(8).

4 Wicontrol Name: wicontrol Configure WaveLAN/IEEE devices. Synopsis:

wicontrol -i iface [-o] wicontrol -i iface -t tx_rate wicontrol -i iface -n network_name wicontrol -i iface -s station_name wicontrol -i iface -c 0 | 1 wicontrol -i iface -q SSID wicontrol -i iface -p port_type wicontrol -i iface -a access_point_density wicontrol -i iface -m mac_address wicontrol -i iface -d max_data_length wicontrol -i iface -e 0 | 1 wicontrol -i iface -k key [-v 1 | 2 | 3 | 4] wicontrol -i iface -T 1 | 2 | 3 | 4 wicontrol -i iface -r RTS_threshold wicontrol -i iface -f frequency wicontrol -i iface -P 0 | 1 wicontrol -i iface -S max_sleep_duration

wicontrol -i iface -Z (zero signal cache) wicontrol -i iface -C (display signal cache)

Description: The wicontrol command controls the operation of WaveLAN/IEEE wireless networking devices via the wi(4) driver. Most of the parameters that can be changed relate to the IEEE 802.11 protocol that the WaveLAN implements. This includes the station name, whether the station is operating in ad-hoc (pointto-point) or BSS (service set) mode, and the network name of a service set to join (IBSS) if BSS mode is enabled. The wicontrol command can also be used to view the current settings of these parameters and to dump out the values of the card's statistics counters. The iface argument given to wicontrol should be the logical interface name associated with the WaveLAN/IEEE device (wi0, wi1, etc.). If none is specified then wi0 is used as the default.

Parameters -i iface [-o] Displays the current settings of the specified WaveLAN/IEEE interface. This retrieves the current card settings from the driver and prints them out. Using the additional -o flag will cause wicontrol to print out the statistics counters instead of the card settings. Encryption keys are only displayed if wicontrol is run as root.

-i iface -t tx_rate Sets the transmit rate of the specified interface. The legal values for the transmit rate vary depending on whether the interface is a standard WaveLAN/IEEE or a WaveLAN/IEEE Turbo adapter. The standard NICs support a maximum transmit rate of 2Mbps while the turbo NICs support a maximum speed of 6Mbps. The following list shows the legal transmit rate settings and the corresponding transmit speeds: TX rate

1

NIC speed

Fixed Low (1Mbps)

2

Fixed Standard (2Mbps)

3

Auto Rate Select (High)

4

Fixed Medium (4Mbps)

5

Fixed High (6Mbps)

6

Auto Rate Select (Standard)

7

Auto Rate Select (Medium)

The standard NICs support only settings 1 through 3. Turbo NICs support all the listed speed settings. The default driver setting is 3 (auto rate select).

-i iface -n network_name Sets the name of the service set (IBSS) that this station wishes to join. The network_name can be any text string up to 30 characters in length. The default name is the string ANY, which should allow the station to connect to the first available access point. The interface should be set for BSS mode using the ​p flag for this to work. Note: The WaveLAN manual indicates that an empty string will allow the host to connect to any access point, however I have also seen a reference in another driver that indicates that the ANY string works as well.

-i iface -s station_name Sets the station name for the specified interface. The station_name is used for diagnostic purposes. The Lucent WaveMANAGER software can poll the names of remote hosts.

-i iface -c 0 | 1 Allows the station to create a service set (IBSS). Permitted values are 0 (don't create IBSS) and 1 (enable creation of IBSS). The default is 0.

Note: This option is provided for experimental purposes only: enabling the creation of an IBSS on a host system doesn't appear to actually work.

-i iface -q SSID Specifies the name of an IBSS (SSID) to create on a given interface. The SSID can be any text string up to 30 characters long. Note: This option is provided for experimental purposes only: enabling the creation of an IBSS on a host system doesn't appear to actually work.

-i iface -p port_type Sets the port type for a specified interface. The legal values for port_type are 1 (BSS mode) and 3 (ad-hoc) mode. In ad-hoc mode, the station can communicate directly with any other stations within direct radio range (provided that they are also operating in ad-hoc mode). In BSS mode, hosts must associate with a service set controlled by an access point, which relays traffic between end stations. The default setting is 3 (ad-hoc mode).

-i iface -a access_point_density Specifies the access point density for a given interface. Legal values are 1 (low), 2 (medium), and 3 (high). This setting influences some of the radio modem threshold settings.

-i iface -m mac_address Sets the station address for the specified interface. The mac_address is specified as a series of six hexadecimal values separated by colons (e.g., 00:60:1d:12:34:56). This programs the new address into the card and updates the interface as well.

-i iface -d max_data_length Sets the maximum receive and transmit frame size for a specified interface. The max_data_length can be any number from 350 to 2304. The default is 2304.

-i iface -e 0 | 1 Enables or disables WEP encryption. Permitted values are 0 (encryption disabled) or 1 (encryption enabled). Encryption is off by default.

-i iface -k key [-v 1|2|3|4] Sets WEP encryption keys. There are four default encryption keys that can be programmed. A specific key can be set using the ​v flag. If the -v flag is not specified, the first key will be set. Encryption keys can either be normal text (i.e., hello) or a series of hexadecimal digits (i.e., 0x1234512345). For WaveLAN Turbo Silver cards, the key is restricted to 40 bits, hence the key can be either a 5character text string or 10 hex digits. For WaveLAN Turbo Gold cards, the key can also be 104 bits, which means the key can be specified as either a 13-character text string or 26 hex digits in addition to the formats supported by the Silver cards.

-i iface -T 1 | 2 | 3 | 4 Specifies which of the four WEP encryption keys will be used to encrypt transmitted packets.

-i iface -r RTS_threshold Sets the RTS/CTS threshold for a given interface. This controls the number of bytes used for the RTS/CTS handshake boundary. The RTS_threshold can be any value between 0 and 2347. The default is 2347.

-i iface -f frequency Sets the radio frequency of a given interface. The frequency should be specified as a channel ID as shown in the list below. The list of available frequencies is dependent on radio regulations specified by regional authorities. Recognized regulatory authorities include the FCC (United States), ETSI (Europe), France, and Japan. Frequencies in the table are specified in Mhz. Channel ID FCC

1

2412

ETSI

France

2412

-

Japan

2412

2

2417

2417

-

2417

3

2422

2422

-

2422

4

2427

2427

-

2427

5

2432

2432

-

2432

6

2437

2437

-

2437

7

2442

2442

-

2442

8

2447

2447

-

2447

9

2452

2452

-

2452

10

2457

2457

2457

2457

11

2462

2462

2462

2462

12

-

2467

2467

2467

13

-

2472

2472

2472

14

-

-

-

2484

If an illegal channel is specified, the NIC will revert to its default channel. For NICs sold in the United States and Europe, the default channel is 3. For NICs sold in France, the default channel is 11. For NICs sold in Japan, the default channel is 14, and it is the only available channel for pre-11Mbps NICs. Note that two stations must be set to the same channel to communicate.

-i iface -P 0 | 1 Enables or disables power management on a given interface. Enabling power management uses an alternating sleep/wake protocol to help conserve power on mobile stations, at the cost of some increased receive latency. Power management is off by default. Note that power management requires the cooperation of an access point to function; it is not functional in ad-hoc mode. Also, power management is only implemented in Lucent WavePOINT firmware

version 2.03 or later, and in WaveLAN PCMCIA adapter firmware 2.00 or later. Older revisions will silently ignore the power management setting. Legal values for this parameter are 0 (off) and 1 (on).

-i iface -S max_sleep_interval Specifies the sleep interval to use when power management is enabled. The max_sleep_interval is specified in milliseconds. The default is 100.

-i iface ​Z Clears the signal strength cache maintained internally by the wi(4) driver.

-i iface -C Displays the cached signal strength information maintained by the wi(4) driver. The driver retains information about signal strength and noise level for packets received from different hosts. The signal strength and noise level values are displayed in units of dBms. The signal quality value is produced by subtracting the noise level from the signal strength (i.e., less noise and better signal yields better signal quality). See also: wi(4), ifconfig(8) History: The wicontrol command first appeared in FreeBSD 3.0. Author: Bill Paul ([emailprotected])

5 Ancontrol Name: ancontrol Configure Aironet 4500/4800 devices. Synopsis:

ancontrol -i iface -A ancontrol -i iface -N ancontrol -i iface -S ancontrol -i iface -I ancontrol -i iface -T ancontrol -i iface -C ancontrol -i iface -t 0 | 1 | 2 | 3 | 4 ancontrol -i iface -s 0 | 1 | 2 | 3 ancontrol -i iface [-v 1 | 2 | 3 | 4] -a AP ancontrol -i iface -b beacon_period ancontrol -i iface [-v 0 | 1] -d 0 | 1 | 2 | 3 ancontrol -i iface -e 0 | 1 | 2 | 3 ancontrol -i iface [-v 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7] -k key ancontrol -i iface -K 0 | 1 | 2 ancontrol -i iface -W 0 | 1 | 2 ancontrol -i iface -j netjoin_timeout ancontrol -i iface -l station_name

ancontrol -i iface -m mac_address ancontrol -i iface [-v 1 | 2 | 3] -n SSID ancontrol -i iface -o 0 | 1 ancontrol -i iface -p tx_power ancontrol -i iface -c frequency ancontrol -i iface -f fragmentation_threshold ancontrol -i iface -r RTS_threshold ancontrol -i iface -M 0-15 ancontrol -h

Description: The ancontrol command controls the operation of Aironet wireless networking devices via the an(4) driver. Most of the parameters that can be changed relate to the IEEE 802.11 protocol that the Aironet cards implement. This includes such things as the station name, whether the station is operating in adhoc (point-to-point) or infrastructure mode, and the network name of a service set to join. The ancontrol command can also be used to view the current NIC status, configuration, and to dump out the values of the card's statistics counters. The iface argument given to ancontrol should be the logical interface name associated with the Aironet device (an0, an1, etc.). If one isn't specified the device an0 will be assumed. The ancontrol command is not designed to support the combination of arguments from different SYNOPSIS lines in a single ancontrol invocation, and such combinations are not recommended.

Parameters -i iface -A Displays the preferred access point list. The AP list can be used by stations to specify the MAC address of access points with which it wishes to associate. If no

AP list is specified (the default) then the station will associate with the first access point that it finds that serves the SSID(s) specified in the SSID list. The AP list can be modified with the -a option.

-i iface -N Displays the SSID list. This is a list of service set IDs (i.e., network names) with which the station wishes to associate. There may be up to three SSIDs in the list: The station will go through the list in ascending order and associate with the first matching SSID that it finds.

-i iface -S Displays NIC status information. This includes the current operating status, current BSSID, SSID, channel, beacon period and currently associated access point. The operating mode indicates the state of the NIC, MAC status and receiver status. When the "synced" keyword appears, it means the NIC has successfully associated with an access point, associated with an ad-hoc master station, or become a master itself. The beacon period can be anything between 20 and 976 milliseconds. The default is 100.

-i iface -I Displays NIC capability information. This shows the device type, frequency, speed, and power level capabilities and firmware revision levels.

-i iface -T Displays the NIC's internal statistics counters.

-i iface -C Displays current NIC configuration. This shows the current operation mode, receive mode, MAC address, power save settings, various timing settings, channel selection, diversity, transmit power, and transmit speed.

-i iface -t 0 | 1 | 2 | 3 | 4

Selects transmit speed. The available settings are as follows: TX rate

NIC speed

Auto​NIC selects optimal speed

1

1 Mbps fixed

2

2 Mbps fixed

3

5.5 Mbps fixed

4

11 Mbps fixed

Note that the 5.5 and 11 Mbps settings are only supported on the 4800 series adapters; the 4500 series adapters have a maximum speed of 2 Mbps.

-i iface -s 0 | 1 | 2 | 3 Sets power save mode. Valid selections are as follows: Selection

Power save mode

None; power save disabled

1

Constantly awake mode (CAM)

2

Power Save Polling (PSP)

3

Fast Power Save Polling (PSP-CAM)

Note that for IBSS (ad-hoc) mode, only PSP mode is supported, and only if the ATIM window is nonzero.

-i iface [-v 1 | 2 | 3 | 4] -a AP

Sets preferred access point. The AP is specified as a MAC address consisting of 6 hexadecimal values separated by colons. By default, the -a option only sets the first entry in the AP list. The -v modifier can be used to specify exactly which AP list entry is to be modified. If the -v flag is not used, the first AP list entry will be changed.

-i iface -b beacon_period Set the ad-hoc mode beacon period. The beacon_period is specified in milliseconds. The default is 100 ms.

-i iface [-v 0 | 1] -d 0 | 1 | 2 | 3 Select the antenna diversity. Aironet devices can be configured with up to two antennas, and transmit and receive diversity can be configured accordingly. Valid selections are as follows: Selection

Diversity

Select factory default diversity

1

Antenna 1 only

2

Antenna 2 only

3

Antenna 1 and 2

The receive and transmit diversity can be set independently. The user must specify which diversity setting is to be modified by using the -v option: selection 0 sets the receive diversity and 1 sets the transmit diversity.

-i iface -e 0 | 1 | 2 | 3 Sets the transmit WEP key to use. Note that until this command is issued, the device will use the last key programmed. The transmit key is stored in NVRAM. Currently set transmit key can be checked via -C option.

-i iface [-v 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7] -k key Sets a WEP key. For 40-bit prefix 10 hex character with 0x. For 128-bit prefix 26 hex character with 0x. Use "" as the key to erase the key. Supports 4 keys; even numbers are for permanent keys and odd numbers are for temporary keys. For example, -v 1 sets the first temporary key. (A permanent key is stored in NVRAM; a temporary key is not.) Note that the device will use the most recentlyprogrammed key by default. Currently set keys can be checked via -C option, only the sizes of the keys are returned.

-i iface -K 0 | 1 | 2 Sets authorization type. Use 0 for none, 1 for Open, and 2 for Shared Key.

-i iface -W 0 | 1 | 2 Enables WEP. Use 0 for no WEP, 1 to enable full WEP, and 2 for mixed cell.

-i iface -j netjoin_timeout Sets the ad-hoc network join timeout. When a station is first activated in ad-hoc mode, it will search out a master station with the desired SSID and associate with it. If the station is unable to locate another station with the same SSID after a suitable timeout, it sets itself up as the master so that other stations may associate with it. This timeout defaults to 10000 milliseconds (10 seconds) but may be changed with this option. The timeout should be specified in milliseconds.

-i iface -l station_name Sets the station name used internally by the NIC. The station_name can be any text string up to 16 characters in length. The default name is set by the driver to FreeBSD.

-i iface -m mac_address Sets the station address for the specified interface. The mac_address is specified as a series of six hexadecimal values separated by colons (e.g., 00:60:1d:12:34:56). This programs the new address into the card and updates

the interface as well.

-i iface [-v 1 | 2 | 3] -n SSID Sets the desired SSID (network name). There are three SSIDs, which allows the NIC to work with access points at several locations without needing to be reconfigured. The NIC checks each SSID in sequence when searching for a match. The SSID to be changed can be specified with the -v modifier option. If the -v flag isn't used, the first SSID in the list is set.

-i iface -o 0 | 1 Sets the operating mode of the Aironet interface. Valid selections are 0 for ad-hoc mode and 1 for infrastructure mode. The default driver setting is for infrastructure mode.

-i iface -p tx_power Sets the transmit power level in milliwatts. Valid power settings vary depending on the actual NIC and can be viewed by dumping the device capabilities with the I flag. Typical values are 1, 5, 20, 50, and 100mW. Selecting 0 sets the factory default.

-i iface -c frequency Sets the radio frequency of a given interface. The frequency should be specified as a channel ID as shown in the following list. The list of available frequencies is dependent on radio regulations specified by regional authorities. Recognized regulatory authorities include the FCC (United States), ETSI (Europe), France, and Japan. Frequencies in the table are specified in Mhz. Channel ID

FCC

ETSI

France

Japan

1

2412

2412

-

-

2

2417

2417

-

-

3

2422

2422

-

-

4

2427

2427

-

-

5

2432

2432

-

-

6

2437

2437

-

-

7

2442

2442

-

-

8

2447

2447

-

-

9

2452

2452

-

-

10

2457

2457

2457

-

11

2462

2462

2462

-

12

-

2467

2467

-

13

-

2472

2472

-

14

-

-

-

2484

If an illegal channel is specified, the NIC will revert to its default channel. For NICs sold in the United States and Europe, the default channel is 3. For NICs sold in France, the default channel is 11. For NICs sold in Japan, the only available channel is 14. Note that two stations must be set to the same channel to communicate.

-i iface -f fragmentation_threshold Sets the fragmentation threshold in bytes. This threshold controls the point at which outgoing packets will be split into multiple fragments. If a single fragment is not sent successfully, only that fragment will need to be retransmitted instead of the whole packet. The fragmentation threshold can be anything from 64 to 2312 bytes. The default is 2312.

-i iface -r RTS_threshold Sets the RTS/CTS threshold for a given interface. This controls the number of bytes used for the RTS/CTS handshake boundary. The RTS_threshold can be any

value between 0 and 2312. The default is 2312.

-i iface -M 0-15 Sets monitor mode via bit mask, meaning: Bit

Meaning

To not dump 802.11 packet.

1

To enable 802.11 monitor.

2

To monitor any SSID.

4

To not skip beacons, monitor beacons produces a high system load.

8

To enable full Aironet header returned via BPF. Note it appears that an SSID must be set.

-h Prints a list of available options and sample usage.

Security Notes WEP (wired equivalent privacy) is based on the RC4 algorithm, using a 24-bit initialization vector. RC4 is supposedly vunerable to certain known plaintext attacks, especially with 40-bit keys. So the security of WEP in part depends on how much known plaintext is transmitted. Because of this, although counterintuitive, using shared key authentication (which involves sending known plaintext) is less secure than using open authentication when WEP is enabled. Devices may alternate among all of the configured WEP keys when transmitting

packets. Therefore, all configured keys (up to four) must agree. Examples:

ancontrol -i an0 -v 0 -k 0x12345678901234567890123456 ancontrol -i an0 -K 2 ancontrol -i an0 -W 1 ancontrol -i an0 -e 0

Sets a WEP key 0, enables "Shared Key"' authentication, enables full WEP and uses transmit key 0. See also: an(4), ifconfig(8) History: The ancontrol command first appeared in FreeBSD 4.0. Bugs: The statistics counters do not seem to show the amount of transmit and received frames as increasing. This is likely due to the fact that the an(4) driver uses unmodified packet mode instead of letting the NIC perform 802.11/Ethernet encapsulation itself. Setting the channel does not seem to have any effect. Author: Bill Paul ([emailprotected])

Appendix E. Signal Loss for Obstacle Types Additional Loss (dB)

Effective Range

Open space

100%

Window (nonmetallic tint)

3

70%

Window (metallic tint)

5​8

50%

Light wall (drywall)

5​8

50%

Medium wall (wood)

10

30%

Heavy wall (15 cm solid core)

15​20

15%

Very heavy wall (30 cm solid core)

20​25

10%

Floor/ceiling (solid core)

15​20

15%

Floor/ceiling (heavy solid core)

20​25

10%

Obstruction

Appendix F. Warchalking Signs

Original Signs

Proposed New Signs

Unrestricted access

AP with MAC filtering

Open access with restrictions

Pay for access AP

AP with WEP

AP with multiple access controls (not for public use)

AP with closed ESSID Honeypot

Appendix G. Wireless Penetration Testing Template

Arhont Ltd Wireless Network Security and Stability Audit Checklist Template Date: _____/______/_______ Customer: ___________________

1 Reasons for an audit network design

network operations issues

preventive / hardening

suspected intrusion

2 Preliminary investigations network administrator

______________________________

familiarity with wireless networking

familiarity with wireless security

presence of wireless security policy

presence of overall security policy

wireless network position information found online

security officer or security system administrator present

resource _____________________________

3 Wireless site survey network type

802.11 DSSS

802.11 FHSS

802.11b DSSS

802.11a DSSS

802.11g DSSS

802.15 Bluetooth

802.16 Broadband

HomeRF

Other _________________________

network structure

Infrastructure/ Managed

Independent/ Ad-Hoc

Other _________________________

network topology

point-to-multipoint

Highest Fresnel zone diameter (if applicable)

Estimated power output

Network coverage zone mapping

point-to-point

_______

IR _____

EIRP _____

See the included/ signed map

Point-to-point link distance ___

Antenna types deployed _________________________ Antenna Vertical polarization

SNR / signal strength value

Horizontal

point-to-point bridge

___

typical clients position

___

Peak usage network point-to-point bridge bandwidth

___

typical clients position

___

DSSS network frequencies / channels __________________

Number of access points deployed

__________________

Access points make

__________________

Number of wireless hosts present

__________________

802.11 layer 2 traffic baselining beacons per min

___

probe requests per min

___

probe responses per min

___

deassociate frames per min

___

deauthenticate frames per ___ min

reassociate frames per min

___

authenticate frames per min

___

ATIM frames per min

___

data packets per min (peak)

___

802.11 frame size (bytes)

___

fragments per minute

___

collisions per minute

___

rants per minute

___

giants per minute

___

RTS/CTS present

___

PCF present / superframes

___

IAPP running

___

Network ESSIDs present:

Misc.

ESSID __________________

Channel

__________________

ESSID __________________

Channel

__________________

ESSID __________________

Channel

__________________

Host roaming enabled

Load balancing enabled

4 Network security features present Close ESSIDs

MAC filtering

explicit deny

explicit allow

Protocol filtering

filtered protocols

________________________

WEP key size ___

static or dynamic __

key rotation frequency ___

TKIP implemented __

other WEP enhancements __________________________________

Authentication system

open

mixed

close

802.1x authentication EAP type __________________________ User database type __________________________ 802.1x-based WEP key rotation

ESSID/MAC EAP authentication

Centralized authentication implemented Kerberos v4

RADIUS

Kerberos v5

TACACS

TACACS version ___

Layer 3 VPN implemented

rotation time ________

VPN type and mode ______________________________

key exchange

shared secret

asymmetric crypto

DH asymmetric crypto

X.509 certificates

other

ciphers used

symmetric ___ message digest

___

key/hash size

assymmetric ___ symmetric ___

message digest

___

assymmetric ___

IPSec AH

tunneling implemented

PPTP

IPSec ESP

L2F

L2TP

CIPE

GRE

IP-IP

VTP

DVS

ATMP

Other ___________________

Higher-layer security protocols used

SSHv1

S/MIME

SSHv2

SCP

HTTPS

Other _________________

Wireless authentication gateway

______________________________

gateway type

______________________________

PGP/GNUPG

MINIP-IP

Proper wired/wireless network separation Type of gateway/firewall

______________________________

Gateway malware filtering present

Gateway SPAM filtering present

Access points management from the wireless side is

enabled

restricted

disabled

Connections between wireless peers denied Wireless peers have firewalling capability

Wireless IDS present

IDS type

Remote sensors present

Sensor type ________________

________________

Number of sensors ___

Centralized logging present Logging is done over

Log review frequency

Wired IDS present

Remote sensors present

UDP

TCP

___ IDS _______________ type Sensor _______________ type Number of sensors

Honeypots deployed wireless

wired

___

comments _________________________________________

5 Network problems / anomalies detected excessive collisions

connection loss

common RF issues

near/far problem hidden node

interference

interference type

narrowband

channel overlapping

wideband

interference ______________________________ source abnormal ______________________________ frames excessive number of management / control frames

excessive frame ___ excessive frame structure type

rogue APs

AP1______________________

AP3_______________________

AP2______________________

rogue APs MACs

AP1______________________

AP3_______________________

AP2______________________

rogue APs IPs

AP1______________________

AP3_______________________

AP2______________________

rogue APs channels

AP1______________________

AP3_______________________

AP2______________________

rogue APs ESSIDs

AP1______________________

AP3_______________________

AP2______________________

___

rogue APs location

AP1______________________

AP3_______________________

AP2______________________

rogue AP signal strength

AP1______________________

AP3_______________________

AP2______________________

rogue APs use WEP

AP1______________________

AP3_______________________

AP2______________________

rogue APs WEP keys

AP1______________________

AP3_______________________

AP2______________________

rogue APs origin

intentional

unknown

unintentional

rogue access points have associated hosts

hosts associated (IP/MAC)

___________________________________

___________________________________

___________________________________ other rogue wireless hosts detected

number of hosts ___ MAC1

_________________

IP1

__________________

MAC2

_________________

IP2

__________________

MAC3

_________________

IP3

__________________

physically discovered rogue wireless devices

PCMCIA client c

USB wireless client

CF client c

other

______________________

Known signatures of wireless attack tools (version) Netstumbler ___

Dstumbler ___

Windows XP scan ___

Wellenreiter ___

Airjack ___

Fata_jack ___

FakeAP ___

Other ___

Man-in-the-middle attacks signs (Double MAC / IP addresses) MiM1

_______________________

MiM2

______________________

MiM3

_______________________

MiM4

______________________

Out of sequence frames present (amount/time)

_____/_____

Excessive deassociate frames

deauthenticate frames

time

___

amount ___

channel ___ Exsessive RF noise

strength ___

channel ___ Rogue DHCP servers present

IP

___________________

MAC ____________________

Atypical route advertisem*nt (type/comments)

Type ____________________

Comments _______________

Type __________________

Comments _______________

Wireless DoS attack signs

Management/control frames flood

frame types _______________

origin MAC ________________

frame types _______________

origin MAC ________________

frame types _______________

origin MAC ________________

Out-of-sequence frames

origin MAC __________________________ Excessive RF noise

channel ___

jamming device discovered

___ strength ___

comments ____________________________________ High-layer DoS attack __________________________________ Comments ____________________________________________ High-layer DoS attack __________________________________ Comments ____________________________________________ Attacks against the access point detected _______________________________________ Comments ____________________________________________ brute-forcing attacks

via SNMP ___

via SSH ___ via other means

___ via Web interface ___

Attacks against wireless hosts detected

Comments ____________________________________________ Attacks directed at the wired hosts from the WLAN _____________________________ Comments ____________________________________________

Attacks directed at the hosts on the Internet Comments ____________________________________________

Attempts to send SPAM

via telnet ___

Comments ____________________________________________

6 Wireless penetration testing procedure Maximum network discovery and fingerprinting distance with: Built-in client card antenna ___

12 dBi omnidirectional ___

15 dBi Yagi ___

19 dBi directional ___

ESSID security default

company name

closed

address

other relevant information _____________________________ Bypassing closed ESSID

closed ESSID value _____________________________ Bypassing MAC filtering

success with MAC _____________________________ Cracking WEP keys

key 1 _____________________________

key 2 _____________________________

key 3 _____________________________

key 4 _____________________________ cracking time ___ WEP cracking acceleration

cracking tool ___

time saved ___

traffic injection tool ___ type of traffic injected ___ Brute-forcing 802.1x access

password guessed _____________________________

Other 802.1x attacks

Comments _____________________________

Wireless man-in-the-middle attacks

Tool ________________

layer 1 attack (comments) _____________________________

layer 2 attack (comments) _____________________________ DoS attack resilience / detection (comments) deauthentication flood ______________________________ deassociation flood ______________________________ malformed frames flood ______________________________ excessive beacon flood ______________________________ authentication flood ______________________________ probe requests flood ______________________________ Other attacks ______________________________ Wireless traffic interception / analysis packets per minute ___ plaintext and plaintext authentication protocols detected

POP3

Telnet

SMTP

FTP

IMAP

HTTP

NNTP

Instant messengers

IRC

SQL

PAP

LDAP

Other ______________________________

passwords/user credentials collected username/password ______________________________ username/password ______________________________ username/password ______________________________ username/password ______________________________ weak encryption/vulnerable protocols detected LM/ NTLMv1

SSHv1

Other ______________________________ passwords cracked username/password ______________________________ username/password ______________________________ username/password ______________________________ username/password ______________________________ UNIX remote services

___

type

___

SMB shares on WLAN ______________________________

NFS shares detected ______________________________

DHCP traffic detected ______________________________

HSRP/VRRP traffic detected ______________________________

HSRP password ______________________________

VRRP authentication ______________________________

VRRP password ______________________________

CDP traffic detected ______________________________

CDP data gathered ______________________________

ICMP type 9/10 implementation

RIPv1 running

Unauthenticated routing protocols over wireless network RIPv2

OSPF

IGRP

EIGRP

IS-IS

IPX RIP

NLSP

Other ________________

Unauthenticated NTP traffic

SNMP traffic

SNMP communities found ___

SNMP version ___

NetBIOS over IPX traffic

AppleTalk traffic

DecNet traffic

Banyan Vines traffic

SNA traffic

Other ________________

Remote administration traffic VNC

PCAnywhere

Webmin

Other ________________

Remote X Server cookies

Syslog traffic

over UDP

over TCP

Passive OS fingerprinting _________________________________ Gateway discovery (IP)

_________________________________

IDS host discovery

_________________________________

ARP spoofing man-inthe-middle attack

_________________________________

Switch CAM table flooding

_________________________________

Route injection attacks

_________________________________

ICMP route redirection

_________________________________

DNS cache poisoning

_________________________________

DHCP DoS attacks

_________________________________

Tunneling protocols attack

_________________________________

VPN enumeration

_________________________________

VPN-related attacks

_________________________________

Active OS fingerprinting

_________________________________

Discovered backdoors / backchannel traffic

_________________________________

Banner grabbing and host penetration​penetrated hosts () IP/hostname:vulnerability _________________________________ IP/hostname:vulnerability _________________________________ IP/hostname:vulnerability _________________________________ Network / host DoS resilience testing attack/host/result _________________________________ attack/host/result _________________________________ attack/host/result _________________________________ Egress filtering firewall testing from the wireless _________________________________ site Physical security issues discovered

_________________________________

Social engineering _________________________________ attacks

7 Final recommendations ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________

________________________________________________________________ ________________________________________________________________

Security Consultant Security Consultant Security Consultant

Appendix H. Default SSIDs for Several Common 802.11 Products 3com AirConnect 2.4Ghz DS (newer 11MB, Harris/Intersil Prism based)

Default SSID:

Comcomcom

Addtron Products

Default SSID:

WLAN

Aironet 900MHz/2.4GHz BR1000/e, BR5200/e and BR4800 Also known as Aironet 630/640 (for 900MHz) and Aironet 340 for 2.4GHz DSSS

Default SSID:

2 tsunami

Console Port:

No Default Password

Telnet Password:

No Default Password

HTTP Management:

On by default, No Default Password

Apple Airport

Default SSID:

AirPort Network AirPort Netzwerk

BayStack 650/660 802.11 DS AP

Default SSID:

Default SSID

Default Admin Password:

Default Channel:

1

NOTES: Default to the 10 net address, 2MB products.

Compaq WL-100 (reportedly the WL-200/300/400 devices as well)

Default SSID:

Compaq

Dlink DL-713 802.11 DS AP

Default SSID:

WLAN

Default Channel:

11

Default IP Address:

DHCP-administered

INTEL Pro/Wireless 2011 802.11 DSSS Product Families

PC CARD: Default SSIDs:

101 xlan intel

Default Channel:

3

Access POINT/REPEATER/BRIDGE: Default SSIDs:

101 195

LINKSYS Products

LINKSYS WAP-11 802.11 DS AP Default SSID:

Linksys

Default Channel:

6

Default WEP key one:

10 11 12 13 14 15

Default WEP key two:

20 21 22 23 24 25

Default WEP key three:

30 31 32 33 34 35

Default WEP key four:

40 41 42 43 44 45

Default WEP key four:

40 41 42 43 44 45

LINKSYS WPC-11 PCMCIA 802.11b DS 2.4GHz Cards

Default Channel:

3 11 6

Default SSID:

Wireless linksys

Netgear 802.11 DS Products, ME102 and MA401

Default SSID:

Wireless

Default Channel:

6

Default IP Address:

192.168.0.5

Default WEP:

Disabled

Default WEP KEY1:

11 11 11 11 11

Default WEP KEY2:

20 21 22 23 24

Default WEP KEY3:

30 31 32 33 34

Default WEP KEY4:

40 41 42 43 44

SMC Access Points

SMC2652W: Single Dipole, non-diversity (OEM radio) Default SSID:

WLAN

Default Channel:

11

Default HTTP:

user: default pass: WLAN_AP

SMC2526W: Wireless Access Point Dual-Dipole, diversity (non-OEM) Default SSID:

WLAN

Default IP:

192.168.0.254

Default AP Name:

MiniAP

Default Channel:

11

Default Admin Password:

MiniAP

SMC2682W EZ-Connect Wireless Bridge, Single Dipole, nondiversity Default SSID:

BRIDGE

Default Channel:

11

Default Admin Password:

WLAN_BRIDGE

SOHOware NetBlaster II

Default SSID:

Same as MAC

Default Channel:

8

Symbol AP41x1 and LA41x1 / LA41x3 802.11 DS Devices

Default SSID:

101

Default WEP key1:

10 11 12 13 14 15

Default WEP key2:

20 21 22 23 24 25

Default WEP key3:

30 31 32 33 34 35

Default WEP key4:

40 41 42 43 44 45

TELETRONICS WL-Access Points (0.5MB and 11MB)

Default SSID:

Any

Default Password:

1234

Wave Lan Family: Default SSID:

"WaveLAN Network"

Default Channel:

3

ZCOMAX 0.5MB DS 802.11 Station Bridges/Repeaters/Access point, model XWL450

Default SSID:

any melo test

Default Password:

1234

ZYXEL Prestige 316 Gateway/Natbox/WirelessBridge

Default SSID:

Wireless

Default Channel:

1

Default Password:

1234

Buffalo Air Station WLA-L11G

Default SSID:

ANY

Default Admin Password:

Default Admin User:

root

Default Channel:

1

Proxim AP-2000

Default SSID:

Wireless

Default User:

Default Password:

public

Glossary 31337 Add +4487044 in a Big-Endian order to contact the authors of this book via POTS.

802.11 The original IEEE standard defining medium access and physical layer specifications for up to 2 Mbps wireless connectivity on local area networks. 802.11 standard covers both DSSS and FHSS microwave radio LANs as well as infrared links.

802.11a A revision to the 802.11 IEEE standard that operates in the UNII band and supports data rates up to 54 Mbps using DSSS.

802.11b A revision to the 802.11 IEEE standard that operates in the middle ISM band and supports data rates up to 11 Mbps using DSSS.

802.11g A revision to the 802.11 IEEE standard that operates in the middle ISM band and supports data rates up to 54 Mbps using DSSS and possessing backward compatibility with 802.11b.

802.11i

The IEEE wireless LAN security standard developed by the 802.11i Task Group. 802.11i combines the use of 802.1x and TKIP/CCMP encryption protocols to provide user authentication, data confidentiality, and integrity on WLANs.

802.15 The IEEE communications specification that was approved in early 2002 for wireless personal area networks (WPANs).

802.1x The IEEE Layer 2 port-based access control and authentication standard.

access control list (ACL) In this book, a security mechanism controlling the incoming and outgoing traffic on the network.

access point A Layer 2 connectivity device that interfaces wired and wireless networks and controls networking parameters of wireless LANs.

active scanning A method by which client devices discover wireless networks. Involves the client device broadcasting a probe request frame and receiving a probe response frame containing the parameters of the responding network.

ad hoc network Also referred to as an Independent network or Independent basic service set (IBSS). An ad hoc network is a wireless LAN composed of wireless stations without an access point.

amplifier A device injecting DC power into the RF cable to increase gain. Can be uni- or bi-directional with fixed or adjustable gain increase.

antenna A device for transmitting or receiving a radio frequency (RF) signal. Antennas are designed for specific frequency ranges and are quite varied in design. In this book we mainly refer to antennas working in the ISM and UNII bands.

antenna diversity Use of multiple antennas per single receiver to increase the signal reception quality and overcome some RF problems, such as the multipath.

ARP spoofing Assuming a false Layer 2 identity on the network by injecting forged ARP packets.

attenuation Loss of RF signal amplitude due to the resistance of RF cables and connectors, free space path loss, interference, or obstacles on the signal path.

authentication header (AH) An IPSec protocol that verifies the authenticity of IP packets, but does not provide data confidentiality.

authenticator In 802.1x, the relay between the authentication server such as RADIUS and the supplicant. On wireless networks this is usually the access point; on wired LANs, high-end switches can perform such a function.

Banyan VINES Virtual networking system / protocols suite based on UNIX principles. Not used frequently nowadays. The Banyan VINES StreetTalk naming system is fun.

basic service set (BSS) A basic 802.11 cell consisting of a single access point and associated client hosts.

basic service set identifier (BSSID) In practical terms, a wireless side MAC address of an access point. Not to be confused with the ESSID.

Big-Endian A method of processing data in which the most significant bit is presented first.

Black Hat A malicious attacker determined to get in without any ethical considerations. Often used synonymously with "cracker."

Bluetooth A part of the 802.15 specification for WPANs developed and supported by the Bluetooth SIG (Special Interest Group), founded by Ericsson, Nokia, IBM, Intel, and Toshiba. Bluetooth radios are low-power FHSS transceivers operating in the middle ISM band.

broadcast SSID A blank service set identifier field in 802.11 management frames, synonymous with the ESSID "Any" in practical terms. Signifies that any client can connect to the WLAN.

brute force, brute-forcing A password / user credentials guessing attack based on comparing random non-repeating data strings with the password and username until the correct values are guessed.

CAM table flooding An attack based on overflowing the switch CAM (MAC) table with multiple fake MAC addresses to force the switch to behave like a hub.

CCMP (counter mode with CBC-MAC )

An AES-based encryption protocol planned for WEP and TKIP replacement when the 802.11i security standard is finally released. Will be required by the WPA version 2 certification.

Clear to Send (CTS) An 802.11 control frame type used by the virtual carrier sense mechanism. The CTS frame is sent as a reply to the RTS frame. It allows data transmission by the requesting host for a period of time declared in the Network Allocation Vector field.

closed system ESSID Hiding the ESSID by removing the ESSID value string from beacon and probe response frames. Like MAC address filtering, it is easily bypassed by determined attackers.

co-location Installing multiple access points on a single network using different noninterfering frequencies. Used to increase throughput on wireless LANs.

cracker Someone who breaks the network, host, or software security safeguards to gain unauthorized privileges.

CSMA / CA (Carrier Sense Multiple Access / Collision Avoidance) Layer 2 contention protocol used on 802.11​ compliant WLANs and by AppleTalk's LocalTalk. CSMA/CA employs positive ACKs for transmitted frames to avoid collisions on LANs.

Cyclic Redundancy Check (CRC) A basic mathematical checksum used to detect the transmitted data integrity violations. Often calculated by dividing the frame length by a prime number, and it can be easily forged by attackers.

dBi Decibels referenced to a perfect isotropic antenna.

dBm or decibels per milliwatt Zero dBm equals 1 mW power output at 1 KHz of frequency and 600 ohms of impedance.

Decibel (dB) Unit for measuring relative power ratios in terms of gain or loss.

DECnet A suite of network communication protocols developed and supported by Digital Equipment Corporation.

defense-in-depth In this book, an approach to network security based on creating multiple layers of defense without a reliance on a single countermeasure, security device, or protocol.

de-militarized zone (DMZ) An area in the firewall architecture that separates secure internal LAN and publicly accessible hosts.

denial of service (DoS) attack In this book, any type of attack that can shut down, freeze, or disrupt operation of a service, host, or the entire network.

dictionary attack A password / user credentials guessing attack based on comparing a dictionary wordlist with the password and username until the correct values are guessed.

DNS spoofing A traffic redirection attack based on assuming the domain name of another system by either corrupting the name service cache of a victim system, or by compromising a domain name server for a valid domain.

DSSS (Direct Sequence Spread Spectrum) One of two approaches to spread spectrum radio signal transmission. In DSSS the stream of transmitted data is divided into small pieces, each of which is allocated across a wide frequency channel. A data signal at the point of transmission is combined with a higher data-rate bit sequence that divides the data according to a spreading ratio.

EAP (Extensible Authentication Protocol) A flexible authentication protocol originally designed for PPP authentication and used by the 802.1x standard. EAP is defined by RFC 2284.

EAP (Extensible Authentication Protocol) methods Specific EAP authentication mechanism types. Common EAP methods include EAP-MD5, EAP-TLS, EAP-TTLS, EAP-PEAP, and EAP-LEAP.

EAPOL (EAP over LANs) Encapsulation of EAP frames on wired LANs. Defined separately for Ethernet and token ring.

EIRP (effective isotropic radiated power) The actual wireless power output at the antenna calculated as IR + antenna gain.

ESSID (Extended Service Set ID) The identifying name of an 802.11-compliant network. ESSID must be known in order to associate with the WLAN.

ETSI (European Telecommunications Standards Institute) A non-profit organization that produces telecommunication standards and regulations for use throughout Europe.

Extended service set (ESS) A network of interconnected basic service sets unified by a common SSID.

Federal Communications Commission (FCC) An independent U.S. government agency directly responsible to Congress. The FCC regulates all forms of interstate and international communications.

Federal Information Processing Standard (FIPS) The standards and guidelines developed and issued by the National Institute of Standards and Technology (NIST) for government-wide use in the United States.

FHSS (Frequency Hopping Spread Spectrum) One of two approaches to spread spectrum radio signal transmission. Characterized by a carrier signal that hops pseudo-randomly from frequency to frequency over a defined wide band.

free space path loss Decrease of RF signal amplitude due to signal dispersion.

Fresnel zone In simplified terms, an elliptical area around the straight line of sight between two wireless transmitters. The Fresnel zone should not be obstructed by more than 20 percent in order to maintain a reasonable wireless link quality.

gain An increase in RF signal amplitude. Estimated in decibels.

Gray Hat An IT security professional or enthusiast who follows situational ethics and can be both hero and villain depending on circ*mstances and mood.

hacker In this book, an individual enthusiastic about programming and/or networking, often with an interest in information security. Both media and the general public tend to confuse the terms "hacker" and "Black Hat"; in reality a hacker can wear a hat of any color.

hidden node A wireless client capable of communicating with the access point but unable to communicate with another wireless client(s) on the same WLAN. The presence of hidden nodes causes excessive collisions and retransmits on a wireless network.

hijacking In this book, taking over a network connection.

honeynet A real or virtual network of honeypots.

honeypot A host specifically set up to be attacked by crackers. The main reason for deploying honeypots is learning about crackers' behavior, methodologies, and tools. They can also be used to slow down the attacks by distracting the crackers' attention and effort. Honeypots are often set up with known security holes and should be completely separate from the internal network.

hotspot An area covered by a public access wireless network. Usually positioned in airports, hotels, coffee shops, and similar public places.

Initialization Vector (IV) In encryption, an additional nonsecret binary input for enciphering known or predictable plaintext to introduce additional cryptographic variance. In addition, IV can be used to synchronize cryptographic equipment.

Integrity Check Value (ICV) A simple checksum (CRC) calculated over an 802.11 frame before WEP encryption.

Internet Key Exchange (IKE) Key management protocol standard usually employed by IPSec.

Internet Protocol Security (IPSec) A standard Layer 3 data confidentiality and integrity protocol.

IrDA (Infrared Data Association) A non-profit trade association providing standards to ensure the quality and interoperability of infrared networking hardware.

IR (intentional radiator) RF transmitting device with cabling and connectors but without the antenna. Defined by the FCC for power output regulations implementation.

ISM (Industrial, Scientific, Medical) Frequency bands authorized by the FCC for use by industrial, scientific, and medical radio appliances without the need to obtain a license. These bands include 902​928 MHz, 2.4​2.5 GHz, and 5.725​5.875 GHz.

jamming Intentional introduction of interference to a wireless data channel. Layer 1 DoS attack against wireless networks.

Lightweight Directory Access Protocol (LDAP) A protocol that provides interface for management and browser applications enabling access to the X.500 directory service.

line of sight A straight line of visibility between two antennas.

Little-Endian A method of processing data in which the least significant bit is presented first.

lobes Also called beams; the electrical fields emitted by an antenna.

Management Information Base (MIB) An Abstract Syntax Notation (ASN) specification of device parameters. Used by SNMP for device status monitoring and reporting as well as remote configuration tasks.

man-in-the-middle attack An active attack in which the attacker intercepts and selectively modifies communicated data to masquerade as one or more of the entities involved in a communication process.

Message Integrity Check (MIC) An HMAC employed by the 802.11i security standard to ensure the packet authentication and integrity.

MS-CHAP Microsoft Challenge Handshake Authentication Protocol.

near/far problem Wireless networking problem caused by hosts in close proximity to the access point outpowering far nodes, efficiently cutting them off the network. Could be a result of a Layer 1 man-in-the-middle attack.

need-to-know principle A general security principle stating that users should only have access to the resources and data necessary to complete their tasks in accordance to their roles in the organization.

open system authentication Default 802.11 authentication method by exchanging authentication frames that must contain the same ESSID to succeed. Does not provide security because the ESSID is transmitted in cleartext.

Orthogonal Frequency Division Multiplexing (OFDM) A physical layer encoding technique multiplexing several slower data subchannels into a single fast, combined channel. Used by 802.11a and 802.11g standard-compliant networks.

passive scanning A method by which client devices discover wireless networks. Involves client devices listening for and analyzing beacon management frames.

penetration testing (pentesting)

A process of assessing the network or host security by breaking into it.

physical carrier sense In this book, wireless network medium sensing by checking the signal strength.

pigtail A connector that adapts proprietary connection sockets on wireless hardware to the standard RF connectors. A major source of headaches and failures in mobile setups such as wardriver "rigs."

Point-to-Point Tunneling Protocol (PPTP) A very common Microsoft proprietary tunneling protocol.

polarization In this book, the physical orientation of an antenna in relation to the ground. Can be horizontal or vertical.

power save mode (PSM) A mode of 802.11 client device operation in which the device powers down for very short amounts of time and passively listens to the beacon (BSS) or ATIM (IBSS) frames. When a beacon with the TIM field set or an ATIM frame is received, the client wakes up and polls the data. After all packets are polled, the client goes back to sleep.

Pre-Shared Key (PSK) mode. A WPA security mode based on distributing a pre-shared key among the WLAN hosts when key distribution via 802.1x is not available.

Remote Access Dial-In User Service (RADIUS) A de-facto standard multifunctional network authentication protocol and service with many implementations.

replay attacks Attacks based on replaying captured network traffic. Thwarted by properly implemented packet sequence counters.

repudiation A situation where the sending party denies sending data or the receiving party denies receiving it.

Request to Send (RTS) An 802.11 control frame type used by the virtual carrier sense mechanism. When virtual carrier sense is used on the 802.11 network, an RTS frame must be sent by a station willing to send data before the transmission is allowed to take place.

RFMON mode Also called monitor mode. A mode of 802.11 client device operation that allows capture and analysis of 802.11 frames. Used by wireless attackers for passive network discovery and eavesdropping, and it is necessary for 802.11 networks troubleshooting, monitoring, and intrusion detection.

RF (radio frequency) A generic term for any radio-based technology.

rig A wardriver's system setup, usually consisting of a laptop, antenna, GPS receiver, and necessary connectors and cables.

rogue wireless device An unauthorized transceiver. Often an access point or a wireless bridge, but can be a hidden wireless client device (e.g. USB dongle) as well.

routing attacks A class of traffic redirection or DoS attacks based on modifying the target host's routing table. Can be done by forging routing protocols updates as well as via ICMP types 5, 9, and 10.

RTS/CTS protocol A practical implementation of the virtual carrier sense on 802.11 networks. Uses 4-way RTS => CTS => Data => ACK handshake. RTS/CTS protocol is often employed to alleviate the hidden node problem.

script kiddie or 1337 h4x0r An unskilled attacker who uses (often precompiled) hacking tools without understanding how they were written and why they work. Often has an ego

the size of the Empire State Building.

shared key authentication A type of 802.11 authentication based on a challenge-response using a preshared WEP key. Does not provide strong security and will be eventually replaced by 802.1x.

site survey Surveying the area to determine the contours and properties of RF coverage.

SNR (signal-to-noise ratio) Received signal strength minus background RF noise ratio.

software access point An access point functionality implemented on a wireless client hardware using the access point capabilities of this hardware driver.

spanning tree protocol (STP) An 802.1d standard-defined Layer 2 protocol designed to prevent switching loops in a network with multiple switches and redundant connections.

spectrum analyzer A receiver that identifies the amplitude of signals at selected frequency sets. Useful for discovering interference or jamming on wireless networks.

spread spectrum RF modulation technique that spreads the signal power over a frequency band that is wider than necessary to carry the data exchanged.

Subnetwork Access Protocol (SNAP) An 802.3 frame format designed to provide backward compatibility with DIX Ethernet Version II and allow the use of Ethertype.

supplicant In 802.1x, a client device to be authenticated.

TEMPEST A violent wind, commotion, or disturbance. Often associated with all things related to RF emission security. The true code word encompassing the RF emissions security in general is EMSEC. TEMPEST stands for a classified set of standards for limiting electric or electromagnetic radiation emanations from electronic equipment, and it is included in EMSEC together with other RF countermeasures and attacks, such as HIJACK and NONSTOP.

TKIP (Temporal Key Integrity Protocol) An RC4-based encryption protocol which lacks many of the original static WEP's weaknesses. TKIP is a non-mandatory part of the 802.11i standard, which is backward compatible with WEP and does not require a hardware upgrade.

Traffic Indication Map (TIM) A field in 802.11 beacon frames used to inform sleeping client hosts about data buffered for them to receive.

UNII (Unlicensed National Information Infrastructure) A segment of RF bands authorized by the FCC for unlicensed use; includes 5.15​ 5.25, 5.25​ 5.35, and 5.725​5.825 GHz frequencies.

Virtual Carrier Sense A carrier sense method based on using a Network Allocation Vector (NAV) field of 802.11 frames as a timer for data transmission on the WLAN. The timer is set employing the RTS/CTS protocol.

Virtual Local Area Network (VLAN) A functionality that allows broadcast domain separation on a data link layer using 802.1q or Cisco ISL frame tagging. A router is needed to connect separate VLANs.

warchalker A Mother Theresa version of wardriver.

warchalking Labeling discovered wireless network's presence and properties with a piece of chalk or paint using a set of known, agreed symbols. Optional altruistic addon to wardriving.

wardriver/walker/cyclist/climber/flier/sailer A mobile geek usually seeking areas with wireless presence. Advanced people of this type often carry sizable antennas and wield GPS receivers.

wardriving/walking/cycling/climbing/flying/sailing Discovering wireless LANs for fun and/or profit. It can be a harmless hobby or a reconnaissance phase of future attacks against uncovered wireless LANs and wired networks connected to them.

WEP (wired equivalent privacy) An optional 802.11 security feature using RC4 streaming cipher to encrypt traffic on a wireless LAN. Several flaws of WEP are published and widely known.

White Hat An IT security professional or enthusiast who adheres to a strict ethical code and would never commit anything illicit (on the network, anyway). A White Hat may discover new security flaws and report them to the vendors first and later to the general public.

WIDS (wireless IDS) An intrusion detection system capable of detecting Layer 1 and Layer 2 wireless security violations.

Wi-Fi Alliance

An organization that certifies interoperability of 802.11 devices and promotes Wi-FiTM as a global wireless LAN compatibility standard.

Wi-Fi (Wireless Fidelity) The Wi-Fi Alliance certification standard that ensures proper interoperability among 802.11 products.

wireless bridge A data link layer device that connects wired LANs via wireless medium.

wireless distributed system (WDS) An element of a wireless system that consists of interconnected basic service sets forming an extended service set.

wireless gateway A wireless to wired high-end connectivity device that supports a variety of advanced features, possibly including firewall, router, QoS, VPN concentrator, and authentication server functionality. An access point on steroids.

wireless LAN (WLAN) In this book this term mainly refers to 802.11-compliant LANs. Of course this use of the term is only partially correct because other types of wireless LANs also exist, but they are not that common.

wireless man-in-the-middle / hijacking attacks

Rogue wireless device insertion attacks that exploit Layer 1 and Layer 2 vulnerabilities of wireless networks.

wireless sniffer A protocol analyzer capable of monitoring the traffic on a wireless network (e.g., using the RFMON mode on 802.11 LANs) and understanding specific Layer 2 wireless protocols.

wireless traffic injection attack An attack against WEP-protected WLANs based on duplicating bypassing traffic and reinjecting it into the network or based on obtaining valid parts of the keystream per selected IV to send valid data to the network without knowing the key.

WPA (Wi-Fi Protected Access) A security subset of the interoperability Wi-Fi certification using 802.11i standard features. At the moment of writing, WPA version 1.0 is available.

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] @Stake 3Com 3DES 2nd 3rd

802.11 wireless network frames, analysis of future of security 2nd reasons for focusing on 2nd 3rd 4th SSIDs, default 2nd 3rd 4th use of term 802.11a client adapters 2nd 802.11b client adapters 2nd 3rd 4th 5th 6th 802.11g 802.11i standard 2nd 3rd 4th 5th 6th 7th 8th 9th attacks against implementations 2nd per-packet key mixing function 2nd 3rd 4th

802.1x authentication systems access point configuration, Orinoco AP-2000 example 2nd 3rd certificates, creating 2nd 3rd description of 2nd 3rd 4th EAP-TLS, basics of 2nd 3rd 4th 5th EAP-TLS, enable 2nd 3rd supplicants 2nd 3rd 4th 5th 6th tools to attack 2nd 3rd

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] AAA framework 2nd Access point association, filling up Access point configuration, Orinoco AP-2000 example 2nd 3rd 4th 5th

Access point deployment rogue 2nd 3rd security of Access point management utilities 2nd 3rd Accounting 2nd Accounting logparser Active scanning 2nd 3rd 4th ADM8211 chipset 2nd 3rd ADMtek, Inc AES 2nd 3rd 4th MARS 2nd 3rd 4th 5th 6th 7th 8th RC6 2nd 3rd 4th 5th 6th 7th Rijndael 2nd 3rd 4th 5th Serpent 2nd 3rd 4th 5th 6th 7th Twofish 2nd 3rd 4th 5th 6th 7th 8th Agere/Proxim WEPPlus Airconf AirDefense Guard Airfart 2nd AirIDS AirJack 2nd 3rd 4th 5th 6th 7th 8th 9th 10th AirMagnet (Java sniffer) AirMagnet monitoring utility 2nd Aironet chipset 2nd 3rd 4th 5th 6th AiroPeek 2nd 3rd Airosniff Airscanner Mobile Sniffer Airsnarf AirSnort Airtraf 2nd 3rd Aleph One Amplifiers 2nd ancontrol 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th Anderson, Ross Anger 2nd

Angst 2nd

Antennas gain 2nd irradiation pattern diagrams 2nd 3rd 4th 5th polarization 2nd positioning 2nd 3rd selecting 2nd 3rd 4th types of 2nd Anwrap.pl AOL Instant Messenger AP Hopper Ap-mrtg 2nd Ap-trapd APD Aphunter 2nd 3rd Apple AirPort AppleTalk Apradar 2nd 3rd arpmin arpspoof Asleap-imp 2nd Asymmetric cryptography 2nd 3rd 4th 5th 6th 7th 8th 9th Atheros chipset 2nd 3rd Atmel chipset Attack signatures 2nd 3rd 4th 5th 6th 7th

Attack, planning the battery power management and estimation 2nd penetration testing kit 2nd 3rd search, conducting an extensive 2nd 3rd site survey issues 2nd 3rd 4th stealth levels while penetration testing 2nd timing 2nd walk-through, conducting a 2nd

Attacking authentication systems 2nd 3rd 4th 5th bridges for penetration testing 2nd 3rd 4th 5th 6th brute-force 2nd

bypassing closed ESSIDs, Mac, and protocol filtering 2nd 3rd 4th 5th 6th combining layers 2nd connectivity DoS attacks against EAP DoS attacks, methods of 2nd 3rd 4th 5th 6th 7th easiest way 2nd 3rd 4th 5th 6th 7th FMS attacks 2nd 3rd 4th 5th 6th honeypot trap man-in-the-middle 2nd 3rd 4th 5th 6th Physical Layer 2nd 3rd reachability replaying rogue access point deployment 2nd 3rd 4th 5th 6th 7th 8th TKIP and PSK keys 2nd 3rd traffic injections VPNs 2nd 3rd 4th 5th 6th 7th wired systems 2nd 3rd 4th 5th 6th attrition.org Authentication 2nd 3rd 4th buffers, filling up frame attacks, spoofed malformed 2nd protocols, analysis of 2nd 3rd systems attacks 2nd 3rd 4th 5th Authentication Header (AH) 2nd 3rd 4th

Authenticator attacks, RADIUS request response Authorization 2nd Avalanche effect

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] Backdoors Bandwidth snatchers Banyan Vines Battery power management and estimation 2nd Bell-LaPadula model of security systems Berkeley Varitronics Systems drivers Biba model of security systems 2nd Biham, Eli Birthday attacks birthday.pl BKtspibdc Black Hats 2nd Blowfish 2nd 3rd 4th 5th Bluetooth 2nd Bridges for penetration testing 2nd 3rd 4th 5th 6th Broadcom AirForce brute-force 2nd BSD 2nd configuring wireless client cards on 2nd 3rd 4th discovery and traffic logging tools 2nd 3rd 4th 5th list of supported wireless cards in 2nd 3rd making client cards work with 2nd 3rd 4th 5th 6th 7th 8th 9th

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] Cables 2nd Caesar's cipher CCMP 2nd 3rd Certicom and Funk Software Certificates, creating 2nd 3rd Channels 2nd flooding CHAP Chipsets selecting 2nd 3rd 4th 5th 6th 7th 8th Cipher Block Chaining (CBC) mode 2nd 3rd Cipher counter mode (CCM) Cipher Feedback (CFB) mode 2nd Ciphers

[See Cryptography]

asymmetric 2nd 3rd 4th 5th 6th 7th selecting 2nd 3rd 4th 5th structure and operation modes 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th

Cisco, Inc Aironet chipset 2nd 3rd 4th 5th 6th catalyst switches 2nd 3rd 4th 5th 6th Centralized Key Management (CCKM) Discovery Protocol (CDP) EAP-LEAP 2nd 3rd 4th 5th 6th Hot Standby Router Protocol (HSRP) Key Integrity Protocol (CKIP) Layer 2 Tunneling Protocol (L2TP) 2nd 3rd Message Integrity Check (CMIC) SAFE 2nd Virtual Router Resilience Protocol (VRRP) 2nd Vulnerability Scanner Cistron

Client cards

configuring 2nd 3rd 4th Linux and NetBSD with 2nd 3rd 4th 5th 6th 7th

Client/server model LDAP 2nd RADIUS 2nd 3rd clPe Collision Compact Flash (CF) cards Compaq's iPAQs Compression, IP 2nd 3rd Configuration of client cards Connection-oriented protocol links Connectivity Connectors 2nd Cookies Cryptanalysis

Cryptography AES 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th asymmetric 2nd 3rd 4th 5th 6th 7th 8th 9th basics 2nd 3rd 4th 5th 6th 7th between DES and AES 2nd 3rd 4th 5th 6th 7th cipher structure and operation modes 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th defined hash (one-way) functions 2nd selecting ciphers 2nd 3rd 4th 5th streaming algorithms 2nd 3rd Cryptology CVS driver, obtaining

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] Dach0den Labs 2nd 3rd Daemen, Joan Data Encryption Standard [See DES] Data transmission, analysis of plaintext 2nd 3rd Dead Peer Discovery (DPD) 2nd Deassociate frames, flooding with 2nd 3rd 4th Deauthentication frames, flooding with 2nd Deceit Decibels, converting watts to 2nd 3rd DECnet Default settings Defcon 2003 wardrive

DES (Data Encryption Standard) 3DES 2nd 3rd description of 2nd 3rd 4th 5th 6th DHCP 2nd Diffie, Whitfield Diffie-Hellman (DH) system Digital certificates Digital envelopes Digital Signature Algorithm (DSA) 2nd Digital signatures 2nd dinject 2nd 3rd dinject-deauth utility dinject-disas utility

Directories LDAP 2nd purpose of Directory Administrator 2nd disco

Discovery methods active scanning 2nd 3rd 4th Airfart 2nd Airtraf 2nd 3rd BSD tools 2nd 3rd 4th 5th Gtkskan

iwlist scan command 2nd 3rd Kismet 2nd 3rd 4th 5th 6th 7th 8th 9th 10th miscellaneous command-line scripts and utilities 2nd 3rd 4th 5th 6th Mognet 2nd RF signal strength monitoring tools 2nd 3rd Wellenreiter 2nd WifiScanner 2nd DNS spoofing 2nd dnshijacker dnsspoof

DoS attacks against 802.11i implementations 2nd against EAP based on settings 2nd filling up access point association and authentication buffers frame deletion Physical Layer or jamming spoofed deassociation and deauthentication frames floods 2nd spoofed malformed authentication frame 2nd driftnet DriverLoader Drivers 2nd 3rd 4th 5th 6th 7th 8th 9th 10th Dsniff webspy DStumbler 2nd 3rd 4th 5th Duntze, Charles Dwepcrack 2nd Dwepdump Dwepkeygen Dweputils 2nd

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] EAP authentication systems attacks 2nd 3rd 4th 5th DoS attacks against frame exchange 2nd EAP-AKA EAP-LEAP 2nd 3rd 4th 5th 6th EAP-MD5 2nd 3rd EAP-PEAP 2nd 3rd EAP-SIM EAP-TLS 2nd basics of 2nd 3rd 4th 5th enable 2nd 3rd packet format EAP-TTLS 2nd 3rd EAPOL 2nd EIGRP EIRP 2nd Electronic Codebook (ECB) mode Electronic Frontier Foundation (EFF) 2nd ElGamal 2nd Elliptic curves 2nd 3rd Encapsulating Security Payload (ESP) 2nd 3rd Encrypted traffic injection tools 2nd 3rd 4th 5th 6th Encryption cracking tools retrieving WEP keys stored on client hosts to attack 802.1x authentication systems 2nd 3rd traffic injection tools to accelerate WEP cracking 2nd WEP crackers 2nd 3rd 4th 5th 6th 7th 8th Encryption, hybrid Equivalent isotropically radiated power (EIRP) 2nd ESSIDs bypassing closed 2nd 3rd closed, role of 2nd Ethereal Ettercap 2nd 3rd 4th 5th 6th 7th 8th

Events, categorizing suspicious 2nd 3rd 4th

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] FakeAP 2nd fata_jack 2nd Feistel cipher Feistel, Horst Ferguson, Niels 2nd Festchook, Roman File2air 2nd 3rd 4th 5th Fingerprinting 2nd 3rd Firewall testing 2nd 3rd

Flooding channel tools with deassociate frames 2nd 3rd 4th with deauthentication frames 2nd Fluhrer, Scott 2nd FMS (Fluhrer, Mantin, and Shamir) attacks 2nd 3rd 4th 5th 6th 7th Frame deletion attacks

Frame-generating tools AirJack 2nd 3rd 4th FakeAP 2nd File2air 2nd Libwlan 2nd 3rd Void 2nd 3rd Wnet 2nd Frames, analysis of Free space path loss FreeBSD 2nd FreeRADIUS installing and configuring 2nd 3rd 4th 5th 6th 7th integration 2nd 3rd FreeS/WAN (secure wide area network) compilation 2nd 3rd 4th 5th 6th configuration 2nd 3rd 4th 5th 6th 7th key generation 2nd 3rd parameters 2nd 3rd

X.509 certificate generation 2nd FTP

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] Gateway resilience protocols, analysis of 2nd Gateway security 2nd 3rd 4th 5th 6th 7th Generic Routing Encapsulation (GRE) Ghost Port Scan 2nd Gilmore, John Global Secure Systems GNU-radius Google GPE Palmtop Environment GPRS phones Gpsdrive 2nd 3rd 4th 5th Gpsmap 2nd 3rd GQ client 2nd Greping data GSM phones Gtkskan

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] H1kari Hard problem 2nd Hash functions 2nd 3rd 4th 5th 6th 7th 8th 9th HAVAL Hellman, Martin Hermes chipset 2nd 3rd HermesAP Hills, Roy HMAC 2nd Honeypots and honeynets 2nd Host-to-host VPN 2nd Host-to-network VPN 2nd 3rd HostAP drivers 2nd 3rd 4th 5th 6th installing and setting 2nd

Hosts hijacking names 2nd identifying 2nd 3rd scanning and exploiting 2nd 3rd 4th Hot Standby Router Protocol (HSRP) HTTP Hunt 2nd Hydra

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] IBM 802.11 security testing software 2nd MARS 2nd 3rd 4th ICMP redirect attacks ICQ ICRADIUS IDEA (International Data Encryption Algorithm) 2nd 3rd 4th 5th IDS [See Intrusion detection systems] ifconfig IGRP IKE (Internet Key Exchange) manglers 2nd 3rd 4th 5th IKE-scan 2nd 3rd 4th 5th IKECrack IKEProber.pl 2nd 3rd 4th 5th IMAP Immunix Infrared Data Association (IrDA) PANs InProcomm IPN Insecurity, scope of 2nd 3rd Integrity law Intel PRO/Wireless (Centrino) Interference 2nd Internet Key Exchange (IKE) 2nd 3rd 4th 5th Intersil, Inc

Intrusion detection systems (IDS) analysis of 2nd 3rd attack signatures 2nd 3rd 4th 5th 6th 7th categorizing suspicious events 2nd 3rd 4th commercial wireless 2nd 3rd knowledge-based 2nd Open Source settings and configuration 2nd 3rd 4th sensor construction 2nd 3rd 4th 5th signature-based iPAQs 2nd

IPSec Key Exchange and Management Protocol (ISAKMP) IPSec protocol 2nd attacking 2nd 3rd 4th 5th 6th Authentication Header (AH) 2nd 3rd 4th components of Dead Peer Discovery (DPD) 2nd development of Encapsulating Security Payload (ESP) 2nd 3rd 4th FreeS/WAN 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th Internet Key Exchange (IKE) 2nd 3rd 4th 5th IP compression 2nd 3rd operation modes 2nd opportunistic encryption Perfect Forward Secrecy (PFS) security associations 2nd VPN 2nd 3rd Windows 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th IPX IRC Irdaping IRPAS 2nd Isomair Wireless Sentry 2nd ISS iwconfig 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th iwevent iwgetid iwlist 2nd 3rd 4th 5th 6th tools that use scan command 2nd 3rd iwpriv 2nd 3rd 4th 5th iwspy

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] Jamming Java Development Kit (JDK) 2nd Jean's Tourrilhes Linux Wireless Extensions John the Ripper 2nd

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] Keinert, Joachim Keli, Mi Kerberos authentication services Kerckhoff's cipher Kernel compilation 2nd Key ciphers, running Key distribution Key schedule algorithm Key-encrypting keys (KEKs) Killmon utility Kismet 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th Knudsen, Lars kracker_jack

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] L2TP [See Layer Two Tunneling Lai, Xuejia Laptops 2nd 3rd Layer Two Tunneling Protocol (L2TP) 2nd

Protocol]

LDAP (Lightweight Directory Access Protocol) centralizing authentication with 2nd 3rd 4th 5th 6th 7th client/server model 2nd defined 2nd directory structure 2nd migration tools 2nd 3rd mobile users and 2nd OpenLDAP, configuration of 2nd 3rd 4th 5th OpenLDAP, installation of 2nd 3rd related tools 2nd 3rd 4th testing 2nd 3rd Tool LdapExplorer 2nd ldapsearch 2nd Leap 2nd 3rd Leapcrack 2nd Libradiate 2nd Libwlan 2nd 3rd 4th LIDS 2nd Linux 2nd 3rd making client card work with 2nd 3rd 4th 5th 6th 7th supplicants 2nd 3rd Linux Wireless Extensions 2nd 3rd 4th 5th 6th linux-wlan-ng utilities 2nd 3rd 4th 5th Linuxant DriverLoader Litty, Lionel LM/NTLMv1 Windows authentication hashes Local area networks (LANs)

Lucent Technologies

Hermes chipset Orinoco Client Manager RegCrypto utility Lucifer cipher

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] MAC filtering 2nd bypassing 2nd role of macfld.pl macof Madwifi drivers 2nd 3rd Malloc() fwscrape 2nd Man-in-the-middle attacks 2nd 3rd combining layers 2nd Physical Layer 2nd Mantin, Itsik 2nd MARS 2nd 3rd 4th 5th 6th 7th 8th Massey, James McKay, Raymond MD 2nd 3rd 4th 5th Mdcrack 2nd Mesh VPN Michael (MIC) 2nd 3rd 4th 5th

Microsoft Corp Layer 2 Tunneling Protocol (L2TP) 2nd MS-CHAP 2nd 3rd Point-to-Point Tunneling Protocol (PPTP) 2nd 3rd Migration tools 2nd Mimic functions MiniStumbler 2nd 3rd Mognet 2nd monkey_jack utility 2nd MS-CHAP 2nd 3rd Mudge, Dr 2nd

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] Nai Sniffer Wireless 2nd National Institute of Standards and Technology (NIST) National Security Agency (NSA) 2nd NdisWrapper Nemesis 2nd Nessus 2nd 3rd 4th NetBSD [See BSD] netsed Netstumbler 2nd 3rd 4th 5th 6th 7th 8th Network Access Server (NAS) Network-to-network VPN 2nd 3rd 4th Neutrino Distributed 802.11b Sensor Newsham, Mike Newsham, Tim NFS, sniffing out nmap NoCat 2nd 3rd 4th 5th 6th 7th 8th NTP traffic

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] Omen omerta utility 2nd 3rd One-time pads One-way (hash) functions 2nd Open message format Open Palmtop Integrated Environment (OPIE) Open source 2nd OpenBSD 2nd

OpenLDAP configuration of 2nd 3rd 4th 5th installation of 2nd 3rd OpenRADIUS OpenVPN 2nd Operating system fingerprinting Orinoco AP-2000, access point configuration example 2nd 3rd Orinoco Gold Osborne, Mark 2nd OSPF Output Feedback (OFB) mode 2nd

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] p0f Packet integrity preservation Packets, EAP

Packets, RADIUS formats 2nd types 2nd Packetstorm Security Packetyzer/Ethereal PADL, migration tools 2nd 3rd passifist Passwords 2nd 3rd PC- 2nd PCMCIA card cradles SSIDs, default 2nd 3rd 4th PCMCIA-cs configuration 2nd 3rd PDAlert PDAs 2nd 3rd pdump 2nd 3rd Penetration testing 2nd bridges for 2nd 3rd 4th 5th 6th kit components 2nd 3rd stealth levels while 2nd template 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th Per-packet key mixing function 2nd 3rd 4th Perfect Forward Secrecy (PFS) Perl script 2nd 3rd Perlskan Personal area networks (PANs) 2nd pGina 2nd 3rd 4th

Physical Layer attacks 2nd 3rd security 2nd 3rd 4th 5th Pluggable Authentication Module (PAM) 2nd 3rd PocketWarrior

Point-to-Point Tunneling Protocol (PPTP) 2nd 3rd POP Port scanning Power calculations 2nd 3rd 4th Power-saving mode attacks Preshard key (PSK) 2nd 3rd 4th

Prism based cards 2nd chipset 2nd 3rd 4th 5th 6th 7th monitor headers 2nd 3rd 4th Prism2ctl 2nd Prism2dump 2nd Prismdump 2nd Prismsnort Property rule 2nd Protocol filtering, bypassing 2nd 3rd Pseudo-random generators (PRNGs) 2nd Public key algorithm

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] QA Cafe

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] RADIUS (Remote Authentication Dial-In User Service) 2nd 3rd AAA framework 2nd accounting 2nd attribute types features of 2nd freeRADIUS, installing and configuring 2nd 3rd 4th 5th 6th 7th freeRADIUS, integration 2nd 3rd overview of 2nd packet codes packet formats 2nd packet types 2nd related tools 2nd vulnerabilities 2nd 3rd RadiusContext RadiusReport RadiusSplit Rager, Anton T 2nd rathergood.com Raw frame sniffing mode 2nd 3rd 4th RC 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th Reachability Realtek RTL8180L Redfang Regulation of Investigatory Powers (RIP) Bill reinj 2nd 3rd Remote Access Server (RAS)

RF amplifiers 2nd antennas 2nd 3rd 4th cables and connectors 2nd jamming power calculations 2nd 3rd 4th signal strength monitoring tools 2nd 3rd RF monitor (RFMON) 2nd 3rd

RFGrabber Rijmen, Vincent Rijndael 2nd 3rd 4th RIPEMD 2nd RIPv 2nd Rivest, Ronald 2nd Rogue access point deployment 2nd 3rd 4th 5th 6th 7th 8th ROT 2nd 3rd Routing protocol, analysis of Routing updates, injecting 2nd RSA (Rivest, Shamir, Adleman) encryption method 2nd RSA Data Security, Inc 2nd 3rd 4th RSA Signature Scheme 2nd RTS/CTS 2nd 3rd

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] SAFE 2nd Satan/Saint/Sara Savard, John 2nd 3rd Scanchan Scanning 2nd 3rd 4th Schiffman, Mike 2nd Schneier, Bruce Blowfish 2nd 3rd Twofish 2nd 3rd 4th Search, conducting an extensive 2nd 3rd Secure Digital (SD) cards Secure message format Security 2nd

[See Cryptography]

802.11i standard 2nd 3rd 4th 5th 6th 7th 8th 9th access point deployment and positioning audits Bell-LaPadula model of security systems Biba model of security systems 2nd closed ESSIDs 2nd countermeasures gateway 2nd 3rd 4th 5th 6th 7th MAC filtering monitoring and incident response 2nd Physical Layer 2nd 3rd 4th 5th proprietary improvements 2nd 3rd RADIUS 2nd SSH port forwarding 2nd updates and registrations user education and responsibility 2nd VLANs 2nd 3rd 4th 5th Security associations (SAs) 2nd Self-synchronization SELinux

Senao Long Range Sensor construction 2nd 3rd 4th 5th Sentinel 2nd 3rd 4th 5th Serpent 2nd 3rd 4th 5th 6th 7th SHA,hash (one-way) functions 2nd 3rd Shamir, Adi 2nd 3rd Shannon, Claude Sharp Zaurus 2nd 3rd Shmoo Group 2nd Signal loss, obstacle types and

Signal strength limiting 2nd monitoring tools 2nd 3rd Simple authentication and security layer (SASL) 2nd Simple security rule Sing Siphon Site surveying 2nd issues 2nd 3rd 4th slapd Sleepycat Software Berkeley DBv 2nd smbproxy Smoorenburg, Miquel van Sniffdet 2nd Sniffer Wireless Sniffers, detecting 2nd 3rd SNMP snmpget snmpset snmpwalk SNR 2nd Soekris boards Song, Dug Sourceforge 2nd SPAM 2nd Spitzner, Lance Spoofed deassociation and deauthentication frames floods 2nd Spoofed malformed authentication frame 2nd SSH 2nd 3rd port forwarding 2nd sshmitm 2nd sshow SSHv 2nd

SSIDs, default 2nd 3rd 4th Ssidsniff ST-divine Star VPN Stealth levels while penetration testing 2nd Steganography 2nd Steghide Stegtunnel Streaming algorithms 2nd 3rd Super Sniffer

Supplicants Linux 2nd 3rd Windows 2000 and Windows XP 2nd 3rd 4th Surfing sw-mitm Symbol chipset 2nd Symmetric block cipher SYN ACK Labs Synchronous stream cipher Syslog

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] Taranis TCP wrappers Team Teso Texas Instruments chipsets THCrut 2nd Tiger TKIP (Temporal Key Integrity Protocol) 2nd 3rd 4th 5th 6th Traffic indication map (TIM) frame attacks Traffic injection tools 2nd 3rd 4th 5th 6th 7th 8th 9th Traffic, analyzing network 2nd 3rd 4th 5th 6th Transport layer security, OpenLDAP Trapdoof Traps Tripwire 2nd Truth tables Tunneling protocols 2nd 3rd Twofish 2nd 3rd 4th 5th 6th 7th 8th 9th

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] User authentication

[See Security;RADIUS]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] Vagner Sacramento Virtual carrier sense-implementing network attacks Virtual private networks [See Attacking;VPNs] Virtual Router Resilience Protocol (VRRP) 2nd VLANs, security and 2nd 3rd 4th 5th Voice over IP (VOIP) 2nd Void 2nd 3rd 4th 5th 6th vomit 2nd

VPNs (virtual private networks) attacking 2nd 3rd 4th 5th 6th 7th clPe Open 2nd purpose of 2nd 3rd reasons for deploying 2nd topologies 2nd 3rd 4th 5th 6th 7th 8th 9th tunneling protocols and common 2nd 3rd Vtun Vtun

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] Warchalking 2nd signs 2nd Warclimbing 2nd Warcycling 2nd Wardialing Wardrive 2nd 3rd Wardriving Warwalking 2nd Watts, converting decibels to 2nd 3rd Wavemon Wavesec Wavestumbler 2nd Webmitm

Websites for network footprinting 2nd 3rd for power calculations webspy Wellenreiter 2nd 3rd 4th 5th 6th WEP 2nd 3rd key length 2nd proprietary improvements 2nd 3rd tool for retrieving keys stored on client hosts

WEP crackers AirSnort Dweputils 2nd Wep_tools 2nd 3rd 4th WepAttack 2nd Wepcrack 2nd 3rd

WEP cracking brute-force 2nd field observations in 2nd traffic injection tools to accelerate 2nd 3rd Wep_tools 2nd 3rd 4th WepAttack 2nd

Wepcrack 2nd 3rd Wepwedgie 2nd 3rd 4th 5th 6th Whitening 2nd Whiting, Doug Wi-Fi Alliance wicontrol 2nd 3rd 4th 5th 6th 7th 8th 9th 10th Wide area networks (WANs) wIDS 2nd WIDZ 2nd WifiScanner 2nd WildPackets, AiroPeek 2nd 3rd

Windows client setup 2nd 3rd 4th 5th 6th IPSec client configuration 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th supplicants 2nd 3rd 4th

Windows XP probing scanning service 2nd supplicants 2nd 3rd 4th Windows, tools for 2nd Wired systems, attacking 2nd 3rd 4th 5th 6th Wireless Access Point Utilities for UNIX

Wireless hackers targets of 2nd 3rd 4th who are 2nd 3rd Wireless hacking, reasons for 2nd 3rd 4th Wireless Network Meter Wireless Power Meter (wpm) Wireless Protected Access (WPA) 2nd 3rd 4th 5th 6th 7th WiSentry Wistumbler 2nd wlan-scan wlan_jack 2nd wlancfg 2nd wlanctl-ng 2nd 3rd WlanFE wlanmeter wlansniff Wnet 2nd Wright, Joshua 2nd 3rd 4th 5th 6th 7th 8th

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] X.509 certificate generation 2nd XORing 2nd Xtops XtRADIUS xwconfig

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] YALA YARD RADIUS YellowJacket and YellowJacket Plus

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z] Zcomax XI-325HP ZoomAir access points