Here is a simple attack against WPA, WEP or whichever wireless security mechanism ...

Have an access point with same SSID with stroger signal strength, the user's laptop connects to the attacker's access point gives a pop up network is not secure do you really want to connect. (Some % of users will click OK). Vola you have hijacked the user's connection. Do all MITM you want to do.

But if you are looking for theoritical/cryptographical hacks, there are some due to weakness of Michael

You can find here:

http://www.ieee802.org/11/Documents/DocumentHolder/3-211.zip

Regarding your concern about PSK and not WPA weakness. The problem is PSK is shared between several users and hence the attack becomes easier (problem of WPA or WPA implementation) strength or length of PSK is immaterial.

Here is some details:

How the PSK is used in WPA and 802.11i

The PSK provides an easily implemented alternative for the PMK as compared to using 802.1X to generate a PMK. A 256bit PSK is used directly as the PMK. When the PSK is a passphrase, the PMK is derived from the passphrase as follows:

PMK = PBKDF2(passphrase, ssid, ssidLength, 4096, 256)

Where the PBKDF2 method is from PKCS #5 v2.0: Password-based Cryptography Standard. This means that the concatenated string of the passphrase, SSID, and the SSIDlength is hashed 4096 times to generate a value of 256 bits. The lengths of the passphrase and the SSID have little impact on the speed of this operation.

The PTK is a keyed-HMAC function using the PMK on the two MAC addresses and the two nonces from the first two packets of the 4-Way Handshake. This is why the whole keying hierarchy falls into the hands of anyone possessing the PSK, as all the other information is knowable.

Available from:

http://wifinetnews.com/archives/002452.html

Also, see details on how offline attacks are possible.

Also see this one on weakness of "temporal key hash" basically having the RC4 key gives you the MIC. It is little bit hypothetical situation but when designing security protocols one should be prepared for the worst possible way users will use this.

http://www.nowires.org/Papers-PDF/WPA_attack.pdf

Since this discussion started about the digest authentication in SIP I have few comments on that too.

1. Digest Authentication was never designed to prevent active MITM attack

2. Certain requests (CANCEL, ACK) and all responses are unauthenticated.

3. Authentication is only one way (phone can not challenge requests from proxy)

4. Auth-Info could be used which is not in most implementations, but even when implemented it does not scale since AAA/Radius can not be used. There is new rfc I know but basically divulges too much information to intermediary.

5. SIP designers (3261) weakened the HTTP digest authentication due to needs of telephony features such as forwarding. (Request uri need not be same as Digest uri)

6. Implementations have several options support qop - none, auth, auth-int. Without auth-int SDP can be manipulated, but none supports integrity protection of SIP message anyway.

7. In absence of cnonce usage, the attacker can not only do offline password attack but can also do precompute reverse dictionary lookup password attack by posing as MITM.

8. Then start implementation issues,

a) refresh of Nonce,

b) incrementing nonce-count,

c) which requests to authenticate

9. Breaks my NAT traversal model if I do auth-int

10. Forces proxies to be part of all requests, no possibility of establishing UA to UA passwords (think about how many realms)

I like the VOIP_HACKER approach, do the best you can with protocols but always have some monitoring IDS, IPS type device which is application/VOIP aware to alert of any breaches.

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/infocus/1862/728#728