Wp Whiff Wireless Intrusion Detect

7/31/2019 Wp Whiff Wireless Intrusion Detect

1/25

WHIFF Wireless Intrustion Detection System

A project by Foundstone, Inc.and Carnegie Mellon University

Christopher R. Ameter Russell A. Griffith John K. PickettCMU Faculty Advisor: Chris Prosise, Foundstone Inc.


2/25

WHIFF

A Wireless Intrusion Detection SystemDeveloped by Foundstone, Inc. and Carnegie Mellon University

This paper presents an overview of the Whiff Intrusion Detection System, which was developed during the

summer and fall of 2002 by a team of graduate students majoring in Information Security and Assurance at

Carnegie Mellon University. The project was a collaborative effort between Carnegie Mellon and

Foundstone, Inc. The experience and knowledge gained during this project will enhance and refine future

versions of Foundstones industry leading security software.

Whiff is a system that solves several current, real-world wireless security problems. Whiff identifies and

monitors wireless networks and devices, alerting administrators to exposures in real time. Whiff is

comprised of multiple listeners which monitor all wireless activity and report to a central correlation engine.

The correlation engine delivers to multiple users a complete asset inventory of wireless devices and access

points as well as a GPS map of signal propagation. The system integrates intrusion detection capabilities,

alerting administrators to wireless and traditional intrusion attempts, rogue access points, and rogue clients.

This document details Whiffs features and functionality. We believe that the capabilities demonstrated in

Whiff will provide needed security solutions to organizations implementing wireless networks.


3/25

TABLE OF CONTENTS

Introduction 1

Scope and Objectives 2

Background 3

Solution 4

Detail 5

Conclusions 21

Resources 22


4/25

www.foundstone.com 2003 Foundstone, Inc. All Rights Reserved | 1

Introduction

During the spring of 2002, a team of Carnegie Mellon University graduate students majoring in Information

Security & Assurance became concerned about the lack of security on wireless networks. They perceived the

need for a wireless intrusion detection system that could keep administrators informed about what was

happening on their network. At about the same time, Foundstone, Inc. approached Carnegie Mellon with a

proposal to work together to develop such a system. Throughout the summer the Carnegie Mellon students

conducted studies of wireless networks and found many lacked the basic configurations necessary to provide

even minimal levels of security. In August development work began, and over the next four months the three-

member graduate team, assisted by a member of Foundstone, devoted 90 hours a week to the project.

Using standard methodologies developed by Carnegie Mellon and Foundstone, the team developed Whiff, a

wireless intrusion detection system that provides network administrators with constant security reports,

allowing them to make informed security decisions.


5/25


Scope and Objectives

This white paper focuses on the security features of Whiff. It describes the systems purpose, how it works

(including collection methodologies, reporting mechanisms, and underlying security architecture), and how it

can be used to improve wireless network security. We also provide references for those who wish to read more

about the tools and technologies used.

This project is not intended to be the "silver bullet" that dramatically increases the state of security of wireless

networks. Identification of intruders is an important step toward that goal, but it is only one part of a larger

effort. The overall security of a system involves blending many technical components with sound policy to

create a total package.

Our goal is to provide administrators with an image of what is happening on their network. Armed with this

information, they will be able to make better decisions and take actions to improve network security.


6/25


Background: Problems with Wireless Network Security

In the early days of local area networks security was addressed by controlling physical access to facilities, and

insiders were the primary threat. With the advent of the Internet and the adoption of wide area networks,

administrators were forced to defend their network not only against those with physical access, but against the

larger community of people with Internet access or even just modems. Hackers began using automated scripts

to call phone numbers at random, searching for modems through which they could access networks. This

became known as war dialing. Still, attackers had to enter the network from a known point, such as a

telephone number or IP address, making them at least somewhat traceable.

In recent years an entirely new class of attacks has emerged. Proliferation of wireless technologies has enabled

attackers to enter networks, quite literally, out of thin air. Using simple, free software, a new generation of

hackers is able to locate wireless networks, eavesdrop on communications, and commandeer resources. The

practice of wandering around in search of wireless networks is referred to as war driving, which is a play on

the earlier modem discovery technique. With the proper antenna, the attack can come from as far as several

miles away. Thus detection and identification of the intruder presents unique challenges which render many

traditional intrusion detection techniques ineffective.

Compounding the problem is the fact that the 802.11b wireless Ethernet standard contains fundamental

security vulnerabilities. Recognizing that eavesdropping is an inherent problem in any wireless system because

of the inability to control the propagation of radio waves, the designers of the standard included WEP, the

wired equivalent privacy protocol, in 802.11b. WEP is a layer two security protocol that employs the RC4

encryption algorithm. While the algorithm itself is sound, the implementation is flawed, allowing WEP to be

broken in a matter of minutes. To a determined attacker, it is a mere inconvenience.

Traditional network security models rely heavily on perimeter protection. Administrators of wireless networks

must recognize, however, that many attacks originate behind these outer defenses. Much of the security must

therefore be handled at the host and application levels.

Solid host security and higher level encryption protocols such as IPSec address many of the vulnerabilities

introduced through the use of wireless networks. Still, if network administrators are to make informed security

decisions, implement sound policies, and deploy available security technology effectively, they must be able to

identify wireless assets, monitor network activity, and detect intruders.


7/25


Solution: WHIFF Wireless Intrusion Detection System

Whiff dynamically creates and reports a complete asset inventory of wireless devices, detects the presence of

rogue wireless clients or access points, detects wireless and traditional intrusion attempts, and alerts

administrators to exposures.

Alerts

Whiff includes one or more listeners, which continuously monitor all wireless activity in their vicinity and

report back to a central correlation engine. The listeners generate four classes of alerts:

Rogue access points Rogue clients Traditional IDS alerts

Wireless-specific alerts

Rogue Clients and Access Points

Rogue clients and access points are identified by detecting the presence of MAC addresses not included in a

known good list. The list of known access points is updated periodically by the correlation engine. Upon

detection of a rogue MAC address, the listener generates an alert, which it transmits to the correlation engine.

The engine filters all incoming alerts (removing duplicates), loads a record of the alerts into a database, and

notifies administrators via e-mail.

Traditional IDS Alerts

Traditional IDS alerting is facilitated through the use of Snort, an open source intrusion detection system.

Snort definitions may be customized and prioritized based on the needs of a specific environment. Traditional

IDS alerts are collected by each listener and periodically transmitted back to the correlation engine, where they

are sorted in a manner similar to that of the rogue MAC alerts and added to the database.

Wireless-Specific Alerts

Wireless-specific alerts are a function of the Kismet wireless sniffer, an open source program upon which much

of this project is based. Wireless-specific alerts are generated by conditions matching special signatures that

would arise only in a wireless network, such as the presence of a NetStumbler probe. Wireless-specific alerts

are handled in a batch fashion, just like traditional IDS alerts.

Web Interface

In addition to automated e-mail notifications, alerts may be viewed through a web interface on the correlation

engine. The web interface may also be used to update configuration files automatically distributed to the

listeners, view various statistics regarding the status of the network, configure administrator accounts, add

MAC addresses to the known good list, and view a propagation map displaying the wireless network

footprint. Communication with the web interface is secured through certificate-based authentication and SSL

encryption.


8/25


WHIFF in Detail

Architecture

The components of the Whiff system architecture were selected to provide the best possible functionality, given

a number of technical and financial constraints. These constraints included the need to limit the amount of

additional strain on the network and to make any machines and traffic added to the network as secure as

possible. While our goal was to achieve a technologically superior solution, we were also heedful of the need

to minimize hardware requirements and software expenditures.

The Whiff architecture comprises the following four modules, diagramed in Figure 1 (page 8):

Listener Notification Correlation Interface

Listener

The listeners act as continuous collection points for wireless data. These machines passively monitor 802.11b

traffic within antenna range and report a variety of anomalies back to the correlation server.

Our listener implementation consists of standard PCs and laptops using either a Lucent Orinoco or Prism II

based wireless card, although almost any card capable of running in monitor mode would work. These

systems run a standard installation of Redhat Linux 8.0 and primarily use two excellent and freely available

software packages, Kismet and Snort. Access to open source was invaluable to the success of this project, as it

was necessary, for example, in the case of Kismet, to add some reporting features to the software.

Kismet operates by placing wireless cards in monitor mode and then continuously hopping between 802.11b

channels to gather data throughout the entire used 2.4GHz spectrum. Unlike standard packet sniffers, such as

TCPDump and Ethereal, Kismet is also able to monitor level II wireless traffic, including 802.11b management

frames and packets (Probe Request, Probe Response, Beacon Frame, etc.).

Kismet simultaneously records GPS data, which is later used by the interface module to produce signal

propagation maps. Theoretically, mobile listeners could be set up using any NMEA GPS or GPSD software

package. Because Whiff listeners are relatively stationary, however, and would likely be placed inside

buildings, usually out of satellite range, a GPS might not work. To deal with this limitation, we developed a

GPS simulator, GPSDork, which simulates the NMEA GPS signals at any given latitude and longitude.

To limit bandwidth usage, much of the initial processing is performed on the listeners, with only anomalies

and summary data reported to the next module, the correlation engine. The data collected by Kismet is

analyzed in real time to watch for a variety of suspicious activities, as described in the Alerts section above.

The TCP/IP traffic is then passed through Snort, a signature based IDS, to watch for any malicious activity on

the wireless network.


9/25


All of these actions are orchestrated through a series of Perl scripts, which ultimately transfer the processed

data to the correlation engine. For security reasons, the listeners do not allow any incoming connections, and

simply push the data back to the server at set intervals. System configuration files for the listeners may be

changed through the web-based interface module, which the listeners periodically inspect for changes and use

to update themselves as necessary. All communications with the listeners are authenticated and encrypted

through a certificate-based SSL connection. This is accomplished with cURL, using HTTP PUT commands to

a special uploads directory on the Apache web server.

Correlation

The correlation module receives data from the listener and processes it into a series of MySQL tables for use

by the interface module. If there are multiple listeners, the Perl scripts first compare all of the alerts and

eliminate duplicates. They also throttle the alerts to prevent excessive e-mail messages from being sent to the

administrator. (Related alerts in rapid succession are grouped into a single alert for notification.)

If a rogue client is detected, a correlation script determines if the client has associated itself with the network.

If the client has been assigned an IP number, the script launches an Nmap port scan and attempts to determine

the host operating system. This information, which may aid in tracking down the rogue host, is delivered to

the administrator as part of the alert notification and is also entered into the database.

A second benefit of the Nmap scan is that it serves as a shot across the bow, letting possible intruders know

they are being tracked. If an intruder were running a personal firewall, they would probably be notified that

they are being port-scanned, which might encourage them to look elsewhere.

The correlation script then uses GPSMap to build a propagation map from the GPS and wireless network data.

The display characteristics of this map are configurable in the interface, as shown in Figure 8.

Finally, the correlation scripts archive all of the data, ensuring that in the event of a major security incident,

administrators have full access to a detailed history. In the case of signature-based (Snort) alerts, the archive

includes any suspicious traffic in TCPDump format, which allows much more detailed analysis than the alert

description. In a production environment this data would probably be moved to offline backup media, as it is

not directly accessed again by Whiff.

Our correlation engine is implemented on a pc server running Redhat Linux 8.0 (minimum specifications in

Figure 1). The correlation, notification, and interface modules all reside on this machine, so there is significant

overlap in both scripts and system software. The primary software packages used for correlation and

notification are the MySQL relational database, the Apache Web Server, GPSMap, Nmap, and OpenSSL. All

are open source and freely available.


10/25


Notification

The notification and correlation modules are conceptually distinct but technically intertwined. The function of

the notification script is to gather alert data from the correlation processes and deliver it to an administrator in

real time. If the administrator does not care about real-time alerting, this module can easily be disabled, as all

of the alert information is also available in the web-based interface.

The notification module may be configured to enable or disable Nmap scans and can deliver messages to any

e-mail address or administrator list. Alert messages are simple and text based, so they display correctly on a

pager or wireless PDA. Administrator notification requires access to an SMTP mail gateway for delivery of e-

mailed alerts. We have not discussed implementation of an SMTP server in our architecture, as most

organizations have one in place or have access to one through their ISP. A sample e-mail alert is shown in

Figure 2 in the Features discussion below.

InterfaceThe interface module provides a web-based console to view alerts, IDS incidents, and rogue clients and access

points. It also provides a wide variety of detail views and allows administrators to tag or add comments to

alerts following investigation. They can also add rogue devices to the known good list. Access to this system

is secured by a certificate-based SSL connection, coupled with a username/password login.

This module, which resides on the same correlation server, dynamically generates Whiff views from the

MySQL database through a series of PHP scripts. These PHP scripts also make it easy to change data or

remote listener configurations from the administrator console. Configuration changes are saved to files on the

server, where they are read by the listeners during each reporting interval.


11/25


Figure 1 - Whiff Modules and Architecture


12/25


Features

In designing Whiff, our goal was a feature set that would not only enhance the overall security of networks,

but would also make the network administrators job a little easier. While this feature set is by no means

complete, we feel it includes appropriate functionality for an initial implementation.

Reporting

Like any other IDS, Whiff generates a great deal of data; one of the biggest design issues was how to best

present this data to users. We chose a web-based interface for its consummate lightness and portability, being

accessible from any browser. The Whiff homepage provides a single place for administrators to view up-to-

the-second wireless network activity, including the most recent alerts of each type, signal propagation, and

current status of each listener.

Figure 2 - Whiff Home Page


13/25


Rogue Access Points

As the cost of wireless access points falls and the desire for convenience and mobility climbs, so too does the

likelihood of one or more rogue access points appearing on a network. Rogue access points pose a serious

threat to the security of networks, as they are likely to be located behind the firewalls erected to keep intruders

out.

Whiff presents a partial list of rogue access point alerts on its homepage and a full list on the Rogue APs page,

both of which link to more detailed information. At the detail page administrators can add comments to an

alert and change its status to in-progress (being looked into) or closed (no longer displayed in the

interface). They can also add the MAC of the rogue access point to the known good list, which is then

pulled from the server by listeners during each reporting period.

Figure 3 - Rogue Access Point Detail


14/25


Rogue Clients (including OS Identification)

Wireless networks offer the advantage of allowing users to move freely around a facility while maintaining

network connectivity. While this convenience makes life easier for users, it also makes life easier for intruders,

who can gain access to the network simply through a handheld device, wireless card, and software freely

available on the Internet.

Whiff detects rogue clients and lists them on both the homepage and Rogue Client page. Clicking on an entry

in the list takes administrators to a detail page, which displays the rogue clients IP address, operating system,

and open ports (captured through Nmap scanning).

Figure 4 - Rogue Client Detail


15/25


Traditional IDS (Snort-based)

Whiff employs the Kismet wireless sniffer, along with Snort, to provide traditional (layer 3) intrusion detection

support for wireless traffic. This is necessary because the IDS already in place on the wired network cannot be

relied upon to pick up all wireless attacks. In cases where wireless traffic does not touch the wired network

for example, where a wireless client is attacking another wireless client on the same access point or where an

access point has been compromised and is being used against its client baseadditional protection is required.

Similar to Whiffs other reporting features, Snort-based alerts are presented in two places: the homepage and a

Snort Alert page. A unique feature, however, is that Snort-based alerts are sorted by priority level, with higher

priorities listed first. Detailed information necessary to determine what happened, when it occurred, and who

was involved can be viewed by clicking on any alert in the list. Among the detail available is attack signature

and class, source and destination IP address and port, and links to reference information. The actual data that

triggered the alert is, of course, archived for further analysis if required.

Figure 5 - Snort-Based Alert Detail


16/25


Wireless-specific (Kismet-based)

In addition to traditional signature-based alerts, Whiff uses the Kismet wireless sniffer to analyze wireless-

specific (802.11b), generally layer 2, traffic. This type of alert is generated by Kismet when it sees specific

frame signatures, including those of some popular wireless discovery tools such as NetStumbler and

Wellenreiter. These tools can be detected because their method of network discovery involves broadcasting

beacon frames, which anything listening, including Kismet, can hear. Whiff can also generate wireless-specific

alerts by scanning for vulnerability in access points caused by software that responds to broadcast queries by

echoing back administrative information.

These alerts are displayed along with the other alerts on the Whiff homepage and can also be viewed on the

Kismet Alerts page. By selecting an individual alert, administrators can view a description of the attack,

including the source MAC and, in some cases, IP address. As with other alert types, comments can be added

and status changed as each alert is handled.

Figure 6 - Kismet-Based Alert Detail


17/25


Network Status (APs and Clients)

In addition to the alert reporting described above, Whiff enables system administrators to view both access

point and client-specific information. The Access Point page displays the most recent access point data from

each listener, including MAC address, service set identifier (SSID), WEP usage, reporting listener, broadcast

channel, and manufacturer. Selecting the desired MAC address link displays details for that access point,

including a breakdown of packets seen and a list of associated clients (see Figure 7).

The packet breakdown can be used to monitor the state of the wireless network, determining under- or over-

used segments. Knowing which clients are associated with each access point is also useful in troubleshooting

and locating rogue clients.

From the access point detail page, additional detail can be viewed by selecting the desired client MAC.

Available client data includes configuration information similar to that provided for access point detail as well

as IP address and the means by which the client was identified.

Figure 7 - Whiff Access Point Detail


18/25


Graphical Signal Propagation

One of the security risks inherent in wireless networks is the propagation of wireless signals beyond the walls

of the organization. While it is difficult to determine with precision the reach of a wireless network, it is

possible to come up with an estimate based on network factors such as signal strength and GPS-based point

data.

Whiff uses the Gpsmap utility to generate a graphical representation of the wireless signal propagation. This

propagation map is displayed at a reduced scale on the homepage and at full size on the Signal Propagation

page.

Some of the Gpsmap provisions for displaying network propagation may be more accurate than others

depending on network-specific factors. For this reason, weve implemented a Propagation Configuration page

(see Figure 8), which allows system administrators to test and update default Gpsmap options.

Figure 8 - Whiff Propagation Configuration


19/25


Listener StatusContinuous reporting of activity from listeners is essential to Whiff performance. The homepage thereforeincludes a display of the current status of each listener, including its name and a Last Reported timestamp.Administrators can also access a full history of the listeners reporting times to make sure it is functioning asexpected.

NotificationsIn addition to providing alert reporting through the web interface, Whiff generates notification emails thatreport details on the combined alerts from all listeners.

Real-TimeOccasionally system administrators may not have access to the web interface but still need to know what ishappening on their network. A real-time notification mechanism fills this need. Each Whiff listener sends real-time alert data to the server, where the correlation engine refines the data, eliminating any redundant alertsfrom overlapping listeners. Notification e-mails currently report all alerts except traditional IDS alerts(see Figure 9).

Figure 9 - Whiff Notification Email

This is an automated intrusion notification.

WARNING: Unknown CLIENT detected!!MAC: 00:02:2D:5D:24:00AP: 00:60:1D:F2:05:00IP: 128.2.69.000OS:Ports:

WARNING: Kismet alert detected!!NetStumbler (3.23) probe deted from 00:02:2D:05:64:00

WARNING: Unknown ACCESS POINT detected!!SSID: 00:05:3C:04:2C:00MAC: 00:60:1D:23:C3:00

WARNING: Unknown CLIENT detected!!MAC: 00:02:2D:0F:38:00AP: 00:60:1D:F2:05:00IP: 128.2.64.000OS:Ports:

This concludes this intrusion notification.


20/25


Centralized Administration

The majority of Whiff installations will be of a distributed nature with multiple listeners reporting back to a

single server. Manageability issues with this type of architecture make centralized administration a key system

requirement.

Whiff User

Whiff user administration is performed through the web interface, with user data, including hashed passwords,

stored in the user table of the database. As illustrated in Figure 10, administrators can add or remove users, or

update user information, such as changing the associated group.

Figure 10 - Whiff User Administration


21/25


Whiff Listener

Each Whiff listener has its own identity, defined through its configuration files. Whiff also provides a number

of configurable time-interval-based options, which can be tweaked during initial setup to suit specific network

needs. While configuration files, once set, generally remain fairly stable, the distributed nature of Whiff

suggested the need for an easy method of making changes. The system therefore includes a Listener

Configuration page, which allows administrators to modify all configuration file from a single interface.

Updated files are subsequently pulled from the server by the appropriate listener.

Figure 11 - Whiff Configuration Administration


22/25


Security

Whiff, a security tool for wireless networks, also incorporates features that enhance its own security.

Certificate-based User AuthenticationThe wealth of information Whiff provides about the wireless network should not be available to just

anyone. The Whiff web server restricts access by performing user authentication based on client certificates

distributed only to valid parties.

Certificate-based File TransfersWhiffs centralized listener configuration, data storage, and notifications require sensitive files to be

transferred between listeners and the server. Client certificates are used to authenticate listeners when they

attempt to connect to the server to pickup configuration updates or deliver network and alert data.

Role-based SecurityWhiff offers role-based security to ensure that users with different functions have access to only those

features they need to do their jobs. (Currently the database and user administrative roles have been

implemented.)

Possible Enhancements

A number of desirable features emerged during the development and testing of Whiff. Some of those that

didnt make the cut for the first version include:

Trend reporting Known-but-not-ours MAC list Extended client OS identification

Trend Reporting

The addition of trend reporting to the Whiff web interface would provide system administrators with the

ability to track activity on their wireless network over time. Examples of such activity include the number of

clients associated with any access point, occurrences of alerts, and overall wireless traffic. Tracking client

counts and wireless traffic in this way would enable system administrators to make informed decisions about

tuning and upgrading wireless networking equipment. It could also help administrators and security expertsbetter understand network attackers. The more known about the opponent, the greater the likelihood of

ultimately gaining victory--historical tracking is a step toward this goal.

Known But Not Ours MAC List

During the course of our testing we noticed that we were continually receiving rogue client alerts for access

points not on our test network. As wireless networks proliferate, overlapping wireless signals become more

likely, creating the problem of distinguishing ones own network from ones that of ones neighbor.


23/25


This issue pertains to both access points and clients, and is currently being handled by adding the MAC

addresses of each to our known good list. As we quickly found out, this solution is less than optimal, as

the administrator may be flooded with rogue client alerts, each of which must be verified.

Our suggestion for a more workable solution is to add a list of known but not ours access point MAC

addresses. This would allow system administrators to verify only the whereabouts of rogue access points,

programmatically disregarding all clients associated with them.

Extended Client OS Identification

Whiff currently identifies rogue clients by validating clients on the network against a list of known good

MAC addresses maintained by the system administrator. This procedure, however, doesnt provide a means of

identifying clients that may be spoofing the MAC of a known client. Such an attack may not be as unlikely as

it seems, given that it's trivial for attackers to sniff known MAC addresses out of the air and update their

wireless settings accordingly.

As discussed previously in this paper, Whiff supports limited Nmap scanning of rogue clients for the purpose

of identifying and reporting the open ports and operating system of the offending system. One way to

overcome this spoofing shortcoming is to perform more extensive client scanning, essentially maintaining

system status for each client. Scanning would take place at a specified interval, and the results would be

compared with historical data for the corresponding client, with alerts generated if too much has changed.

(Both scanning interval and change threshold would be configurable.)

All of this presupposes the resolution of a number of outstanding issues with extended client identification.

Work needs to be done, for example, on handling dual or multi-boot machines, retrieving system status for

machines with personal firewalls, and preventing scans from being picked up by IDSes.


24/25


Conclusion

Throughout the project, the extent of the problems with wireless network security became increasingly

obvious. During a half-hour war drive around Pittsburgh, the project team uncovered 484 wireless access

points; 364 of which were not even running WEP, and many with default configurations.

Even more frightening is the fact that while beta testing some of Whiffs alerting features at home, one team

member was notified of an unknown client on his home network. Initially expecting a false positive, he

checked his access point logs and found that an intruder was indeed present. Upon being port scanned, the

intruder immediately disconnected from the network, never to be seen again.

Clearly there is an urgent need to gather information about what is happening on wireless networks. Whiff

provides a picture of the boundaries of a wireless network, the devices connected to it, and the traffic flowingover it. While identification of attacks and vulnerabilities is only one part of an overall security plan, it is a

critical first step in the effort to improve wireless network security.

The experience and knowledge gained during this project will enhance and refine

future versions of Foundstones industry leading security software.


25/25

Resources

Kismet http://www.kismetwireless.net

MySQL http://mysql.com

Apache http://httpd.apache.org/

PHP http://www.php.net

OReilly Perl.com http://www.perl.com

cURL http://curl.haxx.se

Nmap http://www.insecure.org/Nmap/

Foundstone http://www.foundstone.com

Carnegie Mellon http://www.cmu.edu

Snort http://www.snort.org

Snax Orinoco patch http://airsnort.shmoo.com/orinocoinfo.html

GPSD http://www.pygps.org/gpsd/

Wp Whiff Wireless Intrusion Detect

Documents

Transcript of Wp Whiff Wireless Intrusion Detect