WHIFF Wireless Intrustion Detection System A project by Foundstone, Inc. and Carnegie Mellon University

Transcription

1 WHIFF Wireless Intrustion Detection System A project by Foundstone, Inc. and Carnegie Mellon University Christopher R. Ameter Russell A. Griffith John K. Pickett CMU Faculty Advisor: Chris Prosise, Foundstone Inc.

2 WHIFF A Wireless Intrusion Detection System Developed 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 Foundstone s 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 Whiff s features and functionality. We believe that the capabilities demonstrated in Whiff will provide needed security solutions to organizations implementing wireless networks.

3 TABLE OF CONTENTS Introduction 1 Scope and Objectives 2 Background 3 Solution 4 Detail 5 Conclusions 21 Resources 22

4 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 threemember 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 Foundstone, Inc. All Rights Reserved 1

5 Scope and Objectives This white paper focuses on the security features of Whiff. It describes the system s 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 Foundstone, Inc. All Rights Reserved 2

6 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 b 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 b. 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 Foundstone, Inc. All Rights Reserved 3

7 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 . 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 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 Foundstone, Inc. All Rights Reserved 4

8 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 b 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 b 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 b 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 Foundstone, Inc. All Rights Reserved 5

9 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 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 Foundstone, Inc. All Rights Reserved 6

10 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 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 alert is shown in Figure 2 in the Features discussion below. Interface The 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 Foundstone, Inc. All Rights Reserved 7

11 Figure 1 - Whiff Modules and Architecture Foundstone, Inc. All Rights Reserved 8

12 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 administrator s 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-tothe-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 Foundstone, Inc. All Rights Reserved 9

13 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 Foundstone, Inc. All Rights Reserved 10

14 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 client s IP address, operating system, and open ports (captured through Nmap scanning). Figure 4 - Rogue Client Detail Foundstone, Inc. All Rights Reserved 11

15 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 base additional protection is required. Similar to Whiff s 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 Foundstone, Inc. All Rights Reserved 12

16 Wireless-specific (Kismet-based) In addition to traditional signature-based alerts, Whiff uses the Kismet wireless sniffer to analyze wirelessspecific (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 Foundstone, Inc. All Rights Reserved 13

17 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 overused 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 Foundstone, Inc. All Rights Reserved 14

18 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, we ve implemented a Propagation Configuration page (see Figure 8), which allows system administrators to test and update default Gpsmap options. Figure 8 - Whiff Propagation Configuration Foundstone, Inc. All Rights Reserved 15

19 Listener Status Continuous reporting of activity from listeners is essential to Whiff performance. The homepage therefore includes 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 listener s reporting times to make sure it is functioning as expected. Notifications In addition to providing alert reporting through the web interface, Whiff generates notification s that report details on the combined alerts from all listeners. Real-Time Occasionally system administrators may not have access to the web interface but still need to know what is happening on their network. A real-time notification mechanism fills this need. Each Whiff listener sends realtime alert data to the server, where the correlation engine refines the data, eliminating any redundant alerts from overlapping listeners. Notification s currently report all alerts except traditional IDS alerts (see Figure 9). Figure 9 - Whiff Notification This is an automated intrusion notification. WARNING: Unknown CLIENT detected!! MAC: 00:02:2D:5D:24:00 AP: 00:60:1D:F2:05:00 IP: OS: 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:00 MAC: 00:60:1D:23:C3:00 WARNING: Unknown CLIENT detected!! MAC: 00:02:2D:0F:38:00 AP: 00:60:1D:F2:05:00 IP: OS: Ports: This concludes this intrusion notification Foundstone, Inc. All Rights Reserved 16

20 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 Foundstone, Inc. All Rights Reserved 17

21 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 Foundstone, Inc. All Rights Reserved 18

22 Security Whiff, a security tool for wireless networks, also incorporates features that enhance its own security. Certificate-based User Authentication The 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 Transfers Whiff s 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 Security Whiff 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 didn t 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 experts better 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 one s own network from one s that of one s neighbor Foundstone, Inc. All Rights Reserved 19

23 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, doesn t 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 Foundstone, Inc. All Rights Reserved 20

24 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 Whiff s 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 flowing over 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 Foundstone s industry leading security software Foundstone, Inc. All Rights Reserved 21

25 Resources Kismet MySQL Apache PHP O Reilly Perl.com curl Nmap Foundstone Carnegie Mellon Snort Snax Orinoco patch GPSD Foundstone, Inc. All Rights Reserved 22