Trying to prepare a talk on “security of wireless input devices”

…or…

Breaking link encryption of Logitech Unifying and popping shellz on air gapped

boxes.

Marcus Mengs (@MaMe82)

BSides KØbenhavn 2019

Me at work

• InfoSec

• for a German employer, since 2001

• Main task: Awareness trainings (>4000 IT-Users in area of responsibility)

• Occasionally involved in red & blue teaming tasks / international exercises

mame82@home:~# whoami

Marcus Mengs - @MaMe82

Interests: Family, Vulns, OffSec, new attacks, coding

Languages: what’s needed (C, Java, C#, Python, Go, PS, asm …)

Reports: Microsoft, Oracle, IBM, Invision, Logitech …

Certificates: Yes, one

Projects: P4wnP1, P4wnP1 A.L.O.A., Nexmon Mods Pi0W, covert channels (USB HID, WiFi, Unifying), LOGITacker

Currently: Bluetooth Low Energy (codename “BLExy”)

DISCLAIMER

Why Logitech wireless devices?

• Broadly used

• Several vulnerabilities and attacks published since 2010

• known (and utilized) in InfoSec community – not known / underestimated by most customers and many enterprises

• My working place: usage of wireless keyboards/mice not allowed

… so why bother?

Reality, at work …

Health-Check for screen-workers (doctor)

Logitech Receiver (Wireless Mouse)

Equipment for speakers

Logitech presentation clicker

… not at work, medical practice

Background: Logitech Unifying

• Small RF receiver (Dongle)

• Handles up to 6 wireless devices (Mice, Keyboards, Remotes, Gamepads etc.)

• Exposes USB HID devices to host (driverless)

• Since 2009 (backward compatibility)

• AES128 encryption

• 2.4 GHz ISM band - „Enhanced Shockburst“ (proprietary)

• Robust: utilizes up to 24 channels, short transmissions, ACK’ing

Background: Logitech Unifying

Prior Research

• KeyKeriki V2 (Thorsten Schroeder, Max Moser), 2010

• ESB Pseudo Promiscuous Mode with nRF24 (Travis Goodspeed), 2011

• KeySweeper (Samy Kamkar), 2015

• MouseJack (Marc Newlin), 2016

• „Of Mice and Keyboards“ (Gerhard Klostermeier, Matthias Deeg), 2016

• “Weaponizing BBC Micro Bit” (Damien Cauquil), 2016

• Presentation Clickers (Marc Newlin), 2019

• „New tales of Mice and Keyboards“ (G. Klostermeier, M. Deeg), 2019

Logitech Unifying: • no decryption, only injection • Available patches for all vulnerabilities patched (in theory)

Summary of known vulnerabilities

• Wireless keystroke injection for non-Keyboard devices (MouseJack)

• Unencrypted injection for encrypted devices (MouseJack)

• Encrypted Injection without key knowledge (KeyJack)

Firmware patches available since 2016, but factory deployment not assured

Common misconception: no direct attack against actual device (physical presence not required), injection is directed towards receiver (device impersonation)

Moving R&D to private area (spare time)

• colleague tests keystroke injection against presentation clicker

• Succeeds after 10 minutes, but it doesn’t work reliably

• More analysis and custom tool development required, to use it for awareness talks

• Lack of resources: specialized hardware, specialized software, development time

Solution: move R&D to private OS projects, develop in spare time, use results at work

Initial goal

• Improve available tooling (reliability, functionality)

• Publish as FOSS

• Usable for Live-Demos (awareness talks)

Initial questions (… and answers, with respect to time)

1. Channel hopping algorithm (robust device detection + reliable injection)• Driven by receiver (hops channels, adoptive scheme)• device hops until receiver is hit (determined by RX’ed ACK frame)

• … and we have bi-directional data exchange → back channel

2. ACK frames (reliable injection)• Payload AKCs: same as actual device frames• Receiver and device swap role for a short period (130us to toggle → requires fast sniffing)

3. Promiscuous mode for (device discovery)• Travis Goodspeed approach or SDR

Approach used

• Information Gathering• Prior Research (ESB, Modulation, CRC algorithms …)• FCC Databases (modulation, channels in use)• Public Logitech Drafts

• OSS projects like fwupd

• RF• SDR (Channel-Hopping, ESB ACK payloads) → too slow for realtime interaction

• Custom Tool “mjackit” (Golang, dongle/device emulation with dedicated hardware, fuzzing …)

• adjusted Marc Newlin’s nrf-research-firmware for nRF24LU1+ (fast sniffing, adjusted back channel using ACK frames)

• USB• USBPCap (analyze USB communication between host and dongle)

• Custom Tool munifying (Golang, USB device enumeration, pairing, flashing)

Sharing is caring ?!?!

Slightly adjusting the goal

Slightly adjusting the goalClient Agent- Shell- Communicates

using USB

Dongle- Acts as relay

between USB und RF- No hardware /

firmware changes !!

„Rogue RF device“- emulates paired

device- Communicates via

RF- C2 server for

Client-Agent

New challenges

• Arbitrary data generated by Client Agent has to be relayed from USB to RF by the Unifying dongle (USB to RF Relay)

• Arbitrary data generated by the „Rogue RF Device“ has to be relayed back to the USB host by the Unifying dongle (RF to USB Relay)

Requirements:

• No manipulation of the dongle (firmware/hardware)

• Don’t disrupt usability of connected devices

Solution HID++

source: Unifying Receiver DJ collection specification draft

USB HID generic interface- USB HID descriptor

„vendor specific“ - Generic HID

(driverless)- Concurrent

read/write by multiple processes (shared)

- low privileged access

USB HID keyboard and mouse interfaces- driverless- … but bound

OS-exclusive (no low level access)

Solution HID++

• proprietary, builds on top of generic USB HID interface (unprivileged access, from concurrent processes)

• bi-directional exchange (f.e. Device Battery Level) → implies communication is relayed to RF

• a bunch headroom for future extensions (transports yet undefined message types)

• invalid message type are replied with an error, but are transmitted anyways (without disrupting normal operation)

• RF and USB payload formats are very similar

• UNENCRYPTED transmission (at least for Unifying)

Communication Scheme (client agent perspective)

OUTBOUND• Agent sends invalid HID++ USB frame with arbitrary data, Unifying dongle relays to RF

• Real device rejects resulting RF frame (error reply)• “rogue device” passively sniffs and consumes data

INBOUND• “rogue device” sends invalid HID++ RF frame with arbitrary data• Unifying dongle relays all the way up to USB host (wants to be future proof)

• Logitech software stack (if installed) rejects• Client agent listens on same USB HID interface and consumes data (remember, sharable between processes)

Payload example – USB vs RF

• 17 bytes per frame

• throughput depends on injection frequency (vs. device usability)

New problem: Client Agent delivery

Obvious approach: Keystroke Injection! But all vulnerabilities have been fixed!

… so what? Maybe there are other ones

Suspicious aspects observed already• Only 8 Bytes pairing data are random (rest represent assignable device metadata)

• …but, a dedicated 128bit AES encryption key is used per device (likely generated during pairing)

• Transmitted cipher text for keyboard report is only 8 Bytes in length (+plain 32 bit counter → likely AES CTR)

Extending methodology

• Add RF tool which emulates a pairing device/dongle with different parameters (project mjackit)

• add USB tool capable of dumping/flashing dongle firmwares(project munifying)

• static firmware analysis (using radare2, free, 8051 support)

• Firmware-Patching (runtime AES keyextraction)

Result part 1 – RF payload encryption

Weak encryption algorithm

• Plain payload (representing pressed keys) is not encrypted with AES, instead it gets XOR-keyed with a fraction of the (per-frame) generated AES CTR cipher

• No usage of hardware AES CTR, but AES ECB (CTR in software)

• Input data for AES cipher generation is static and globally shared between all devices on market (mixed with per-frame counter)

• per device “pre-shared” key stays constant, till re-pairing

• Approach is vulnerable to known plaintext attacks (reversible XOR-keying) if counter could be reused

→ Was reusable, reported by Bastille (KeyJack), fixed in 2016

• Yet unencrypted: Mouse, Multimedia, Power, System Key and LEDreports (shutdown all boxes)

Result part 1 – RF payload encryption

E E E E E E E E CT CT CT CT C

CT CT CT CT

M K1 K2 K3 K4 K5 K6 C9

CY CY CY CY CY CY CY CY CY CY CY CY CY CY CY CY

S S S S S S S CT CT CT CT S S S S S

P E R D E V I C E K E Y

AES ECB

XOR

Result part 1 – RF payload decryption

E E E E E E E E CT CT CT CT C

M K1 K2 K3 K4 K5 K6 C9

CY CY CY CY CY CY CY CY CY CY CY CY CY CY CY CY

S S S S S S S CT CT CT CT S S S S S

P E R D E V I C E K E Y

AES ECB

XOR

Known plaintext - principle

With a minimum 23 valid frames of successive counters replay is still possible → ?? known plaintext ??

0 X 0 0 0 0 0 C9

CY CY CY CY CY CY CY CY

0 C 0 0 0 0 0 C9

E E E E E E E E CT CT CT CT C

E E E E E E E E CT CT CT CT C

XOR

XOR

Real world example – identifying key releases

Report ID

„set keep-alive“ report

Attack 1 – Revival of counter reuse (CVE-2019-13053)

Voila: known plaintext for 4 successive counters!

Encrypted KeyCounter n

Unencrypted LED (CAPS changed)

releaseEncrypted KeyCounter n+1

UnencryptedSET KEEP-ALIVE

CAPS LOCK

Encrypted KeyCounter n+2

Unencrypted LED (CAPS changed)release

Encrypted KeyCounter n+3

UnencryptedSET KEEP-ALIVE

CAPS LOCK

00 CA 00 00 00 00 00 C9

00 CA 00 00 00 00 00 C9

00 00 00 00 00 00 00 C9

00 00 00 00 00 00 00 C9

Demo – Encrypted Injection (KeyJack patch applied)

Placeholder video 1

Additional facts:

• Replaying 3 encrypted frames with valid counters disrupts functionality of real keyboard (if typing at the same time)

• Replaying 23+ frames works (f.e. lock screen password input)

• If plaintext for 23+ frames is known, they could be loop-replayed, with changing payloads for keystroke injection of arbitrary kength (corresponds to ~12 key presses or 12 times next slide button on encrypted presentation clicker)

Result part 2 – Key exchange / key generation

Extracted keys occur weak

• Low entropy, high equality amongst different keys

• Obviously weak key generation algorithm

• Likely no secure key exchange (only 8 random bytes exchanged during pairing)

Same Unifying dongle, different keys

Keyboard

Keyboard (re-paired)

Mouse (with keyboard functions)

08 38 E2 F2 C6 6B 26 C4 D4 88 94 4D 10 AD 40 58

08 38 E2 F2 18 6B 7E ED F9 88 B6 4D A3 8E 40 CE

08 38 E2 F2 6D 6B F8 78 4B 88 B2 4D 39 E6 40 B0

Result part 2 – Key exchange / key generation

Dongle serial (known + Pairing):Device WPID (guessable + Pairing):Dongle WPID (known + Pairing):Device Nonce (PRNG + Pairing):Dongle Nonce (PRNG + Pairing):

Plain key data(from pairing)

Resulting device key 08 38 E2 F2 C6 6B 26 C4 D4 88 94 4D 10 AD 40 58

E2 38 6B F2 40 4D 88 08 D4 26 C6 58 94 10 C4 AD

E2 C7 94 F2 40 4D 88 08 D4 73 C6 58 6B 10 C4 F8

XO

R 55h

XO

R 55h

XO

R FFh

XO

R FFh

XO

R FFh

E2 C7 94 F2

40 4D

88 08

D4 73 C6 58

6B 10 C4 F8

Demo – Sniff Pairing, live decryption (demo)(CVE-2019-13052)

Placeholder video 2

Demo - Combine everything and gimme Shellz (demo)

Placeholder video 3

A good thing about housekeeping…

• While cleaning up docs and code, stumbled across notes on undocumented HID++ commands which haven’t been investigated

• One of the commands, allows byte-wise read from arbitrary flash addresses

• For dongles with Texas Instruments chip, this allows reading flash regions, which contain plain AES key data (could give a nice low priv MSF payload)

USB dumping of ALL device keys (demo)(CVE-2019-13055 / CVE-2019-13054)

Placeholder video 4

Impact / attack scenarios

• All Logitech Unifying, Lightspeed and some other devices affected (R500, Spotlight …)

• Receivers with outdated firmware in stores, hard to patch for customers

• supply-chain attacks (key extraction via USB / re-pairing)

• post-capture key-stealing and decryption

• not much attention since 2016

• Close range attacks, but could be carried out with very small low cost device (drop attacks)

Vendor Response

• Feb 11, 2019 - first contact (engineering team)

• till Apr, 2019 - ongoing exchange on reporting modalities and technical details

• Apr 04, 2019 - feedback, working to fix ALL issues

• May 14, 2019 - Final decision:• won’t fix CVE-2019-13052 (pair sniffing)• won’t fix CVE-2019-13053 (injection without AES key)• Fix planned CVE-2019-13055 (USB key extraction)

• May 2019 - more devices affected → handover to nat. CERT and press (CVE-2019-13054)

• Aug 29, 2019 - patch release CVE-2019-13055

• Aug 30, 2019 - demo of patch bypass, disclosure of complete research material and tools

Joyning forces with Luca Bongiorni…

#USBSamurai received MUNIFYING treatment and meets LOGITacker (demo)

Placeholder video 5

Outcome ? Few patches, many tools !

github.com/mame82…../UnifyingDisclosureRepo – vendor reports, raw docs, PoC tools

../mjackit – all RF PoCs using CrazyRadio PA

../munifying – USB PoCs, firmware cross-, down- and upgrade for almost all Logitech receivers

../LOGITacker – dedicated - easy to use - hardware tool; implements most attacks; Unifying covert channel; USB keystroke injection; device emulation; runs on 10$ nRF52840 dongle; adds encryption/decryption for LIGHTSPEED receivers; requires no external software stack

→ don’t miss Niel’s workshop on LOGITacker

Credz (only a few)

- Luca Bongiorni

- Rogan Dawes (+SensePost Team)

- Damien Cauquil

- Travis Goodspeed

- Marc Newlin

- Matthias Deeg & Gerhard Klostermeier

- Ronald Eikenberg

- Milan Gabor

- @NielDK

- Laurent Gillet

Q&A