Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2018.2350
wpa_supplicant -- unauthenticated encrypted EAPOL-Key data
15 August 2018
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: wpa_supplicant
Publisher: FreeBSD
Operating System: FreeBSD
Impact/Access: Access Privileged Data -- Remote/Unauthenticated
Denial of Service -- Remote/Unauthenticated
Resolution: Patch/Upgrade
CVE Names: CVE-2018-14526
Reference: ESB-2018.2297
Original Bulletin:
http://www.vuxml.org/freebsd/6bedc863-9fbe-11e8-945f-206a8a720317.html
- --------------------------BEGIN INCLUDED TEXT--------------------
FreeBSD VuXML: Documenting security issues in FreeBSD and the FreeBSD Ports
Collection
wpa_supplicant -- unauthenticated encrypted EAPOL-Key data
Affected packages
wpa_supplicant < 2.6_2
FreeBSD <= 10.4_10
FreeBSD <= 11.2_1
Details
VuXML ID 6bedc863-9fbe-11e8-945f-206a8a720317
Discovery 2018-08-08
Entry 2018-08-14
SO-AND-SO reports:
A vulnerability was found in how wpa_supplicant processes EAPOL-Key frames.
It is possible for an attacker to modify the frame in a way that makes
wpa_supplicant decrypt the Key Data field without requiring a valid MIC
value in the frame, i.e., without the frame being authenticated. This has a
potential issue in the case where WPA2/RSN style of EAPOL-Key construction
is used with TKIP negotiated as the pairwise cipher. It should be noted
that WPA2 is not supposed to be used with TKIP as the pairwise cipher.
Instead, CCMP is expected to be used and with that pairwise cipher, this
vulnerability is not applicable in practice.
When TKIP is negotiated as the pairwise cipher, the EAPOL-Key Key Data
field is encrypted using RC4. This vulnerability allows unauthenticated
EAPOL-Key frames to be processed and due to the RC4 design, this makes it
possible for an attacker to modify the plaintext version of the Key Data
field with bitwise XOR operations without knowing the contents. This can be
used to cause a denial of service attack by modifying GTK/IGTK on the
station (without the attacker learning any of the keys) which would prevent
the station from accepting received group-addressed frames. Furthermore,
this might be abused by making wpa_supplicant act as a decryption oracle to
try to recover some of the Key Data payload (GTK/IGTK) to get knowledge of
the group encryption keys.
Full recovery of the group encryption keys requires multiple attempts (128
connection attempts per octet) and each attempt results in disconnection
due to a failure to complete the 4-way handshake. These failures can result
in the AP/network getting disabled temporarily or even permanently
(requiring user action to re-enable) which may make it impractical to
perform the attack to recover the keys before the AP has already changes
the group keys. By default, wpa_supplicant is enforcing at minimum a ten
second wait time between each failed connection attempt, i.e., over 20
minutes waiting to recover each octet while hostapd AP implementation uses
10 minute default for GTK rekeying when using TKIP. With such timing
behavior, practical attack would need large number of impacted stations to
be trying to connect to the same AP to be able to recover sufficient
information from the GTK to be able to determine the key before it gets
changed.
References
CVE Name CVE-2018-14526
URL https://w1.fi/security/2018-1/unauthenticated-eapol-key-decryption.txt
- -------------------------------------------------------------------------------
Copyright (C) 2003-2005 Jacques Vidrine and contributors.
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
https://www.auscert.org.au/bulletins/
===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967
iQIVAwUBW3OYCmaOgq3Tt24GAQi+5hAAxGiutR++7eGeg+nB2GUMxbIX/1nGkq2I
/FQjRK9Z7L0dL+TZ/zY6J2a8TMOY+zvHTEXyX/BeMgc9qEPcZeOIaXhGHgEn+ghk
ZzV/0hMk+DYU7g/CxHTUa1Y93tgpKCWjHGLfmZDuptD9zbYXMrPeqRL6gDP4OXgy
/j+WJ04y8gHWvmOPFvIzydP0FYGM0MUfCYalpc72JNoGVblsCYzwRQZGF7jpqfHx
L6LEy7GCEO5viMM1PEW/H4jM1X4ecBgP2J+x2IhuKR7PbeNtcJwV56rPxKGU26xi
8302hoq1YLZvqxi7yJDq1AbLbfH6uNeqMt0V+pSu56EPoByv1cvnJGkP7VXDDh5/
LLAS3RMvpxQRzpiEEYxj4XFvn3mFpAq/CIwagaB+YI35rwjRON16c+ecQy+r8OSd
1qM5ylJxMf4q7ygZhaN3SP5vVDiUGfO9hB4jrT8Z6d0NWTTX8QJdtuEhLmhNE3LW
Bhj9OLLvdZQi535Kwz7IFon7tSJCV2aYQGwH10FcH3UirX8bCdw/bUv6lQFDE05W
4JkYrxETJuLMJUQMkhzR4wa4kMW6ko1d2DNDJTl76AsGZN3YbrSOmDri00HRIR36
0haiSIyZKobGKo6OGzGv0Jbyc3gGynomp4GOovxdQdzSwd4PyS5MayrB+zt3c66Y
uiWleDvjFBM=
=2kO0
-----END PGP SIGNATURE-----