Skip to content

Latest commit

 

History

History
274 lines (185 loc) · 14.4 KB

logitech_vuln_summary.md

File metadata and controls

274 lines (185 loc) · 14.4 KB
Raw

The repo holding all the disclosure material for the research is published here: https://github.com/mame82/UnifyingVulnsDisclosureRepo

Summary / Overview of known Logitech wireless peripheral vulnerabilities

There has been a ton of research on wireless input devices using proprietary 2.4 GHz radio technology. Lately, I reported some new vulnerabilities for Logitech devices, myself, and noticed that one could easily get confused by all those issues.

So here is an attempt to clarify some things.

This document focuses on Logitech devices only, as other vendors haven't been part of my own research.

General information

In context of attacks on Logitech devices, the device itself is often assumed to be vulnerable. Especially for keystroke injection attacks, this is not the case. The vulnerable part is the wireless receiver. In fact, in order to carry out a keystroke injection attack, the actual input device does not even have to be in range. This is because the attacker is communicating with the receiver via RF while impersonating a real device.

The actual device is only of interest for the questions:

  • Does the receiver allow keyboard input for the impersonated device or not (has the impersonated device keyboard capabilities, even if it is not a keyboard)?
  • If the receiver accepts keyboard input, does it have to be encrypted (the attacker would need a valid encryption key to impersonate the device)?

The answer to these questions are known by the receiver, because the data of paired devices is stored. If the receiver behaves according to those answers, depends not only on the stored device data. It additionally, it depends on the patch level of the respective receiver. This is because some vulnerabilities discovered by Bastille (Marc Newlin) back in 2016, exploited misbehavior:

  • An unpatched receiver could accept unencrypted keyboard input, even if the impersonated devices should only communicate encrypted (plain injection for encrypted devices)
  • An unpatched receiver could be forced to register a new device, which always accepts plain keystrokes (forced pairing)

It should be noted, that an impersonated device does not have to be a wireless keyboard. Most mice, all presentation clickers and various other devices are able to emit keyboard input. Ultimately, the receiver would accept keystrokes from an attacker impersonating such a device, f.e. a mouse.

Known vulnerabilities (partially undisclosed)

1) Plain keystroke injection / plain keystroke injection for encrypted devices

Description

A remote attacker could inject arbitrary keystrokes into an affected receiver. In most cases (if no additional key filters are in place) this directly leads to remote code execution (RCE) and thus full compromise of the host with the receiver attached.

Most Logitech presentation clickers accept plain keystrokes (f.e. R400, R700, R800). The only thing needed by an attacker to impersonate the actual device is the RF address in use. This address could be discovered by monitoring RF traffic (pseudo promiscuous mode as proposed by Travis Goodspeed or Software Defined Radio). Once the address is obtained, the attack could be directly carried out.

Additionally, older Unifying receiver firmwares accept unencrypted keyboard frames from impersonated devices, which should only send encrypted keyboard frames. Again, an attacker only needs to discover an RF address for such a device in order to carry out the attack.

Those kinds of attack are known since 2016. Still today, Unifying receivers could be bought, which aren't patched against those attacks.

References

Demos

2) Encrypted keystroke injection without key knowledge (patched)

Description

Wireless Logitech keyboards encrypt keystrokes before sending them to the receiver. A custom AES CTR implementation is used to prevent an attacker from injecting arbitrary keystrokes. The implementation of Unifying receivers with outdated firmware have multiple issues:

  • The receiver does not enforce incrementation of the AES CTR counter for successive RF frames. This allows replay attacks and reuse of the counter with a modified cipher text
  • If the plaintext of an encrypted keyboard RF frame is known, an attacker could use this to recover the key material used to encrypt the frame with this specific counter. Ultimately, the attacker is able to modify the respective RF frame with new plaintext (other key presses). In combination with the ability to re-use the counter, the attacker could inject arbitrary keystrokes.
  • Encrypted key release frames are easy to identify while monitoring RF transmissions and could be used for a known plaintext attack.

Note: The issue exists for Unifying receivers not patched against the respective vulnerability, which was called "KeyJack" by Bastille. So this is a good example for a vulnerability not directly depending on the device.

References

3) Encrypted keystroke injection without key knowledge (no patch from vendor)

Description

Logitech provided patches for the issue "encrypted keystroke injection without key knowledge":

Beside the fact, that not all dongles in market have the respective patches applied, they could be bypassed by an attacker. No patches exist for the extended version of the attack and Logitech confirmed, that no patch will be provided for this new vulnerability.

In contrast to the existing version of the attack, the new version requires that an attacker gets one-time physical access to the wireless device, in order to enforce arbitrary key-presses. The goal of the attacker is to generate more known plaintext, while capturing cryptographic data from RF. The collected cryptographic data than could be used, to carry out an attack similar to the one described above, but additionally bypass the AES counter re-use protection applied with the latest patches. Physical access is only required one time. Once the data has been collected, arbitrary keystrokes could be injected, when and as often as the an attacker likes.

A possible attacker only needs some seconds to generate the key-presses needed to break encryption (12 to 20 times pressing the same key).

Note on presentation clickers: The goal of the physical key presses is to generate a sufficient amount of known plaintext (which could be derived from information leaks during RF transmissions by an attacker). In case of encrypted presentation clickers, this step usually gets obsolete, because an attacker has other possibilities to get to know of the plaintext for encrypted keyboard reports (Visual identification of pressed key, by watching the presentation controlled with the clicker. F.e. if next slide is shown, it is clear which plain key was pressed on the clicker before encryption took place). Because of this fact, the attack could be simplified to a remote approach, only.

References

  • CVE-2019-13053
  • vendor report (will be released soon)

Demos

4) Passively obtain Logitech Unifying link encryption keys by capture of pairing (RF only, no patch from vendor)

Description

Weak key exchange and encryption allow an attacker to derive the per-device link-encryption keys, if the attacker is able to capture a pairing between the device and receiver from RF. Additionally, an attacker with physical access to device and receiver could manually initiate a re-pairing of an already paired device to the receiver, in order to obtain the link-encryption key. There exists no possibility for the user, to notice that the respective key has been compromised.

Thus, beside being a passive remote attack (RF), the attack could be modified to a drive-by approach or supply chain attack.

With the stolen key, the attacker is able to inject arbitrary keystrokes (active), as well as to eavesdrop and live decrypt keyboard input remotely (passive). This applies to all encrypted Unifying devices with keyboard capabilities (f.e. MX Anywhere 2S mouse).

Logitech confirmed, that no patch will be provided for this new vulnerability.

References

  • CVE-2019-13052
  • vendor report (will be released soon)

Demos

5) Actively obtain link encryption keys by dumping them from receiver of Unifying devices (physical access, patch will be supplied)

Description

Due to undocumented vendor commands and improper data protection of some Logitech Unifying receivers, an attacker with physical access could extract link encryption keys of all paired devices in less than a second.

Logitech is going to provide a patch for this issue in August 2019.

With the stolen key, the attacker is able to inject arbitrary keystrokes (active), as well as to eavesdrop and live decrypt keyboard input remotely (passive). This applies to all encrypted Unifying devices with keyboard capabilities (f.e. MX Anywhere 2S mouse). Additionally there is no need to discover the device "on air" to carry out a keystroke injection attack, as the address is pre-known from the extraction (targeted attack possible, actual device doesn't have to be in range - only the receiver)

Logitech confirmed, that a patch will be provided for this new vulnerability in August 2019.

References

  • CVE-2019-13055
  • vendor report (will be released once patch is available)

Demos

6) Actively obtain link encryption keys by dumping them from receiver of encrypted presentation clickers (physical access, patch will be supplied)

Description

Due to undocumented vendor commands and improper data protection of some Logitech presentation clicker receivers, an attacker with physical access could extract link encryption keys of all paired devices in less than a second.

The exact same attack vector described in CVE-2019-13055 applies, thus this is assumed to be fixed along with the respective Unifying vulnerability in August 2019 (vendor has been informed on the issue, which is technically the same).

With the stolen key, the attacker is able to inject a subset of possible keystrokes (active). Additionally there is no need to discover the device "on air" to carry out a keystroke injection attack, as the address is pre-known from the extraction (targeted attack possible, actual device doesn't have to be in range - only the receiver).

In contrast to Logitech Unifying devices, there is no user accessible functionality to exchange the AES key of the presentation clicker, once it has been compromised.

In addition to applying encryption, the receiver of affected presentation remotes filters out some keys, like A to Z, otherwise the devices act as standard keyboard.

On Microsoft Windows operating systems, this "key blacklisting" protection could be bypassed, using (not filtered) shortcuts, which produce arbitrary ASCII characters as output. From an attacker's perspective this eliminates the need to obtain the keyboard layout used by the target, as the shortcut based approach is language independent.

Logitech only confirmed to fix the key exteaction vulnerability. There is no information on planned Mitigations for the key filter bypass.

Update July 3rd, 2019: The announced Logitech patch also includes further measures to mitigate potential plain injections (those measures will then be effective on R500 and Mx Anywhere mouse)

Devices known to be affected are:

  • Logitech R500
  • Logitech SPOTLIGHT

References

  • CVE-2019-13054
  • vendor report (will be released once patch is available)

Demos

7) Forced Pairing

Description

A remote attacker could pair a new device to a Logitech Unifying receiver, even if the user has not put the dongle into pairing mode. This newly paired device could be used by the attacker to inject keystrokes into the host which has the Unifying dongle connected. The new device doesn't necessarily have to be presented to the user as keyboard, as other devices (f.e. mice) could be created with keyboard input capabilities, too.

This issue does not lead to eavesdropping of already paired keyboards.

Reference

Demos

Disclosure

Planned timeline on Twitter:

https://twitter.com/mame82/status/1144356418130194432