1 / 22

Detecting and Blocking Unauthorized Access in Wi-Fi Networks Haidong Xia and Jos é Brustoloni

Detecting and Blocking Unauthorized Access in Wi-Fi Networks Haidong Xia and Jos é Brustoloni. Department of Computer Science University of Pittsburgh 210 S. Bouquet St. #6111, Pittsburgh, PA 15260, USA Tel.: +1 (412) 624-8852, Fax: +1 (412) 624-8854 Email: jcb@cs.pitt.edu

benjy
Download Presentation

Detecting and Blocking Unauthorized Access in Wi-Fi Networks Haidong Xia and Jos é Brustoloni

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Detecting and Blocking Unauthorized Access in Wi-Fi NetworksHaidong Xia and José Brustoloni Department of Computer Science University of Pittsburgh 210 S. Bouquet St. #6111, Pittsburgh, PA 15260, USA Tel.: +1 (412) 624-8852, Fax: +1 (412) 624-8854 Email:jcb@cs.pitt.edu Web:http://www.cs.pitt.edu/~jcb/

  2. Motivation • Securing Wi-Fi networks is feasible but labor-intensive • IPsec, dynamic WEP w/ IEEE 802.1x, WPA, IEEE 802.11i • HW, SW installation, configuration in user computers • Wi-Fi networks that serve large number of user-owned computers typically resort to not-so-secure but easier-to-use authentication schemes • Many university departments: MAC address filtering • University campuses and commercial hotspots: captive portals • Unauthorized access is easy in such networks • MAC address spoofing • Session hijacking, freeloading Jose' Brustoloni -- Networking'2004

  3. Contribution • Novel mechanisms for detecting and blocking unauthorized access in Wi-Fi networks • session id checking • MAC sequence number tracking • Work with default HW/SW configuration in user computers • possible applications in universities, commercial hotspots • Interoperate with IPsec, 802.1x, WPA, 802.11i • application in easy-to-use Internet-only access for authenticated guests while members use stronger but more-difficult-to-configure security • Experiments demonstrate modest overhead Jose' Brustoloni -- Networking'2004

  4. Native Wi-Fi security AP RADIUS 802.1x client AP router Internet encrypted Wi-Fi w/ dynamic keys AP • WEP hopelessly insecure → new schemes based on 802.1x • 802.1x access point restricts user’s access until RADIUS-authenticated • EAP supports a variety of user authentication schemes • EAP-TLS (certificate-based), PEAP (password-based) • Pre-shared keys for residential, SOHO networks • After user authenticated, all traffic between user and access point • encrypted with per-session keys and dynamic WEP, TKIP (WPA), • or AES-CCMP (802.11i) Jose' Brustoloni -- Networking'2004

  5. Hurdles for native Wi-Fi security • Install and configure new software, firmware, possibly hardware in user computers • Must implement same drafts as access points and RADIUS server do • Work in progress – e.g., PEAP, 802.11i still drafts • Interoperability currently problematic • Default configuration probably (no) pre-shared key • Different configurations likely necessary if used in hotspots and homes • Configuration confusing for end users – many knobs to turn • How to support on-the-spot sign-ups? Jose' Brustoloni -- Networking'2004

  6. MAC address filtering • Access points configured to accept only packets that contain certain MAC addresses • Often combined with suppression of 802.11 beacon packets (security by obscurity ...) • Sometimes combined with static WEP keys • Attackers can easily find approved MAC address and spoof it • ethereal • Linux: ifconfig ethXX hw ether xx:xx:xx:xx:xx:xx • Windows: smac application, control panel (some drivers), or registry • WEP keys, if used, can be found by social engineering, airsnort, WEPcrack • Difficult to support large or dynamic user groups Jose' Brustoloni -- Networking'2004

  7. Captive portals AP • First proposed by Stanford’s SPINACH project (INFOCOM’99) • Widely used in university campuses and commercial hotspots • User’s Web browser automatically redirected to captive portal • SSL-secured page where user enters id and password • may use a variety of back-ends for authentication (Kerberos, RADIUS, LDAP) • After authentication, user’s MAC and IP addresses are authorized Internet plain Wi-Fi Captive portal default client AP intranet AP Jose' Brustoloni -- Networking'2004

  8. Session hijacking attack • Hijacker snoops victim’s MAC and IP addresses and access point’s MAC address • Periodically sends to victim 802.11 disassociation or deauthentication notifications purported to come from access point (causing denial-of-service) • Hijacker uses victim’s MAC and IP addresses to obtain unauthorized access Jose' Brustoloni -- Networking'2004

  9. Victim continues to communicate (no denial of service) If victim does not have personal firewall, victim may respond to packets destined to freeloader (e.g., TCP RST), disrupting freeloader’s communication However, if victim has personal firewall, victim does not respond to such packets Both victim and freeloader get access: potential for collusion Freeloading attack Jose' Brustoloni -- Networking'2004

  10. Detecting and blocking session hijackings Session id checking: • Captive portal sends to client a session management page with cookie containing a cryptographically random session id • Session management page is SSL-secured and tagged with http-equiv = “refresh” directive • Client’s browser periodically sends to captive portal request to refresh the session management page • Each request accompanied by cookie with session id • Captive portal deauthorizes MAC and IP addresses of client whose refresh request and session id cookie were not received in the previous period Jose' Brustoloni -- Networking'2004

  11. Detecting freeloading • Each 802.11 packet contains a 12-bit sequence number • Increments by one for each new packet sent; remains the same in case of MAC-layer fragmentation or retransmission • Implemented in adaptor’s firmware; cannot be changed by host • In case of freeloading, sequence numbers of packets using the same MAC and IP addresses form two (or more) trend lines Jose' Brustoloni -- Networking'2004

  12. Blocking freeloading Jose' Brustoloni -- Networking'2004 MAC sequence number tracking: Access point tracks MAC sequence numbers of packets from each associated client In case MAC sequence number returns from a trend line to the previous trend line, access point notifies captive portal for deauthorizing client’s MAC and IP addresses

  13. Comparison between the two defenses • Session id checking is inappropriate against freeloading because in the latter case, the victim continues to communicate and refresh the session management page • MAC sequence number tracking is inappropriate against session hijacking because the latter causes a simple jump in sequence number • simple jump can also happen without hijacking (e.g., client moves out of range and then back in range) • need two trend lines for robust detection • Therefore, use defenses in tandem • Both defenses are transparent to clients: no client configuration required Jose' Brustoloni -- Networking'2004

  14. Implementation • Access point: IBM Thinkpad T30, Pentium 4 1.8 GHz, 256 MB RAM Linux 2.4.20 with modified HostAP driver • Captive portal: Dell Dimension 4550, Pentium 4 2.4 GHz, 256 MB RAM Linux 2.4.20, Apache server • Authentication server: identical Dell computer running OpenLDAP • Test server: identical Dell computer • Test clients: IBM T30 and older Dell and Sony laptops, Sharp PDAs, Dell Dimension 8300 desktops w/ PCI 802.11 cards • Throughput measurements using ttcp • Round-trip measurements using ethereal Jose' Brustoloni -- Networking'2004

  15. Experimental results Verified that: • PittNet Wireless and Starbucks Wi-Fi networks are vulnerable to session hijacking and freeloading • Session id checking detects and blocks session hijacking • reaction delay controlled by refresh period • MAC sequence number tracking detects and blocks freeloading • reaction as soon as legitimate client resumes transmission • Session id checking and MAC sequence number tracking: • interoperate well • work with a variety of network interface cards (including Prism 2, 2.5 (Netgear, Linksys, D-Link), Proxim Orinoco, Cisco Aironet) Jose' Brustoloni -- Networking'2004

  16. Session id checking - throughput Jose' Brustoloni -- Networking'2004

  17. Session id checking – CPU utilization For 1 s refresh Jose' Brustoloni -- Networking'2004

  18. Session id checking - delay Jose' Brustoloni -- Networking'2004

  19. MAC sequence number tracking - throughput Jose' Brustoloni -- Networking'2004

  20. MAC sequence number tracking - delay Jose' Brustoloni -- Networking'2004

  21. Conclusions • Session id checking and MAC sequence number tracking are novel defenses that can help block unauthorized access in: • academic Wi-Fi networks • commercial hotspots • Tradeoff between speed of reaction to session hijacking and CPU and bandwidth overhead of session id checking • Project 1 s reaction time with < 10% CPU overhead @ 1.8 GHz • Overhead of MAC sequence number tracking is very low Jose' Brustoloni -- Networking'2004

  22. IPsec-based Wi-Fi security AP • Use in hotspots proposed at WWW’2000 (Brustoloni & Garay) • Microsoft IPsec client does not support nested IPsec tunnels • if used for LAN, IPsec not available for wider-range VPNs • Thus, need to install IPsec client SW in user computer • Many knobs to turn; interoperation challenging; user needs certificate • Currently viable only with abundant tech support • Perhaps will become easier-to-use with IKEv2 Internet Wi-Fi w/ IPsec IPsec Gateway IPsec client AP intranet AP Jose' Brustoloni -- Networking'2004

More Related