how to not make a secure protocol 802.11 wep dan petro

Post on 19-Dec-2015

223 Views

Category:

Documents

4 Downloads

Preview:

Click to see full reader

TRANSCRIPT

How To Not Make a Secure Protocol

802.11 WEP

Dan Petro

What is WEP? Wired Equivalent Privacy Wireless LAN security protocol

Uses IEEE 802.11 a,b,g, and n Provides certain security services Originally 64 bits, but has been extended to 128

bits and even 256 bits Easily broken Why? And How?

Fundamentally poor design choices

How does WEP work? It works like a One

Time Pad Keystream is

pseudorandom XOR'd with plaintext Perfectly secret

ciphertext Right? What's the

worst that could happen?

Design Goals of WEP Confidentiality

RC4 cipher and XOR operation

Integrity CRC of message

inside plaintext Authentication?!* Availability?!

Keys Not one, but two

keys. Primary Master Key or

just “key” (Secret) Initialization Vector

(Well known) Key = 40 bits IV = 24 bits

Total = 64 bits

Failure #1 ONE TIME Pad

You must never use the same key(stream) twice. In WEP, Key = PMK + IV

IV changes for each message If an IV is ever used twice, the same keystream will

be used twice IV is only 24 bits

Birthday Attack = collision every 5,000 frames.

Failure #1 What's the harm?

Cipher1 = Plaintext1 ⊕Keystream Cipher2 = Plaintext2 ⊕Keystream

You now know Plaintext1 ⊕Plaintext2 If you happen to know one of the plaintexts, then

you can decrypt any new ciphertext that uses the same Keystream

Full and partial knowledge No diffusion!

Even worse: WEP does not specify how to select IV's.

Failure #1 Example

• Capture multiple Ciphertexts with the same IV

• Obtain a (partial) Known Plaintext

• Decrypt corresponding bits in the other messages.

Failure #2 Integrity Failure

Linear CRC is used for Integrity.

Not a Cryptographically Secure Hash Function

Linear means distributive CRC(a) xor CRC(b)

Equals CRC(a xor b)

Failure #2

Arbitrary packet forgery!

Even with partial knowledge.

If you know the plaintext of any part of a message, you can change it.

WEP sends DST IP in plaintext

Failure #2.5

IP Redirection Attack

– Change every IP address to that of the attacker outside the network.

Failure #3

• Authentication Fail

• 1) Client Hello

• 2) Server Plaintext Challenge (128 Bytes)

• 3) Client Sends Encrypted Challenge back

Failure #3

But we can change the contents of any message, remember?

Observe one valid authentication.

Failure #3

• Now just change the contents of this captured response to be the challenge you need!

Failure #4

Getting a “Known Plaintext Attack” WEP does not mask the size of frames You can see exactly how long each message

is. Mix that with TCP/IP, and you get a known

plaintext attack ARP messages are very short, and of known

length. (28 ARP bytes + 14 Layer 1 Bytes= 42 Bytes Total)

Lots of routers automatically send tons of ARP messages constantly

Failure #4.5

ARP Replay Attack ARP is stateless One ARP request packet can be replayed

over and over Hosts will respond with fresh traffic as

responses Allows for an arbitrary amount of traffic to be

generated in use with other attacks. Upgrade the attack to “Chosen Plaintext”

Failure #5 No Server

Authentication Rouge AP's Attacker makes

another AP with the same SSID

Victim connects to the wrong AP

Now you have a Man-in-the-Middle

Failure #6 The Cafe Latte Attack

No authentication

Clients keep a list of favorite AP's

One's they've used before

When powering on, they try to connect to those AP's

Stimulate traffic from client, crack key

Failure #7 If the PMK is known, all bets are off

WEP does not specify how PMKs are chosen or exchanged.

It's a standard “Shared Secret” problem! Social Engineering

Use a Rouge AP Dictionary attacks Out of Band attacks

Does your company have a piece of paper with the key laying around? It probably does.

Failure #8 Denial of Service Firstly, it is legal to jam 2.4GHz signals

Just not cell phones! 802.11 Wifi is naturally vulnerable to this

But not Bluetooth! Associate / Disassociate Packets are unencrypted If there is a single malicious user on your network, he can

bring the whole thing down ARP Cache Poisoning DOSS (Denial of Service... with Style)

Failure #9

• No Session Keys!

• How the network's perimeters should look:

• How it does look:

Failure #9 Airpwn

First “displayed” at Defcon 12

Intercepts data just like with a Rouge AP

Responds to HTTP traffic before the real web server can

Result? Anything you

want!

The Breaks Key recovery attacks due to RC4 Fluhrer, Mantin and Shamir attack

Discovered that the first few bytes produced is highly non-random

Andreas Klein Even more correlations between key and

keystream found Tews, Weinmann, and Pyshkin. (PTW)

Built upon Klein's analysis and built Aircrack-ptw

(Now Aircrack-ng)

References and links Intercepting Mobile Communications: The

Insecurity of 802.11 http://www.isaac.cs.berkeley.edu/isaac/mobicom.pdf

Wikipedia http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy

Weaknesses in the Key Scheduling Algorithm of RC4

http://www.drizzle.com/~aboba/IEEE/rc4_ksaproc.pdf CC-BY-SA

top related