Discussion:
RC4 is dangerous in ways not yet known - heads up on near injection WPA2 downgrade to TKIP RC4
coderman
2014-09-15 08:02:37 UTC
Permalink
first and foremost:
WPA2 does NOT prevent an adversary able to inject packets at you from
downgrading crypto to flawed RC4. due to odd forgotten legacy protocol
bits, every implementation of WPA2 that i have tested is vulnerable to
an active downgrade to TKIP/RC4 while still being "WPA2" and still
showing all signs of using strongest security settings.

let me re-iterate: _WPA2 only_ as a setting on router or client device
does not prevent an active RC4 downgrade when using WPA2. AES-CCMP
must be explicitly checked for, and this is not straightforward in
end-user configuration or management utilities.

RECOMMENDATION: use a wireless packet capture utility to specifically
check for and alert on the presence of TKIP in a WPA2 session. this
never happens under legitimate circumstances. [if you know of one,
please tell me!]

TKIP in WPA2 == Active injection attack by "well funded" adversary[0]

---

i missed the renewed speculation that periodically swirls around RC4, e.g.

"I feel but cannot prove that the day is coming when we learn that
everything we ever encrypted with RC4 is very practical to decrypt"
- https://twitter.com/marshray/status/505586082461655040

"Kind of annoyed SHA-1 is a "crypto emergency" when most of the web
was encrypted with RC4 last year and almost no one cared"
- https://twitter.com/bascule/status/509239990216163330

"This attack also applies directly to WPA/TKIP, with similar success
rates, because of its use of per-packet keys for RC4. Here, the
particular structure of WPA/TKIP keys means that a different set of
biases are obtained in the first 256 bytes of RC4 keystream... For
WPA/TKIP, the only reasonable countermeasure is to upgrade to WPA2."
- http://www.isg.rhul.ac.uk/tls/

---

i have an advisory pending to full-disclosure with details on this
WPA2 force downgrade to TKIP attack and a rant about Kaminsky's DEF
CON 22 talk. advisory includes timeline indicating "in the wild"
discovery of this technique late 2013. any earlier indications
welcome!

to be clear, this issue is with backwards compatibility in WPA2, and
the manner in which a local attacker (8 miles or more with power and
directional emission) can force the WPA2 protected session to use
TKIP/RC4 while appearing to both client and network management
equipment to be using WPA2 and best security configuration. (not WEP,
not WPA)

this is not about how RC4 is broken; i have no idea about the nature
of the RC4 weaknesses enabling decryption, and this as yet unknown
attack is certainly more effective than the attack described in
CVE-2013-2566:
"The attacks can only be carried out by a determined attacker who can
generate sufficient sessions for the attacks. They recover a limited
amount of plaintext. In this sense, the attacks do not pose a
significant danger to ordinary users of TLS or WPA/TKIP in their
current form. However, it is a truism that attacks only get better
with time, and we anticipate significant further improvements to our
attacks."

the attacks observed in the wild did not rely on any additional or
excessive packet creation to reach effectiveness.

best regards,



0. About TKIP with WPA2...
some tools know that TKIP is backwards compatible in WPA2, having
written to spec. E.g. airodump-ng: "Not mandatory, but TKIP is
typically used with WPA and CCMP is typically used with WPA2."

in my testing i have never seen a device that could do WPA2 but not
AES-CCMP. if you find one i'd like to know about it! if you ever see
a device+router pair that used to speak AES-CCMP over WPA2 suddenly
using TKIP you are under active attack.

finally, i mention "advanced attacker" because utilizing this
downgrade also means applying an as yet unknown attack on the RC4
cipher to decrypt.
coderman
2014-09-15 09:39:15 UTC
Permalink
... every implementation of WPA2 that i have tested is vulnerable to
an active downgrade to TKIP/RC4 while still being "WPA2" and still
showing all signs of using strongest security settings.
yes, this attack does require knowing the WPA passphrase (PSK) and no
i have not looked at WPA-Enterprise mode (EAP-*).

yes, just looking for populated michael MIC authenticator fields is
probably sufficient to alarm if you've configured WPA2 only.

yes, this is all for now. :)


best regards,
coderman
2014-09-15 10:23:08 UTC
Permalink
Post by coderman
...
yes, this is all for now. :)
i lied and one last clarification before day is done:

why do you care if this assumes knowledge of the pairwise master key?
a) my poc sucks; make a better one able to manipulate EAPOL frames without PMK!
b) presumably still useful if client SNonce is missed (easier to hear
loud access points than quiet clients behind more obstacles?)

switch to WPA2-EAP-PWD, WPA2-EAP-TTLSv0|v1, WPA2-EAP-PEAP, anything
other than PSK... i can't say for sure that WPA-Enterprise is immune
to this attack, but it is certainly better in many respects
regardless.
coderman
2014-09-22 02:29:27 UTC
Permalink
Hey coderman,
has this been released anywhere? I asked because I discovered
http://people.cs.kuleuven.be/~mathy.vanhoef/papers/wpatkip.pdf again.
(Where with TKIP, if you can inject packets on the air, you can get
back unencrypted traffic that was headed towards the client..)
hi Daniel!

please continue posting relevant material. this is released plus or
minus Full Disclosure moderation queue. you are smart enough to see
why this is a dead end, and "optional" TKIP will live in WPA2 forever.

you may also want to keep in touch with K. Paterson who wrote about
another TKIP issue as mentioned earlier in this thread. i have not
heard of any further input from K. i have not seen any further public
confirmation of active TKIP downgrade or implications.

silence the story, per usual.

best regards,
nymble
2014-09-22 05:49:27 UTC
Permalink
Post by coderman
WPA2 does NOT prevent an adversary able to inject packets at you from
downgrading crypto to flawed RC4. due to odd forgotten legacy protocol
bits, every implementation of WPA2 that i have tested is vulnerable to
an active downgrade to TKIP/RC4 while still being "WPA2" and still
showing all signs of using strongest security settings.
TKIP is NOT the same as RC4 … while we are trying to remove it from
any usage in Wi-FI, it has yet to be fully broken (publicly).
Post by coderman
let me re-iterate: _WPA2 only_ as a setting on router or client device
does not prevent an active RC4 downgrade when using WPA2. AES-CCMP
… vendors create crappy UIs. WPA2 only should mean just AES-CCMP.
Some are done correctly.
Post by coderman
must be explicitly checked for, and this is not straightforward in
end-user configuration or management utilities.
RECOMMENDATION: use a wireless packet capture utility to specifically
check for and alert on the presence of TKIP in a WPA2 session. this
never happens under legitimate circumstances. [if you know of one,
please tell me!]
YEs/
Post by coderman
TKIP in WPA2 == Active injection attack by "well funded" adversary[0]
Please elaborate. TKIP has not been identified as a ‘active attack’ vector.
Post by coderman
---
i missed the renewed speculation that periodically swirls around RC4, e.g.
"I feel but cannot prove that the day is coming when we learn that
everything we ever encrypted with RC4 is very practical to decrypt"
- https://twitter.com/marshray/status/505586082461655040
"Kind of annoyed SHA-1 is a "crypto emergency" when most of the web
was encrypted with RC4 last year and almost no one cared"
- https://twitter.com/bascule/status/509239990216163330
"This attack also applies directly to WPA/TKIP, with similar success
rates, because of its use of per-packet keys for RC4. Here, the
particular structure of WPA/TKIP keys means that a different set of
biases are obtained in the first 256 bytes of RC4 keystream... For
WPA/TKIP, the only reasonable countermeasure is to upgrade to WPA2."
- http://www.isg.rhul.ac.uk/tls/
---
i have an advisory pending to full-disclosure with details on this
WPA2 force downgrade to TKIP attack and a rant about Kaminsky's DEF
CON 22 talk. advisory includes timeline indicating "in the wild"
discovery of this technique late 2013. any earlier indications
welcome!
to be clear, this issue is with backwards compatibility in WPA2, and
the manner in which a local attacker (8 miles or more with power and
directional emission) can force the WPA2 protected session to use
TKIP/RC4 while appearing to both client and network management
equipment to be using WPA2 and best security configuration. (not WEP,
not WPA)
this is not about how RC4 is broken; i have no idea about the nature
of the RC4 weaknesses enabling decryption, and this as yet unknown
attack is certainly more effective than the attack described in
"The attacks can only be carried out by a determined attacker who can
generate sufficient sessions for the attacks. They recover a limited
amount of plaintext. In this sense, the attacks do not pose a
significant danger to ordinary users of TLS or WPA/TKIP in their
current form. However, it is a truism that attacks only get better
with time, and we anticipate significant further improvements to our
attacks."
the attacks observed in the wild did not rely on any additional or
excessive packet creation to reach effectiveness.
best regards,
0. About TKIP with WPA2...
some tools know that TKIP is backwards compatible in WPA2, having
written to spec. E.g. airodump-ng: "Not mandatory, but TKIP is
typically used with WPA and CCMP is typically used with WPA2."
in my testing i have never seen a device that could do WPA2 but not
AES-CCMP.
WPA2 is supposed to mean AES-CCMP. WPA is TKIP.
Unclear that you know what you are saying ….


nymble
Post by coderman
if you find one i'd like to know about it! if you ever see
a device+router pair that used to speak AES-CCMP over WPA2 suddenly
using TKIP you are under active attack.
finally, i mention "advanced attacker" because utilizing this
downgrade also means applying an as yet unknown attack on the RC4
cipher to decrypt.
_______________________________________________
cryptography mailing list
http://lists.randombit.net/mailman/listinfo/cryptography
coderman
2014-09-22 23:37:32 UTC
Permalink
Post by nymble
...
TKIP is NOT the same as RC4 … while we are trying to remove it from
any usage in Wi-FI, it has yet to be fully broken (publicly).
agreed.
Post by nymble
Please elaborate. TKIP has not been identified as a ‘active attack’ vector.
if TKIP is optional in WPA2, and yet must be implemented in WPA2 [0]
and, attacker is able to inject EAPOL in one or both directions, some
of the time
then, attacker can force TKIP in a "WPA2 protected session" visibly
identical to the user as desired AES-CCMP WPA2 mode. " [1]
and attacker can force WPA2-TKIP regardless of the WPA disable,
and TKIP disable options set in client or access point, which all
appear to set advertised preferences, not absolute capabilities, at
the radio level.

consider the following states, which may be influenced by injecting attacker:
access point WPA2-TKIP disable + client WPA2-TKIP requested
access point WPA2-TKIP requested + client WPA2-TKIP disable
access point WPA2-TKIP disable + client WPA2-TKIP disable (able to
silent transition? bug on top of bug) [2]

if any of these end up in WPA2 TKIP for a given hardware pair, it is a problem.

we have problems.


best regards,


to be specific about the problems, in case not concise enough above:
0. lack of a way to enforce TKIP disable.
1. lack of visual signal of TKIP downgraded security in WPA2 to users.
2. insult to injury with "unspecified" bozofail TKIP transition to ON
flaws in some hw.

Loading...