how to not make a secure protocol 802.11 wep dan petro
Post on 19-Dec-2015
223 views
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