Lucene search

K
attackerkbAttackerKBAKB:E144DDF5-BA54-49FB-B30B-34FF2B8B7F5E
HistoryFeb 05, 2020 - 12:00 a.m.

CVE-2019-15126 aka Kr00k

2020-02-0500:00:00
attackerkb.com
86

8.8 High

CVSS3

Attack Vector

ADJACENT_NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

8.3 High

CVSS2

Access Vector

ADJACENT_NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

COMPLETE

Integrity Impact

COMPLETE

Availability Impact

COMPLETE

AV:A/AC:L/Au:N/C:C/I:C/A:C

An issue was discovered on Broadcom Wi-Fi client devices. Specifically timed and handcrafted traffic can cause internal errors (related to state transitions) in a WLAN device that lead to improper layer 2 Wi-Fi encryption with a consequent possibility of information disclosure over the air for a discrete set of traffic, a different vulnerability than CVE-2019-9500, CVE-2019-9501, CVE-2019-9502, and CVE-2019-9503.

Recent assessments:

busterb at February 27, 2020 2:53pm UTC reported:

The TL;DR from the technical whitepaper found here: <https://www.welivesecurity.com/wp-content/uploads/2020/02/ESET_Kr00k.pdf&gt;

If there are outbound TX queue packets for certain common WiFi devices, and a disassociation management packet is sent, the device will clear the encryption key to all zeros, and send the remaining packet data in the queue with that hardcoded key. If an attacker can send diassociate packets and then listen for any residual data frames, they can decrypt whatever traffic remains in the TX queue on those devices, which may be a few hundred packets depending on the data rate involved.

While this seems like a real risk, I’m firmly in the camp that relying on the physical layer in the first place for data protection is misguided, and that really end-to-end security is still the only way to – Wifi has proven over and over to be a weak security boundary. By the time this is wide-spread fixed, we’ll all be using DNS-over-HTTPS by force from browsers anyway. So, from an end-point consumer PoV, this isn’t a big deal. Not any worse that connecting to that unencrypted hotel network you may have used earlier.

Some potential future vuln predictions here: <https://twitter.com/vanhoefm/status/1232738451587555328&gt;

Thinking through situations where an attacker might find this useful would be in physically accessing business-local OT networks, like point-of-sale, manufacturing, or other squishy-on-the-inside networks. Expect to see this show up in the next Wifi Pineapple release or in your next pen test physical engagement report.

Assessed Attacker Value: 2
Assessed Attacker Value: 2Assessed Attacker Value: 4

References

8.8 High

CVSS3

Attack Vector

ADJACENT_NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

8.3 High

CVSS2

Access Vector

ADJACENT_NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

COMPLETE

Integrity Impact

COMPLETE

Availability Impact

COMPLETE

AV:A/AC:L/Au:N/C:C/I:C/A:C