PTK0 rekey attack scenario for ath9k with kernel <4.20

Sorry, forgot to put the Mailing list on CC for the initial mail. So 
here again:

Am 06.01.20 um 12:38 schrieb Alexander Wetzel:
> Am 06.01.20 um 10:03 schrieb Jouni Malinen:
>> On Sat, Jan 04, 2020 at 11:10:01PM +0100, Alexander Wetzel wrote:
>>> Rekeying a pairwise key using only keyid 0 (PTK0 rekeys) has many broken
>>> implementations and should be avoided for both security and usability
>>> reasons.
>>> The effects can be triggered by either end of the connection and range
>>> from hardly noticeable disconnects over long connection freezes up to
>>> leaking clear text MPDUs which can be used to calculate the outgoing 
>>> PTK.
>>>
>>> To avoid the issues replace PTK0 rekeys by default with disconnects and
>>> add the new option "wpa_deny_ptk0_rekey" to let the user control the
>>> behavior.
>>
>> I don't think it is appropriate to force disconnections by default for
>> all existing systems. It would seem fine to provide an option to
>> explicitly request such behavior, but this by-default-behavior looks
>> like a too drastic approach to take when there are multiple drivers that
>> have over years added various workarounds to avoid many of the issues
>> for most common cases.
>>
> 
> I'm aware of the issue to be controversial. For me this looks more risky 
> than the alternative, but I can't rule out I miss something...
> 
> Have you some evidence of rekeying to be really working in real-world 
> scenarios? It can work with carefully selected cards/drivers but in 
> mixed environments it seems to be asking for trouble.
> 
> I've done some tests with abysmal results with HW available to me.
> I tried to google issues related to that and did find some - but much 
> less than expected - candidates ranging from very likely to maybe. Some 
> were even discussing GTK rekeys when the log evidence made clear that 
> they had a PTK rekey issue.
> 
> I can only explain the missing outcry by the assumption that rekeying is 
> seldom used and the few users hit by it are using the workarounds for 
> "strange wifi issues" like disabling HW encryption and/or A-MPDU 
> aggregation or switching to other HW. Coupled with the normal 1h "dead 
> time" you need to hit the first problem and that most systems seem to 
> recovering already with a reconnect that may just be possible...
> 
> Set your AP to rekey all 30s and start a download or video streaming and 
> check what happens with your different devices. (I'm normally testing 
> close to the AP.)
> For me with Windows the "common" case was a disconnect, due to 
> encrypting the eapol #4 with the new key. I was initially assuming that 
> these reconnects were by design to recover from whatever went wrong and 
> was wondering why linux systems did freeze instead. Fixing eapol#4 races 
> may therefore make the situation worse.
> 
> Here list for devices/System which got at least some quick look and what 
> I found out (this data is roughly two years old):
> 
> The only working devices I found are
>   - ath10k with linux (not tested with Windows)
>   - Windows Surface Pro 3 running Win 10 (I think many/most/all Marvell
>     drivers could be ok)
>   - iPhone (I think it was a iPhone X but may be off one generation)
> 
> Known devices/systems not able to rekey the PTK correctly:
>   - any linux system using ath9k with mac80211 from kernel < 4.20
>   - HTC 10 smartphone (running Linageos)
>   - Nexus 5x smartphone (stock)
>   - Samsung Galaxy S5 smartphone (running Linageos)
>   - Samsung Galaxy Tab S3 (stock)
>   - Samsung Series 6 SmartTV
>   - Dell notebook using some broadcom fullmac NIC (Windows 7)
>   - AWUS036ACH USB stick (Win10)
> 
> So there is at least some evidence that many developers did not consider 
> the races and the potential consequences of ignoring them has.
> 
> There is basically no way that the ath9k driver is not messing up a 
> rekey with ongoing traffic. It's also so far the only known driver which 
> can leak the PTK. Especially with TKIP this looks extremely dangerous, 
> where an attacker can trigger the rekeys at will.
> I've not tried it, but generate MIC errors at a busy moment and you will 
> get MPDUs fully set up for encryption with only the encryption missing. 
> And that also works for retransmits, so you can get the same MPDU 
> encrypted and decrypted... Which for my understanding then allows you to 
> calculate the PTK and decrypt any previously captured MPDUs using the PTK.
> 
> Now this is of course nothing more than a driver issue but looking at 
> the lists I would be very surprised if not at least 50% of common used 
> devices are broken today and expect rates around 90%. (With most already 
> reconnecting, mitigating the user impact.)
> 
> For me the issue started with these two tickets, when I got frustrated 
> by the strange wlan freezes and could no longer deny a pattern after 
> having ignored it for years:
>   - https://bugzilla.kernel.org/show_bug.cgi?id=92451
>   - https://dev.archive.openwrt.org/ticket/18966
> 
> I was able to pin the issue to PTK rekeying with clear evidence showing 
> what was going on. But nothing happened and so some years later I 
> decided to try to fix that myself. A important mile stone was the fix 
> for mac80211 62872a9b9a10 ("mac80211: Fix PTK rekey freezes and clear 
> text leak"), which is to my best knowledge the first documentation what 
> must be considered when replacing a PTK key besides the eapol#4 race - 
> which is pretty harmless compared to the other races a driver can have.
> 
> Keeping the old behavior as default will for sure cause less pain, after 
> all the problems are as old as WPA and the users must have reached some 
> kind of arrangement with the situation. But knowing that this can leak 
> PTKs it looks like the only secure approach is enforce the reconnects.
> 
> The reasoning is, that since we do not have a outcry of users with PTK 
> rekey issues today and most devices are already reconnecting on rekey 
> there should not be many users which should notice the difference.
> But quite some of them may leak PTK keys.
> 
> I would of course feel better if more would test PTK rekeying in their 
> setups or at least get some data how often PTK rekeying is enabled by 
> default and what are the intervals.
> 
> Not changing the default is ok when we are sure that only ath9k with 
> mac80211 < 4.20 is leaking clear text MPDUs and no other of the broken 
> devices fell into the same trap. Or - since my understanding of the used 
> cypto is still lacking - someone can confirm that having an encrypted 
> MPDU and the same MPDU decrypted (with all the same headers and PN) does 
> not allow to calculate the PTK.

I small update on that:
After some reading I'm sure the clear text leak is harmless with 
"modern" TKIP/CCMP ciphers. The only security relevant issue allowing 
attacks on the key seems to be the the PN reuse.

Here the attack, designed for ath9k cards using vulnerable mac80211:

1) Attacker sets up an "repeater" and getting an victim to funnel all 
communication with the true AP trough it. (When thew AP is vulnerable 
all STAs can be attacked.)

2) The repeater is normally just passing through all frames without 
modifications but a small delay (10ms or so, probably needs some tuning)

3) Once the "repeater" detects an PTK rekey (PN numbers reset to zero) 
it drops all packets buffered to stop all packets using the PN from the 
old key encrypted with the new to reach the other STA. (This prevents 
the freeze AND the attacker gets some packets for the new key with PN 
numbers the new key may reach)

4) Now the attack needs luck or a way to generate traffic for the 
association: The PN for the new key must become a bit higher than for 
the first key.

5) Which violates the requirement that PNs must never be reused. (Sounds 
like this opens some cryptographic attacks)

6) Which then potentially allows to decrypt or is at least weakening the 
encryption of all other MPDUs protected with the same key. (Not sure how 
bad it really is but for my understanding it crosses a red line.)

With CCMP the attacker can't control the time for the PTK rekey, so a 
mostly idle connection during the rekey will make this a hit and miss. 
But if the connection is using TKIP he simply can time a rekey by 
generating Michal MIC errors when he wants...

I did find anything how much effort it would be to calculate the PTK 
when you have multiple MPDUs using the same PN. (I guess 10 pairs of 
duplicate PN MPDUs can be achieved by the attack on each rekey.)

Do you see any holes in the attack scenario?

Alexander

_______________________________________________
Hostap mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/hostap