Thread by @mame82

About one and a half years ago, I disclosed several security issues affecting @Logitech wireless peripherals (mainly "Unifying" brand, but others - e.g. "G-Series Lightspeed" - are affected too).

Because of recent requests, I want to briefly review the flaws

1/n

1) CVE-2019-13053 covers a an issue, which allows an attacker to inject encrypted keystrokes over the air, without knowing the actual encryption keys. The root cause is unproper protection against counter reuse for underlying AES CTR.

In order to exploit this ...

2/n

... is required to get knowledge of about 8 keypresses while sniffing encrypted wireless traffic. This step is only required once. If the victim uses a clicker - for example - an attacker could get knowledge on a pressed key sequence, by observing how the slides ...

3/n

change (everytime the next slide appears, it could be safely assumed that the pressed key was "Cursor RIGHT").

Once about 8 "plain" key presses are known, the attacker could exploit the flaw to wireless inject an unlimited amount of arbitrary key presses.

4/n

Another to get knowledge on pressed keys: The attacker triggers the key presses herself (a few seconds of device access are enough, as that has only to be done once). For LED triggering keys (NUM LOCK, CAPS LOCK etc), this could be further automated, as the protocol leaks...

5/n

metadata, which allows to identify those special keys, even if transmissions are encrypted.

A demo for this approach was shown here:


Logitech clarified that the issue WILL NOT BE ADDRESSED

6/n

While allowing keystroke injection, the issue described above would not allow to eavesdrop wireless key presses from an encrypted keyboard, because the encryption keys are unknown to the attacker.

But there are two other flaws, which allow to obtain the encryption keys:

7/n

2) CVE-2019-13052 covers a flaw, which allows an attacker to obtain the link encryption key in case he is able to sniff a wireless pairing of a device and a dongle.

While this technique works fully passive and wireless, chances are low that such a pairing occurs ...

8/n

in real world scenarios (the devices and dongles ship pre-paired). Still, with one time physical access, an attacker would be able to unpair and re-pair the devices. The time required to do so would be a few seconds and the newly assigned encryption keys could be sniffed.

9/n

Again, this procedure is only required once in order to empower an attacker to wireless eavesdrop pressed keys or inject keys forever. There is no user indication for the encryption key compromise (everything works as intended).

Demo:

10/n

Again, Logitech clarified that the issue WILL NOT BE ADDRESSED.

Manual enforcement of re-pairing to enroll the described attack, would require one time physical access to device and receiver.

But there exists a similar flaw, which requires only receiver access...

11/n

3) CVE-2019-13055 described a flaw, which allowed to dump the link encryption keys directly from a receiver via USB.

The issue depends on the SoC used by the receiver (only affects Texas Instruments, not Nordic Semiconductors), but most new receivers are vulnerable.

...

12/n

Dumping the keys from a receiver with one time physical access (to the receiver, not the host) takes less than 1 second and was demoed here:

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

13/n

In contrasts to the other flaws, Logitech put some efforts into patching this one. Receivers with latest firmwares should not be vulnerable, but the patch could be bypassed by simply downgrading the firmware to a vulnerable on before stealing the keys.

14/n

The downgrade-bypass requires 23 additional seconds, before keys could be dumped again (for receivers without signed firmware it is even less).

This was demoed here:

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

15/n

For receivers which check firmware signatures, a vulnerable signed firmware is required for the bypass. Respective firmwares are publicly available for:

- all affected Unifying receivers
- Lightspeed receivers
- NOT available for "Spotlight" clicker receiver

16/n

There are still chances of being able to dump keys from a fully patched Logitech "Spotlight" receiver, by "cross-flashing" the receiver with a vulnerable (but signed) Unifying firmware and re-flash it with the legacy firmware once keys have been dumped.

17/n

I was not able to test the latter, as my test device was only borrowed from a supporter. Also, it would be less interesting to eavesdrop a clicker, but arbitrary keystroke injection remains a valid goal for such an attempt.

So far it goes for the vulns, nut there is more..

18/n

Almost all wireless Logitech use a proprietary protocol called HID++ (build on top of USB "Human Interface Device" protocol). All implementations of the protocol are backwards compatible to its very 1st version and provide room for an attacker to hide arbitrary data in it.

19/n

Moreover, the HID++ protocol works bi-directional, which means data could injected wireless and ends up on the USB port of the host which has the receiver attached ... and ... USB data generated on the host could be transmitted wireless and sniffed from the outside.

20/n

I want to be very clear, that these conditions are met for all Unifying devices (and many other Logitech devices) BY DESIGN. In addition, the wireless version of HID++ data is transmitted unencrypted for Unifying (for Lightspeed receivers a key is needed).

This means..

21/n

an attacker could abuse the HID++ protocol to bring up a covert channel via a Logitech receiver WITHOUT THE NEED TO MODIFY THE RECEIVER OR INTERFERING WITH ITS NORMAL FUNCTIONALITY.

Demo - covert channel remote shell with a "Spotlight" receiver:

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

22/n

Because this is intended functionality, there will be no patch.

Another demo extends the approach by implanting a Logitech receiver into an USB cable.
The client payload for the covert channel gets typed out invisibly (the target is air-gapped)

23/n

So to sum up:

- 1 out of 3 vulnerabilities was patched
- the patched could be bypassed
- abusing HID++ for covert channel communications will always be possible

There exists patched receivers for clickers like the R400, which effectively prevent ...

24/n

... arbitrary keystroke injection (by not allowing physical key presses which do not map to buttons on the clicker). Still it would be possible to exploit those receivers for covert channel communications.

25/n

So for mitigation:
- Only use receivers which are patched against keystroke injection (ask Logitech support, not me)
- disconnect the receiver when not used
- assure nobody can access the receiver
- alternative: avoid wireless input

26/n

If you want to test your devices yourself, I provided a tool which runs on USD10 hardware. It is called LOGITacker and covers almost all techniques mentioned here. It was designed to counter Logitech's argument "the attacks are hard to deploy"

github.com/RoganDawes/LOG…
27/n

Finally, if you are interested in more details I suggest to watch my (only public) talk given at @bsideskbh on the topic:

vimeo.com/378870549

28/n

I hope this answers most of the question I was facing recently. To my best knowledge, not much has changed since the disclosures, but it is hard to keep track of or test each individual receiver/device combination (again, LOGITacker is there for testing).

Stay safe, MaMe82
29/29

In tweet #22 I linked the wrong demo.

Here's the correct one for the remote shell on using the receiver of a clicker

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