Tag Archives: driver

WPA2 KRACK Vulnerability: What you need to know

Last Sunday, the early signs of a vulnerability disclosure affecting the extensively used Wi-Fi protected access (WPA2) protocol were evident. The next day, disclosure of the vulnerability lead to more details. The vulnerability was discovered by  two researchers Mathy Vanhoef and Frank Piessens of the Katholieke Universiteit Leuven (KU Leuven) while examining OpenBSD’s implementation of the WPA2 four way handshake.

Why should this vulnerability be considered important?
On Monday 16th October, the KRACK (key re-installation attacks) vulnerability was disclosed. This vulnerability was found within the implementation of the WPA2 protocol rather than any single device making it’s impact much more widespread. For example, vulnerable devices include Windows, OpenBSD (if not already patched against it), Linux, Apple iOS, Apple macOS and Google Android.

If exploited this vulnerability could allow decryption, packet replay, TCP connection hijacking and if WPA-TKIP (defined) or GCMP (explained) are used; the attacker can inject packets (defined) into a victim’s data, forging web traffic.

How can an attacker exploit this vulnerability?
To exploit the vulnerability an attacker must be within range of a vulnerable Wi-Fi network in order to perform a man in the middle attack (MiTM)(defined). This means that this vulnerability cannot be exploited over the Internet.

This vulnerability occurs since the initial four way handshake is used to generate a strong and unique key to encrypt the traffic between wireless devices. A handshake is used to authenticate two entities (in this example a wireless router and a wireless device wishing to connect to it) and to establish the a new key used to communicate.

The attacker needs to manipulate the key exchange (described below) by replaying cryptographic handshake messages (which blocks the message reaching the client device) causing it to be re-sent during the third step of the four way handshake. This is allowed since wireless communication is not 100% reliable e.g. a data packet could be lost or dropped and the router will re-send the third part of the handshake. This is allowed to occur multiple times if necessary. Each time the handshake is re-sent the attacker can use it to gather how cryptographic nonces (defined here and here) are created (since replay counters and nonces are reset) and use this to undermine the entire encryption scheme.

How can I protect myself from this vulnerability?
AS described in this CERT knowledge base article.; updates from vendors will be released in the coming days and weeks. Apple (currently a beta update) and Microsoft already have updates available. OpenBSD also resolved this issue before the disclosure this week.

Microsoft within the information they published for the vulnerability discusses how when a Windows device enters a low power state the vulnerable functionality of the wireless connection is passed to the underlying Wi-Fi hardware. For this reason they recommend contacting the vendor of that Wi-Fi hardware to request updated drivers (defined).

Links to affected hardware vendors are available from this ICASI Multi-Vendor Vulnerability Disclosure statement. Intel’ security advisory with relevant driver updates is here. The wireless vendor, Edimax also posted a statement with further updates to follow. A detailed but easy to use list of many vendors responses is here. Since I use an Asus router, the best response I could locate is here.

======
Update: 21st October 2017:
Cisco have published a security advisory relating to the KRACK vulnerability for its wireless products. At the time of writing no patches were available but the advisory does contain a workaround for some of the affected products.
======

The above updates are software fixes but updates will also be made available for devices in the form of firmware updates e.g. for wireless routers, smartphones and Internet of Things (IoT)(defined) devices. For any wireless devices you own, please check with the manufacturer/vendor for available updates with the above CERT article and vendor response list detailing many of the common vendors.

Thank you.

HP audio driver contained keylogger

Late last week it was announced the security firm Swiss security firm ModZero had responsibly disclosed (defined) to HP back in early April 2017 their discovery of an audio driver (Conexant HD Audio) containing a keylogger. The driver is known to be present on 28 HP devices (listed here).

Conexant also creates drivers to Asus, Lenovo and Dell, at this time it is not clear if they use the same driver (security analysts have been unable to discover any other devices using the affected driver).

How can I tell if my HP (or other device) is affected by this vulnerability?
This BleepingComputer article explains how to check for this vulnerability.

Why should this vulnerability be considered important?
The affected audio driver (versions 1.0.0.31 up to and including 1.0.0.46) contained the issue with the issue first being created in December 2015. Thus it has the potential to have gathered a vast quantity of information since this time.

Not only does the driver record key presses (using a low-level keyboard input hook (defined)) but the driver exposes the OutputDebugString and MapViewOfFile APIs (API, defined). The OutputDebugString API enables any running application to capture keystrokes while MapViewOfFile enables any framework or application with access to MapViewOfFile API to do the same.

Since the unencrypted keystrokes are stored in a text file, forensic investigators with access to the log file (stored at C:\Users\Public\MicTray.log) could potentially recover previously saved sensitive data (a reboot or power of the device clears the file). When backups of the affected systems are performed previous versions of this file would contain further captured (and potentially sensitive) information.

Since our keyboards are used to enter all kinds of sensitive information,  emails, chat/instant message conversations, social media posts, credit card numbers etc., this vulnerability could have serious consequences If the log contents were to be obtained by cyber criminals. The file might also contain credentials (usernames/passwords for the above mentioned activities.

From the information disclosed about this vulnerability, there is evidence to suggest the driver uploads/sends the information it gathers within that log to HP, Conexant or anyone else. However if you are creating unencrypted backups within a corporate, small business or consumer environment this file over time will contain more and more information gathered over time. If someone knew you create these backups and knew where to look within them (assuming they are not encrypted), they could gather significant volumes of sensitive information.

How can I protect myself from this vulnerability?
After ModZero disclosed this information to HP, HP made available a driver update (version 10.0.931.90) which removes the keylogging behavior. Moreover, the driver update will be made available via Windows Update for both 2016 and 2015 HP devices. HP Vice President Mike Nash clarified the logging feature of the driver was simply debugging code (defined) inadvertently left within the driver.

If you followed the steps above to check if your device was vulnerable but there is no driver update available, the same BleepingComputer article describes how to mitigate the vulnerability.

Thank you.