802.11 Denial-of-Service Attacks Real Vulnerabilities and Practical - - PowerPoint PPT Presentation

802.11 Denial-of-Service Attacks Real Vulnerabilities and Practical Solutions

John Bellardo and Stefan Savage Department of Computer Science and Engineering University of California, San Diego

Motivation

n 802.11-based networks have flourished

n Home, business, health care, military, etc.

n Security is an obvious concern

n Threats to confidentiality well understood and

being addressed [WPA, 802.11i]

n Threats to availability (denial-of-service) not

widely appreciated & not being addressed

Live 802.11 DoS Demonstration

Time (1/10 second intervals) Packets

Everyone Else Attacker Victim

D e m

• n

s t r a t i

• n

N

• t

A v a i l a b l e I n t h i s v e r s i

• n
• f

t h e P r e s e n t a t i

• n

n RF Jamming

n Real threat, 802.11 highly vulnerable; not our focus

n Bandwidth consumption (flooding)

n 802.11 has same vulnerability as wired nets; not our focus

n Attacks on 802.11 protocol itself

n Easy to mount, low overhead, selective, hard to debug n Media access vulnerabilities n Management vulnerabilities

n This talk focuses on these DoS attacks, their

practicality, their effectiveness and how to defend against them

802.11 DoS Attacks

Media Access Vulnerabilities

n 802.11 includes collision avoidance mechanisms n Typically require universal cooperation between all

nodes in the network

n Media access vulnerabilities arise from the

assumption of universal cooperation

n Virtual carrier sense is an example of a media access

mechanism that is vulnerable to DoS attacks

Frm Ctl

NAV Vulnerability

Duration Addr1 Addr2 Addr3 Seq Ctl Addr4 Data FCS

802.11 General Frame Format

2 6 6 6 6 6 0-2312 2 2

n Virtual carrier sense allows a node to reserve

the radio channel

n Each frame contains a duration value

n Indicates # of microseconds channel is reserved n Tracked per-node; Network Allocation Vector (NAV) n Used by RTS/CTS

n Nodes only allowed to xmit if NAV reaches 0

Simple NAV Attack: Forge packets with large Duration

Access Point Node 1 Node 2 Attacker

Duration=32000 Duration=32000

Access Point and Node 2 can’t xmit (but Node 1 can)

Extending NAV Attack w/RTS

Access Point Node 1 Node 2 Attacker

Duration=32000

R T S

Duration=31000

CTS

Duration=31000

CTS

D u r a t i

• n

= 3 1

CTS AP and both nodes barred from transmitting

n Both wrong…

Conventional Wisdom

n NAV attack not a practical threat

n Commodity hardware doesn’t allow

Duration field to be set

n But would be highly effective if

implemented

n Shut down all access to 802.11 network

Commodity 802.11 hardware

n Firmware-driven microcontroller

n Same code/architecture shared by most popular

vendors (Choice Microsystems)

n Transmit path

n Host provides frame to NIC and requests xmit n NIC firmware validates frame and overwrites key

fields (e.g. duration) in real-time

n Frame then sent to baseband radio interface

n Not possible to send arbitrary frames via

firmware interface

How to Generate Arbitrary 802.11 Frames?

Key idea: AUX/Debug Port allows Raw access to NIC SRAM

• 1. Download frame to

NIC

• 2. Find frame in SRAM
• 3. Request transmission
• 4. Wait until firmware

modifies frame

• 5. Rewrite frame via AUX

port Host Interface to NIC

BAP AUX Port SRAM Xmit Q Xmit process

Virtualized firmware interface

Physical resources

Radio Modem Interface

Why the NAV attack doesn’t work

n Surprise: many vendors do not implement the

802.11 spec correctly

n Duration field not respected by other nodes

Excerpt from a NAV Attack Trace

TCP Data 0.258 :93:ea:e7:0f :93:ea:ab:df 1.297869 802.11 Ack :93:ea:e7:0f 1.296540 TCP Data 0.258 :93:ea:ab:df :93:ea:e7:0f 1.295192 802.11 CTS 32.767 :e7:00:15:01 1.294020 Type Duration (ms) Destination Source Time (s)

1.2952 - 1.2940 = 1.2 ms

Simulating the NAV attack

n This bug will likely get fixed

n Valuable for 802.11-based telephony, video, etc.

n So how bad would the attack be? n Simulated NAV attack using NS2

n 18 Users n 1 Access Point n 1 Attacker

n 30 attack frames per second n 32.767 ms duration per attack frame

NAV Attack Simulation

50 100 150 200 250 300 350 10 16 22 28 34 40 46 52 58 64 70 76 82 88 94 Simulated Seconds Packets Attacker

• Users

Practical NAV Defense

n Legitimate duration values are relatively

small

n Determine maximum reasonable NAV

values for all frames

n Each node enforces this limit n < .5 ms for all frames except ACK and CTS n ~3 ms for ACK and CTS

n Reran the simulation after adding

defense to the simulator

Simulated NAV Defense

50 100 150 200 250 300 350 10 16 22 28 34 40 46 52 58 64 70 76 82 88 94 Simulated Seconds Packets Attacker

• Users

Management Vulnerabilities

n 802.11 Management functions

n Authentication (validate identity) n Association (picking access point)

n Most management operations unprotected

n Easy to spoof with false identity n Source of vulnerabilities

n This problem is not being fixed

n Most management frames unencrypted n 802.1x ports allocated after management

functions take place

n 802.11i has deferred addressing this problem

Deauth Attack

Authenticated Associated

n 802.11 management requires nodes

associate before sending data

Attacker Victim Authentication Request Association Request Association Response Authentication Response Access Point

Deauth Attack

Authenticated Associated

n Before node can transmit data, attacker

send a spoofed deauthentication frame

Attacker Victim Access Point Deauthentication

Deauth Attack

Authenticated Associated

n Node attempts to transmit data, but it

can not

Attacker Victim Data Deauthentication Access Point

Deauth Attack Results

100 200 300 400 500 600 700 800 1 11 21 31 41 51 61 71 81 91 101 112 122 132 141 151 Time (s) Packets Attacker Win XP Linux Thinkpad Linux iPaq MacOS

Practical Deauth Defense

n Based on the observed behavior that

legitimate nodes do not deauthenticate themselves and then send data

n Delay honoring deauthentication request

n Small interval (5-10 seconds) n If no other frames received from source then

honor request

n If source sends other frames then discard request

n Requires no protocol changes and is

backwards compatible with existing hardware

Deauth Defense Results

100 200 300 400 500 600 700 1 5 9 13 17 21 25 29 33 37 41 45 Time (s) Packets Attacker Win XP Linux Thinkpad Linux iPaq MacOS

Conclusion

n 802.11 DoS attacks require more attention

n Easy to mount and not addressed by existing

standards

n Should not depend on restricted firmware

interfaces (can send arbitrary 802.11 pkts)

n Deauthentication attack is most immediate

concern

n Simple, practical defense shown to be effective

Hands-on Demonstration

n Attack implemented

• n an iPaq

n See me for a hands-

• n demonstration

during the break