Detecting and Blocking Unauthorized Access in WiFi Networks

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 Web: http: //www. cs. pitt. edu/~jcb/ May 12, 2004 Jose' Brustoloni -- Networking'2004

Motivation ♦ Securing Wi-Fi networks is feasible but labor-intensive Ø Ø ♦ Wi-Fi networks that serve large number of user-owned computers typically resort to not-so-secure but easier-to-use authentication schemes Ø Ø ♦ IPsec, dynamic WEP w/ IEEE 802. 1 x, WPA, IEEE 802. 11 i HW, SW installation, configuration in user computers 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 May 12, 2004 Jose' Brustoloni -- Networking'2004 2

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 Ø ♦ Interoperate with IPsec, 802. 1 x, WPA, 802. 11 i Ø ♦ possible applications in universities, commercial hotspots 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 May 12, 2004 Jose' Brustoloni -- Networking'2004 3

Native Wi-Fi security AP 802. 1 x client RADIUS AP encrypted Wi-Fi w/ dynamic keys router Internet AP • WEP hopelessly insecure → new schemes based on 802. 1 x • 802. 1 x 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. 11 i) May 12, 2004 Jose' Brustoloni -- Networking'2004 4

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. 11 i 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? May 12, 2004 Jose' Brustoloni -- Networking'2004 5

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 eth. XX hw ether 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 ♦ May 12, 2004 Jose' Brustoloni -- Networking'2004 6

Captive portals default client plain Wi-Fi AP AP Internet Captive portal AP ♦ ♦ ♦ intranet 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 May 12, 2004 Jose' Brustoloni -- Networking'2004 7

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 May 12, 2004 Jose' Brustoloni -- Networking'2004 8

Freeloading attack ♦ ♦ ♦ 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 May 12, 2004 Jose' Brustoloni -- Networking'2004 9

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 May 12, 2004 Jose' Brustoloni -- Networking'2004 10

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 ♦ May 12, 2004 Jose' Brustoloni -- Networking'2004 11

Blocking freeloading 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 ♦ May 12, 2004 Jose' Brustoloni -- Networking'2004 12

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 ♦ May 12, 2004 Jose' Brustoloni -- Networking'2004 13

Implementation ♦ ♦ ♦ ♦ Access point: IBM Thinkpad T 30, Pentium 4 1. 8 GHz, 256 MB RAM Linux 2. 4. 20 with modified Host. AP 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 Open. LDAP Test server: identical Dell computer Test clients: IBM T 30 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 May 12, 2004 Jose' Brustoloni -- Networking'2004 14

Experimental results Verified that: ♦ Pitt. Net Wireless and Starbucks Wi-Fi networks are vulnerable to session hijacking and freeloading ♦ Session id checking detects and blocks session hijacking Ø ♦ MAC sequence number tracking detects and blocks freeloading Ø ♦ reaction delay controlled by refresh period 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) Ø May 12, 2004 Jose' Brustoloni -- Networking'2004 15

Session id checking - throughput May 12, 2004 Jose' Brustoloni -- Networking'2004 16

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

Session id checking - delay May 12, 2004 Jose' Brustoloni -- Networking'2004 18

MAC sequence number tracking - throughput May 12, 2004 Jose' Brustoloni -- Networking'2004 19

MAC sequence number tracking - delay May 12, 2004 Jose' Brustoloni -- Networking'2004 20

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 May 12, 2004 Jose' Brustoloni -- Networking'2004 21

IPsec-based Wi-Fi security IPsec client Wi-Fi w/ IPsec AP AP Internet IPsec Gateway AP ♦ ♦ Use in hotspots proposed at WWW’ 2000 (Brustoloni & Garay) Microsoft IPsec client does not support nested IPsec tunnels Ø ♦ ♦ intranet 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 IKEv 2 May 12, 2004 Jose' Brustoloni -- Networking'2004 22