Hacking Wireless Networks (2015)

Part I

Building the

Foundation for

Testing Wireless

Networks

Chapter 2 The Wireless Hacking Process

In This Chapter

ᮣ Understanding the hacking process

ᮣ The Ten Commandments of Ethical Hacking

ᮣ Understanding the standards

ᮣ Evaluating your results

We teach courses on ethical hacking — and when you’re teaching, you need an outline. Our teaching outline always starts with the introduction to the ethical-hacking process that comprises most of this chapter.

Inevitably, when the subject of an ethical hacking process comes up, the class participants visibly slump into their chairs, palpable disappointment written all over their faces. They cross their arms across their chests and shuffle their feet. Some even jump up and run from class to catch up on their phone calls. Why? Well, every class wants to jump right in and learn parlor tricks they can use to amaze their friends and boss. But that takes procedure and practice. Without a defined process, you may waste time doing nonessential steps while omitting crucial ones. So bear with us for a while; this background information may seem tedious, but it’s important.

Obeying the Ten Commandments

of Ethical Hacking

In his book Hacking For Dummies (Wiley), Kevin discussed the hacker genre and ethos. In Chapter 1, he enumerated the Ethical Hacking Commandments.

In that book, Kevin listed three commandments. But (as with everything in networking) the list has grown to fill the available space. Now these commandments were not brought down from Mount Sinai, but thou shalt follow these commandments shouldst thou decide to become a believer in the doctrine of ethical hacking. The Ten Commandments are

1. Thou shalt set thy goals.

2. Thou shalt plan thy work, lest thou go off course.

07_597302_ch02.qxd 8/4/05 7:26 PM Page 20

20 Part I: Building the Foundation for Testing Wireless Networks 3. Thou shalt obtain permission.

4. Thou shalt work ethically.

5. Thou shalt work diligently.

6. Thou shalt respect the privacy of others.

7. Thou shalt do no harm.

8. Thou shalt use a scientific process.

9. Thou shalt not covet thy neighbor’s tools.

10. Thou shalt report all thy findings.

Thou shalt set thy goals

When Peter was a kid, he used to play a game at camp called Capture the Flag. The camp counselors would split all the campers into two teams: one with a red flag and one with a blue flag. The rules were simple: If you were on the blue team, then you tried to find the red flag that the red team had hidden and protected, and vice versa. Despite appearances, this game could get rough — on the order of, say, Australian Rules Football. It was single-minded: Capture the flag. This single-mindedness is similar to the goals of a penetration test, a security test with a defined goal that ends either when the goal is achieved or when time runs out. Getting access to a specific access point is not much different from capturing a flag: Your opponent has hidden it and is protecting it, and you’re trying to circumvent the defenses. Penetration testing is Capture the Flag without the intense physical exercise.

How does ethical hacking relate to penetration testing? Ethical hacking is a form of penetration testing originally used as a marketing ploy but has come to mean a penetration test of all systems — where there is more than one goal.

In either case, you have a goal. Your evaluation of the security of a wireless network should seek answers to three basic questions:

ߜ What can an intruder see on the target access points or networks?

ߜ What can an intruder do with that information?

ߜ Does anyone at the target notice the intruder’s attempts — or successes?

You might set a simplistic goal, such as finding unauthorized wireless access points. Or you might set a goal that requires you to obtain information from a system on the wired network. Whatever you choose, you must articulate your goal and communicate it to your sponsors.

07_597302_ch02.qxd 8/4/05 7:26 PM Page 21

Chapter 2: The Wireless Hacking Process

Involve others in your goal-setting. If you don’t, you will find the planning process quite difficult. The goal determines the plan. To paraphrase the Cheshire Cat’s response to Alice: “If you don’t know where you are going, any path will take you there.” Including stakeholders in the goal-setting process will build trust that will pay off in spades later on.

Thou shalt plan thy work,

lest thou go off course

Few, if any of us, have an unlimited budget. We usually are bound by one or more constraints. Money, personnel or time may constrain you. Consequently, it is important for you to plan your testing.

With respect to your plan, you should do the following:

1. Identify the networks you intend to test.

2. Specify the testing interval.

3. Specify the testing process.

4. Develop a plan and share it with all stakeholders.

5. Obtain approval of the plan.

Share your plan. Socialize it with as many people as you can. Don’t worry that lots of people will know that you are going to hack into the wireless network. If your organization is like most others, then it’s unlikely they can combat the organizational inertia to do anything to block your efforts. It is important, though, to remember that you do want to do your testing under

“normal” conditions.

Thou shalt obtain permission

When it comes to asking for permission, remember the case of the Internal Auditor who, when caught cashing a payroll check he didn’t earn, replied, “I wasn’t stealing. I was just testing the controls of the system.” When doing ethical hacking, don’t follow the old saw that “asking forgiveness is easier than asking for permission.” Not asking for permission may land you in prison!

You must get your permission in writing. This permission may represent the only thing standing between you and an ill-fitting black-and-white-striped suit and a lengthy stay in the Heartbreak Hotel. You must ask for — and get — a 07_597302_ch02.qxd 8/4/05 7:26 PM Page 22

22 Part I: Building the Foundation for Testing Wireless Networks Aw, we were just having fun . . .

In December 2004, a Michigan man became the

wireless networks, had found the wireless

first person ever convicted of wardriving (the

access point of a hardware chain store, had

unauthorized snagging of confidential informa-

used that connection to enter the chain’s cen-

tion via wireless access points, discussed in

tral computer system, and had installed a pro-

Chapters 9 and 10). Prosecutors presented evi-

gram to capture credit-card information.

dence that he and his cronies had scanned for

“get out of jail free” card. This card will state that you are authorized to perform a test according to the plan. It should also say that the organization will

“stand behind you” in case you are criminally charged or sued. This means they will provide legal and organizational support as long as you stayed within the bounds of the original plan (see Commandment Two).

Thou shalt work ethically

The term ethical in this context means working professionally and with good conscience. You must do nothing that is not in the approved plan or that has been authorized after the approval of the plan.

As an ethical hacker, you are bound to confidentiality and non-disclosure of information you uncover, and that includes the security-testing results. You cannot divulge anything to individuals who do not “need-to-know.” What you learn during your work is extremely sensitive — you must not openly share it.

Everything you do as an ethical hacker must be aboveboard, and must support the goals of the organization. You should notify the organization whenever you change the testing plan, change the source test venue, or detect high-risk conditions — and before you run any new high-risk or high-traffic tests, as well as when any testing problems occur.

You must also ensure you are compliant with your organization’s governance and local laws. Do not perform an ethical hack when your policy expressly forbids it — or when the law does.

Thou shalt keep records

Major attributes of an ethical hacker are patience and thoroughness. Doing this work requires hours bent over a keyboard in a darkened room. You may have to do some off-hours work to achieve your goals, but you don’t have to 07_597302_ch02.qxd 8/4/05 7:26 PM Page 23

Chapter 2: The Wireless Hacking Process

wear hacker gear and drink Red Bull. What you do have to do is keep plugging away until you reach your goal.

In the previous commandment we talked about acting professionally. One hallmark of professionalism is keeping adequate records to support your findings. When keeping paper or electronic notes, do the following: ߜ Log all work performed.

ߜ Record all information directly into your log.

ߜ Keep a duplicate of your log.

ߜ Document — and date — every test.

ߜ Keep factual records and record all work, even when you think you were not successful.

This record of your test design, outcome, and analysis is an important aspect of your work. Your records will allow you to compile the information needed for a written or oral report. You should take care in compiling your records.

Be diligent in your work and your documentation.

Thou shalt respect the privacy of others

Treat the information you gather with the utmost respect. You must protect the secrecy of confidential or personal information. All information you obtain during your testing — for example, encryption keys or clear text passwords —

must be kept private. Don’t abuse your authority; use it responsibly. This means you won’t (for example) snoop into confidential corporate records or private lives. Treat the information with the same care you would give to your own personal information.

Thou shalt do no harm

The prime directive for ethical hacking is, “Do no harm.” Remember that the actions you take may have unplanned repercussions. It’s easy to get caught up in the gratifying work of ethical hacking. You try something, and it works, so you keep going. Unfortunately, by doing this you may easily cause an outage of some sort, or trample on someone else’s rights. Resist the urge to go too far — and stick to your original plan.

Also, you must understand the nature of your tools. Far too often, people jump in and start using the tools shown in this book without truly understanding the full implications of the tool. They do not understand that setting up a monkey-in-the-middle attack, for example, creates a denial of service. Relax, take a deep breath, set your goals, plan your work, select your tools, and (oh yeah) read the documentation.

07_597302_ch02.qxd 8/4/05 7:26 PM Page 24

24 Part I: Building the Foundation for Testing Wireless Networks Many of the tools we discuss here allow you to control the depth and breadth of the tests you perform. Remember this point when you want to run your tests on the wireless access point where your boss connects!

Thou shalt use a “scientific” process

By this commandment, we don’t mean that you necessarily have to follow every single step of the scientific process, but rather that you adopt some of its principles in your work. Adopting a quasi-scientific process provides some structure and prevents undue chaos (of the sort that can result from a random-walk through your networks).

For our purposes, the scientific process has three steps: 1. Select a goal and develop your plan.

2. Test your networks and systems to address your goals.

3. Persuade your organization to acknowledge your work.

We address the first two steps in previous commandments, so let’s look at the third step here. Your work should garner greater acceptance when you adopt an empirical method. An empirical method has the following attributes: ߜ Set quantifiable goals: The essence of selecting a goal (such as capturing the flag) is that you know when you’ve reached it. You either possess the flag or you don’t. Pick a goal that you can quantify: associating with ten access points, broken encryption keys or a file from an internal server.

Time-quantifiable goals, such as testing your systems to see how they stand up to three days of concerted attack, are also good.

ߜ Tests are consistent and repeatable: If you scan your network twice and get different results each time, this is not consistent. You must provide an explanation for the inconsistency, or the test is invalid. If we repeat your test, will we get the same results? When a test is repeatable or replicable, you can conclude confidently that the same result will occur no matter how many times you replicate it.

ߜ Tests are valid beyond the “now” time frame: When your results are true, your organization will receive your tests with more enthusiasm if you’ve addressed a persistent or permanent problem, rather than a tem-porary or transitory problem.

Thou shalt not covet thy neighbor’s tools

No matter how many tools you may have, you will discover new ones. Wireless hacking tools are rife on the Internet — and more are coming out all the time.

The temptation to grab them all is fierce. Take, for instance, “wardriving” tools.

07_597302_ch02.qxd 8/4/05 7:26 PM Page 25

Chapter 2: The Wireless Hacking Process

Early on, your choices of software to use for this “fascinating hobby” were limited. You could download and use Network Stumbler, commonly called NetStumbler, on a Windows platform, or you could use Kismet on Linux. But these days, you have many more choices: Aerosol, Airosniff, Airscanner, APsniff, BSD-Airtools, dstumbler, Gwireless, iStumbler, KisMAC, MacStumbler, MiniStumbler, Mognet, PocketWarrior, pocketWiNc, THC-RUT, THC-Scan, THC-WarDrive, Radiate, WarLinux, Wellenreiter WiStumbler, and Wlandump, to name a few. And those are just the free ones. You also could purchase AirMagnet, Airopeek, Air Sniffer, AP Scanner, NetChaser, Sniff-em, Sniffer Wireless . . . Well you get the idea. Should you have unlimited time and budget, you could use all these tools. But we suggest you pick one tool and stick with it. (We give you a closer look at some from this list in Chapters 9 and 10.) Thou shalt report all thy findings

Should the duration of your test extend beyond a week, you should provide weekly progress updates. People get nervous when they know someone is attempting to break into their networks or systems — and they don’t hear from the people who’ve been authorized to do so.

You should plan to report any high-risk vulnerabilities discovered during testing as soon as they are found. These include

ߜ discovered breaches

ߜ vulnerabilities with known — and high — exploitation rates ߜ vulnerabilities that are exploitable for full, unmonitored, or untraceable access

ߜ vulnerabilities that may put immediate lives at risk

You don’t want someone to exploit a weakness that you knew about and intended to report. This will not make you popular with anyone.

Your report is one way for your organization to determine the completeness and veracity of your work. Your peers can review your method, your findings, your analysis, and your conclusions, and offer constructive criticism or suggestions for improvement.

If you find that your report is unjustly criticized, following the Ten Commandments of Ethical Hacking, should easily allow you to defend it.

One last thing: When you find 50 things, report on 50 things. You need not include all 50 findings in the summary but you must include them in the detailed narrative. Withholding such information conveys an impression of laziness, incompetence, or an attempted manipulation of test results.

Don’t do it.

07_597302_ch02.qxd 8/4/05 7:26 PM Page 26

26 Part I: Building the Foundation for Testing Wireless Networks Understanding Standards

Okay, we’ve told you that you need to develop a testing process — here’s where we give you guidance on how to do so. We wouldn’t keep you hanging by a wire (this is, after all, a wireless book). The following standards (which we get friendly with in the upcoming sections) provide guidance on performing your test:

ߜ ISO 17799

ߜ COBIT

ߜ SSE-CMM

ߜ ISSAF

ߜ OSSTMM

You may find that the methodology you choose is preordained. For instance, when your organization uses COBIT, you should look to it for guidance. You don’t need to use all of these methodologies. Pick one and use it. A good place to start is with the OSSTMM.

Using ISO 17799

The ISO/IEC 17799 is an internationally adopted “code of practice for information security management” from the International Organization for Standardization (ISO). The international standard is based on British Standard BS-799.

You can find information about the standard at www.iso.org.

ISO/IEC 17799 is a framework or guideline for your ethical hack — not a true methodology — but you can use it to help you plan. The document does not specifically deal with wireless, but it does address network-access control.

The document is a litany of best practices at a higher level than we would want for a framework for ethical hacking.

One requirement in the document is to control access to both internal and external networked services. To cover this objective, you need to try to connect to the wireless access point and try to access any resource on the wired network.

The document also requires that you ensure there are appropriate authentication mechanisms for users. You can test this by attempting to connect to a wireless access point (AP). When there is Open System authentication (see Chapter 16) you need not do any more work. Obviously no authentication is not appropriate authentication. APs with shared-key authentication may require you to use the tools shown in Chapter 15 to crack the key. If the AP is using WPA security, then you will need to use another tool, such as WPAcrack.

07_597302_ch02.qxd 8/4/05 7:26 PM Page 27

Chapter 2: The Wireless Hacking Process

Should the AP implement Extensible Authentication Protocol (EAP), you may need a tool such as asleap (see Chapter 16).

Bottom line: These guidelines don’t give you a step-by-step recipe for testing, but they can help you clarify the objectives for your test.

Using COBIT

COBIT is an IT governance framework. Like ISO 17799, this framework will not provide you with a testing methodology, but it will provide you with the objectives for your test.

You can find information about COBIT at www.itgi.org/.

Using SSE-CMM

Ever heard of the CERT? (Give you a hint: It’s not a breath mint or a candy.) It’s the Computer Emergency Response Team that’s part of the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh, Pennsylvania. Well, the SEI is known for something else: It developed a number of capability maturity models (CMM) — essentially specs that can give you a handle on whether a particular system capability is up to snuff. The SEI included a CMM just for security — the Systems Security Engineering CMM

(SSE-CMM for short). Now, the SSE-CMM won’t lay out a detailed method of ethical hacking, but it can provide a framework that will steer you right. The SSE-CMM can help you develop a scorecard for your organization that can measure security effectiveness.

You can find out about SSE-CMM at www.sei.cmu.edu/.

The Computer Emergency Response team also sends out security alerts and advisories. The CERT has a methodology as well — OCTAVE. OCTAVE stands for Operationally Critical Threat, Asset, and Vulnerability Evaluation. You can use OCTAVE as a methodology to build a team, identify threats, quantify vulnerabilities, and develop an action plan to deal with them.

You can find OCTAVE at www.cert.org/octave.

Using ISSAF

The Open Information System Security Group (www.oissg.org) has published the Information Systems Security Assessment Framework (ISSAF).

Developed as an initiative by information-security professionals, the ISSAF is a practical tool — a comprehensive framework you can use to assess how 07_597302_ch02.qxd 8/4/05 7:26 PM Page 28

28 Part I: Building the Foundation for Testing Wireless Networks your security effectiveness. It’s an excellent resource to use as you devise your test. (Draft 0.1 has, in fact, 23 pages on WLAN security assessment.) The ISSAF details a process that includes the following steps: 1. Information gathering

a. Scan

b. Audit

2. Analysis and research

3. Exploit and attack

4. Reporting and presentation

These steps correspond to our Ten Commandments of Ethical Hacking. For each of the steps just given, the document identifies appropriate tasks and tools. For example, the scanning step lists the following tasks: ߜ Detect and identify the wireless network

ߜ Test for channels and ESSID

ߜ Test the beacon broadcast frame and recording of broadcast information ߜ Test for rogue access points from outside the facility ߜ IP address collection of access points and clients

ߜ MAC address collection of access points and clients

ߜ Detect and identify the wireless network

The document recommends you use programs such as Kismet, nmap, and ethereal as tools for Step 1.

You also will find information in the document on the software you can use and the equipment you will need to build or acquire to do your assessment of your organization’s wireless-security posture.

The document we reviewed was a beta version, but it shows promise and is worth watching. You can find the ISSAF at www.oissg.org/issaf.

Using OSSTMM

We do recommend you take a long and hard look at the OSSTMM — the Open Source Security Testing Methodology Manual (www.osstmm.org). The Institute for Security and Open Methodologies (ISECOM), an open-source collaborative 07_597302_ch02.qxd 8/4/05 7:26 PM Page 29

Chapter 2: The Wireless Hacking Process

community, developed the OSSTMM’s methods and goals much along the lines of the ISSAF: as a peer-review methodology. Now available as version 3.0, the OSSTMM has been available since January 2001 and is more mature than the ISSAF.

You’ll find that the OSSTMM gathers the best practices, standard legal issues, and core ethical concerns of the global security-testing community — but this document also serves another purpose: consistent definition of terms.

The document provides a glossary that helps sort out the nuances of vulnerability scanning, security scanning, penetration testing, risk assessment, security auditing, ethical hacking, and security hacking. The document also defines white-hat, gray-hat, and black-hat hackers, so that by their metaphori-cal hats ye shall know them. But even more importantly (from your viewpoint as an ethical-hacker-to-be), it provides testing methodologies for wireless security, distilled in the following bullets:

ߜ Posture review: General review of best practices, the organization’s industry regulations, the organization’s business justifications, the organization’s security policy, and the legal issues for the organization and the organization’s regions for doing business.

ߜ Electromagnetic radiation (EMR) testing: Testing of the electromagnetic radiation emitted from wireless devices.

ߜ 802.11 wireless-networks testing: Testing of access to 802.11 WLANs.

ߜ Bluetooth network testing: Testing of Bluetooth ad-hoc networks.

ߜ Wireless-input-device testing: Testing of wireless input devices, such as mice and keyboards.

ߜ Wireless-handheld testing: Testing of handheld wireless devices, such as personal digital assistants and personal electronic devices.

ߜ Cordless-communications testing: Testing of cordless communications communication devices, such as cellular technology.

ߜ Wireless-surveillance device testing: Testing of wireless surveillance or monitoring devices, such as cameras and microphones.

ߜ Wireless-transaction device testing: Testing of wireless-transaction devices, such as uplinks for cash registers and other point of sale devices in the retail industry.

ߜ RFID testing: Testing of RFID (Radio Frequency Identifier) tags.

ߜ Infrared testing: Testing of infrared communications communication devices.

ߜ Privacy review: General privacy review of the legal and ethical storage, transmission, and control of data, based on employee and customer privacy.

07_597302_ch02.qxd 8/4/05 7:26 PM Page 30

30 Part I: Building the Foundation for Testing Wireless Networks Each step has associated tasks that provide more detail and specific tests. As well, each step has a table that outlines the expected results. For example, expected results for Step 3 include these:

ߜ Verification of the organization’s security policy and practices — and those of its users.

ߜ Identification of the outermost physical edge of the wireless network.

ߜ Identification of the logical boundaries of the wireless network.

ߜ Enumeration of access points that lead into the network.

ߜ Identification of the IP-range (and possibly DHCP-server) of the wireless network.

ߜ Identification of the encryption methods used for data transfer.

ߜ Identification of the authentication methods of exploitable “mobile units” (that is, the clients) and users.

ߜ Verification of the configuration of all devices.

ߜ Determination of the flaws in hardware or software that facilitate attacks.

Obviously, you need to cut and paste these tests according to your needs.

For instance, should your organization not have infrared, then you would skip Step 11.

The OSSTMM is available from www.isecom.org/osstmm/.

With resources like these, you have a methodology — and everything you need to map out your plan. But rather than leave you hanging there, the rest of the book shows you how to work through a methodology. In Chapter 3, you develop a methodology for a review. In Chapter 4, you select your weapons of mass disruption. Chapters 6 through 16 show you how to use the tools to test your security posture. The only thing left after that is to evaluate your results. So . . .

08_597302_ch03.qxd 8/4/05 7:00 PM Page 31