Keykeriki v2 Cansec v1.1

Download as pdf or txt
Download as pdf or txt
You are on page 1of 63

Practical Exploitation

of
Modern Wireless Devices
Thorsten Schroeder
[email protected]

Max Moser
[email protected]
Warning!
 Verifying the security of someone else's data
transmission or injecting stuff without permission
could send you (or the other guy) to jail in most
countries :-)
What is this talk all about?
 Brief History
 Nordic Semiconductor Radio
 Practical Exploitation of…
 … other Mobile Devices
 Demo & Release – Remote Code Execution
History
Evolution
 Infrared (Not part of this talk)
 27 MHz Radio
 Bluetooth 2.4 GHz Radio
 Proprietary 2.4 GHz Radio
What is it?
 27 MHz frequency band (Citizen Band)
 Miller encoded radio signal
 Proprietary protocols
 Approx. 90 cm guaranteed max. working distance
 Low cost
 Battery demanding
What is wrong?
 Pure one way communication
 “Encryption” absent or only optionally available
 No protection against replay attacks
 No (Message) Authentication
Logitech Packets (27MHz)
a(down)
000000100 10001001001 0000011110 1 00000
Keyb 1
a(down)
000000100 100111001111 0000011110 1 0001000
Keyb 2
a(up)
000000100 10001001001 0000011110 0 00000
Keyb 1
a(up)
000000100 100111001111 0000011110 0 0001000
Keyb 2
b(down)
000000100 10001001001 0000000101 1 0101
Keyb 1
b(down)
000000100 100111001111 0000000101 1 0100000
Keyb 2
b(up)
000000100 10001001001 0000000101 0 0101
Keyb 1
b(up)
000000100 100111001111 0000000101 0 0100000
Keyb 2

? Keyboard ID Keystroke State ?


Tools Anyone?

 Radio transceiver + Taperecorder == replay


 Two identical receiver + Sync == FAIL
 Sniffing => Keykeriki V1
Keykeriki V1
 Released in May 2009 at PH-Neutral
 Capable of sniffing Microsoft, Siemens-Fujitsu,
Logitech, …
 SDCard for persistent Storage of data
 On-the-Fly Crypto Analysis /Cracking
Attack Limitation
 Full wavelength of 27 MHz is about 11 meters 
huge antennas
 Error correction not part of the design & not
implemented. Therefore limited range
 Injection is limited to replay because some minor bits
are still unknown within the packet format
Bluetooth Keyboards
What is it?
 Popular transmission technique in mobile area
 Security features are implemented within firmware
and not directly accessible from operating system
 Pairing process
 Encryption / Key exchange
 Fast frequency hopping makes sniffing more difficult
What is wrong?
 Bluetooth transmission modules are expensive ⇒
Expensive keyboards
 During pairing process all pre-requirements for a
successful PIN-cracking can be sniffed - “Simple
Pairing” should fix this
 Buggy implementations (Complexity)
 Overdesigned
Tools Anyone?
 GnuRadio
 Frontline FTE4BS™
 Flashing old Frontline FW on CSR Bluecore 3
dongles
Attack Limitation
 Sniffing is possible but kind of “unstable”
 All pre-requirements for a successful PIN-cracking
can only be sniffed during pairing
 Complex documentation
 GnuRadio or FTE4BS™ are expensive
 Rarely used
Proprietary 2.4 GHz
based Keyboards
What is it?
 Not Bluetooth, not Zigbee, not 802.11xyz
 Most devices operating with1 Mbit/sec some at
rates up to 2 Mbit/sec
 Nordic Semiconductor NRF24XXX family widely
used
 Compact form factor (e.g. 2.4 GHz antenna, small
IC devices, …)
 Faster, less TX time  less power consumption
Vendor Specific Responsibilities
 Any radio based keyboard vendor is responsible
for:
 Computer System Protection
 Authentication

 Data Protection & Integrity

 USB receiver is single line of defense (in case of


keyboards for example)
Proprietary 2.4 GHz
based Devices
Nordic Semi NRF24xxx

(Source: Nordic Semiconductor)


Enhanced Shockburst™

Packet
CRC
Preamble Address Control Payload
Field
1-2
1 Byte 3-5 Byte 0-32 Byte
Byte
9 bit

 How does it work?


 Nordic Multiceiver concept Packet Control Field
 Multiple RX data pipes 6 bit Payload Length
2 bit Sequence / Packet ID
 One channel at a time
1 bit Disable Auto ACK
 Dynamic Payload Len
Raw Shockburst Processing
 Difficulties
 Speed (2 Mbit/s is fast!)
 Auto-Ack and Retransmission Features vs.1 Mbit
solutions
 Direct Baseband Signal Access / Interface
How NRF24xxx works
 Detect valid Enhanced Shockburst Frame:
8 bit preamble (0xAA or 0x55)
 3-5 byte device address

 CRC (if enabled) must match

 Otherwise it is considered being noise


NRF24L01+ Interface
 Config and Data Transmission via SPI (Serial
Peripheral Interface) using FIFO buffers
 There is no way to access radio layer directly
 Target system„s device address must be known to
read/write data from/to the remote device
Nordic Semi NRF24 Direct Mode
 Direct Mode allows Software Defined Radio
 Additional pin on tranceiver module which toggles
all the time, allowing an MCU doing the raw data
processing (SDR)
 Only available as non-„Enhanced“ Shockburst with
speeds <1mbit/s
Radio Layer
 Raw (valid) Data
Setting up a sniffer
 Capture raw Enhanced Shockburst Traffic at
2mbit/sec
 Detect Preamble
 Get device addresses
 Decide wether it is a valid device
address/Enhanced Shockburst Frame or not
 Configure NRF24L01+ device via SPI using that
address
 But… how to capture the raw data…?
Alternative 2.4GHz transceiver
modules
 We have found a chip vendor in Taiwan who
produces a 2.4GHz transceiver with a „Direct
Mode“ pin
 Documentation was... Hmm… quite OK
Challenges
 Remote: NRF Module (TX) with 30ppm crystal
 Local: Amiccom A7125 (RX) with 10ppm crystal
 Asynchronous radio transmission at 2mbit/sec 
Clock drift is a real problem when building
hardware tool with SDR
 500 ns (nano seconds) processing time per bit
 A 100 MHz CPU has 10 ns per clock cycle
Challenges (cont„d)
 We are looking for an unknown 5 Byte value (device
address)
 We know, an 8 bit preamble is located right before the
device address, and we know the value (0xAA)
 There is a well defined 9 bit Header right after the
device address – the first 6 bit are known to be less then
32
 We need to match <preamble>unknown<len <=
32>unknown .. Within a 2mbit/s noise stream
 Many false positives, still no way to verify a valid
address
500 ns
 Using a 100 MHz CPU we have 50 cycles during 500ns
 Having a 2 mbit/s timer interrupt for processing, we
have an IRQ handler overhead of approx. 20 cycles.
 30 CPU cycles left for:
 Read current value of A7125„s Direct Output pin
 Shift new bit in LSb of a 3x32 bit hardware CPU register
chain:
trash  [reg 3]  [reg 2]  [reg 1]  I/O bit input (new)
 Match Preamble in MSB in [reg 3]
30 CPU cycles left (cont„d)
 Mask Enh. Shockburst Header length value (6-bit)
 Check wether value is 0, 8, 16 or 32 byte (most likely)

 If it matches, calculate very basic „hash“ value of


address in reg 3 and reg 2 – then increment
address match counter
 Check address match counter & decide wether address
might be valid or not
 Disable timer interrupt
30 CPU cycles left (cont„d)
 Disable A7125 module
 Enable NRF24L01+ module

 Set RX/TX address

 Act like a genuine device, using the valid Enhanced


Shockburst device address
 BTW: We might have used an FPGA or CPLD, but
this would have been too easy ;-) *
* In fact we are currently working on this thing
Keykeriki V2 (beta)
 We built a hardware device, based on an NXP
LPC17xx ARM Cortex-M3 Microcontroler at 100
MHz with a Software Defined Radio Firmware
 We are using two different radio transceiver
modules
 Because we are lazy (SPI + FIFO is easier), less code
 less errors
 Because of probable legal issues
 And of course: Using the Nordic Semi chip is consuming
less power
Remember the vendor
responsibilities?
Microsoft Hardware
Payload Analysis
 To be able to successfully TX or RX/parse packets,
we need to understand how their protocol works
 Findthe checksum algorithm (necessary for TX)
 Analyze content, find and understand cryptographic
algorithms
 Sequence IDs

 Etc

 Capture/Replay could be helpful


Microsoft Payload
0a 78 6 1 df 88 4b 0a c0 C9 88 8 0a c0 cd 57

0a 38 6 1 df 88 8 d2

Keystrokes "a b
0a 38 6 1 df 88 8 d2
 0a 38 6 1 df 88 8 d2

<space>"
0a 38 6 1 df 88 8 d2

0a 38 6 1 df 88 8 d2

0a 78 6 1 DE 88 4b 0a c0 CD 88 8 0a c0 cd 52

 Recognizable Patterns 0a 78 6 1 D9 88 4b 0a c0 C8 88 8 0a c0 cd 50

 First 4 Byte: Header: 0a

0a
38

38
6

6
1

1
d9

d9
88

88
8

8
d4

d4

 Device Class ID
0a 38 6 1 d9 88 8 d4

0a 38 6 1 d9 88 8 d4

 Packet Type ID
0a 38 6 1 d9 88 8 d4

0a 78 6 1 D8 88 4b 0a c0 CD 88 8 0a c0 cd 54

 Model ID 0a 78 6 1 DB 88 4b 0a c0 E1 88 8 0a c0 cd 7B

0a 38 6 1 dB 88 8 d6

 Unknown Packet Header 0a 38 6 1 dB 88 8 d6

0a 38 6 1 dB 88 8 d6
Sequence ID / Counter
0a 38 6 1 dB 88 8 d6
Metakey Flags / Bitfield
0a 38 6 1 dB 88 8 d6
HID code 0a 78 6 1 DA 88 4b 0a c0 CD 88 8 0a c0 cd 56
Checksum
Microsoft Payload Encryption

C 0A 78 06 01 C2 98 76 0A C0 C8 98 35 0A C0 CD 5B
K CD 98 35 0A C0 CD 98 35 0A C0 CD
P 0A 78 06 01 0F 00 43 00 00 05 00 00 00 00 00
Device type

Packet type

Sequence ID

Flags/Meta

HID Code

Checksum
Model

(Key-Down) Packet with device address


CD 98 35 0A C0
Microsoft Encryption & Checksum
Algorithm
ctx->const_down = ctx->const_up = ~ctx->address[1];
...
cksum = ctx->const_down;

for(i=0;i<4;i++) {
ctx->c_down[i] = ctx->p_down[i];
cksum ^= ctx->p_down[i];
}

for(i=4;i<15;i++) {
cksum ^= ctx->p_down[i];
ctx->c_down[i] = ctx->p_down[i] ^ ctx->secret[i % 5];
}
ctx->c_down[15] = cksum;
Microsoft Mouse
 Data (x/y) is not encrypted
 Mouse button press/idle/releases are also simply
HID codes
 Mouse has Device Class ID 0x08
Limited to Keyboards?
Obviously
Apartment Whispering?
Election / Voting?
Sports / Health
Dragos, see the issue?
What is going through your mind,
when you see terms like…
 Identification Keypad Module
 In/Out Module
 GSM Module
 Driver Identification Module
 Engine Blocking Module
 … all interconnected within cars, using proprietary
2.4GHz techniques..
Security / Safety
More targets…
 Just have a look at the Nordic Semiconductor „Press
Releases“ Webpage
 How many of the vendors, using the NRF24xxx
based transceivers in their devices, might implement
crypto in a proper way? Message authentication?
 How many of the vendors might use the NRF24xxx
crypto hardware in a proper way?
Back to the keyboard topic
Logitech Hardware
Logitech Payload Patterns

 8 Byte encrypted data


 4 Byte Sequence ID incremented
 1 Byte checksum
 The following checksum algorithm can be applied to
the payload: cksum = 0xFF
for n in len(data):
cksum -= data[n]
cksum += 1
Logitech AES 128 Secret Key
Exchange
Receiver Keyboard

500us

X X X X
Time
Logitech AES Key Derivation
 128 bit AES cipher needs block sizes of 16 Byte
 Only 8 Bytes are seemingly random or encrypted
 We assume, that AES128 is used in a mode, to
generate random data for an arbitrary stream-
cipher initialization.
 Even when pressing the same key again and again,
the 8 Byte ciphertext block differs completely
More Logitech…
 Keyboard Multimedia Keys are not encrypted
 Mouse data is not encrypted
Keykeriki V2 - DEMO
1. Scanning channels for valid
Enhanced Shockburst frames
2. Setup sniffer & NRF module
3. Perform Remote Command
Execution:
 <WINMETA-R>

 cmd.exe<return>

 calc.exe<return>

 46/2=
Risk & Impact
 Malware infection
 Remote key- and command injection (Drive-by
shooting)
 About 75 meters with default antenna
 Interception / Identity theft
 Where lies the burden of proof.....?
Whats Next?
 Fall 2010 2.4 GHz software defined radio
 Can support different protocols
 Can support different channels

 Can support different encodings

 Free & commercial version


 New hardware, using more powerful programmable
logic devices
 Analysis software, Wireshark, …
Questions?

Write us:
[email protected]
[email protected]

Infos, Software & Hardware Release:


http://www.remote-exploit.org/

Greetings & thx to:


n1ck, greg, eric, phil

You might also like