detecting and blocking unauthorized access in wi-fi networks haidong xia and jos é brustoloni

Detecting and Blocking Detecting and Blocking Unauthorized Access in Unauthorized Access in

Wi-Fi NetworksWi-Fi Networks

Haidong Xia and JosHaidong Xia and José Brustolonié Brustoloni

Department of Computer ScienceUniversity of Pittsburgh210 S. Bouquet St. #6111, Pittsburgh, PA 15260, USATel.: +1 (412) 624-8852, Fax: +1 (412) 624-8854Email: [email protected]: http://www.cs.pitt.edu/~jcb/

mailto:[email protected]

http://www.cs.pitt.edu/~jcb/



Jose' Brustoloni -- Networking'2004 2May 12, 2004

MotivationMotivation♦ 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


ContributionContribution♦ 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


Native Wi-Fi securityNative Wi-Fi securityAP

AP

AP

RADIUS802.1xclient Internet

encryptedWi-Fi w/dynamic

keys

router

• 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)


Hurdles for native Wi-Fi securityHurdles 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?


MAC address filteringMAC 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


Captive portalsCaptive portals

♦ 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

AP

AP

AP

Captiveportal

defaultclient

Internet

intranet

plainWi-Fi


Session hijacking attackSession 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


Freeloading attackFreeloading 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


Detecting and blocking session hijackingsDetecting 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


Detecting freeloadingDetecting 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


Blocking freeloadingBlocking 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


Comparison between the two defensesComparison 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


ImplementationImplementation♦ 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


Experimental resultsExperimental resultsVerified 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)


Session id checking - throughputSession id checking - throughput


Session id checking – CPU utilizationSession id checking – CPU utilization

For 1 s refresh


Session id checking - delaySession id checking - delay


MAC sequence number tracking - throughputMAC sequence number tracking - throughput


MAC sequence number tracking - delayMAC sequence number tracking - delay


ConclusionsConclusions♦ 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


IPsec-based Wi-Fi securityIPsec-based Wi-Fi security

♦ 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

AP

AP

AP

IPsecGateway

IPsecclient

Internet

intranet

Wi-Fi w/IPsec

detecting and blocking unauthorized access in wi-fi networks haidong xia and jos é brustoloni

Documents

user computersmust

user en

users access

large number of user

user computerswifi networks

freeloadingjose brustoloni

ijose brustoloni

approved mac address