In early 2023 an awesome colleague (Andreas) spoke about an incident response case featuring thugs plugging a media keyboard into an ATM, and breaking out of its ATM kiosk software to install malware causing it to dispense $$$. This prompted me to spend some time during spring and summer of 2023 looking into Consumer Control, a subset of USB functionality, which is what allows media keyboards to launch and control various applications over USB with the press of single buttons; so called Consumer Control Buttons (CCBs). This writeup describes my research on the matter, and what I have nicknamed the USB HID & Run attack (credit to Roman for helping out with the name).
[…]
An attacker with access to the USB port of the kiosk, could potentially leverage this access to break out of the kiosk using keyboard shortcuts or CCBs.
[…]
Attacks on kiosks often focus on breaking out of the kiosk model to perform other actions on the underlying systems. Typical means of achieving this, either in the case of a kiosk equipped with a keyboard or with an on-screen keyboard, is to leverage either operating system-specific or application-specific keyboard shortcuts to trigger an event exposing unintended functionality. Examples of this include:
- Leveraging built-in Windows shortcuts (e.g.
Win+Eto launch the File Explorer). - Leveraging application-specific shortcuts (e.g.
ctrl+pwhich in many applications opens a print dialog from which the underlying file system can be reached). - Going completely bananas and doing “weird shit” with the hope of triggering an error that can be leveraged to access further functionality.
Often times, access to the underlying file system is enough to execute arbitrary code on the system. While details of this is beyond the scope of this project, Windows-based readers are encouraged to pause momentarily and do the following:
- Press
Win+E - Press
ctrl+l - Type
cmd - Press
enter
Now imagine this was a kiosk instead, and you hopefully get the concept. Congratulations, you are now a computer hacker with the ability to execute arbitrary code on the system.
For kiosks that are not equipped with either a physical or on-screen keyboard, this becomes much more difficult. However, with physical access to a USB port, you can plug in your own keyboard and do the same thing.
A plethora of resources exist on the matter of breaking out of kiosks, documenting many of the methods I have used myself on real assessments. [1] is a generic but comprehensive resource, and [2] is a more in-depth article written by a kiosk lockdown software manufacturer that even goes into great detail on physical USB attacks. However, the topic of CCBs is not covered.
[…]
Media Keyboards and USB
What sets media keyboards apart from traditional keyboards is the presence of keys that automagically launch a new application, or control elements of a currently running application.
[…]
Manufacturers can choose to include these keys to for example launch a local file explorer, a web browser or a calculator application; all through USB.
[…]
The functionality that USB HID vendors can include in their devices is defined in the USB HID Usage Tables for USB document [7].
[…]
The Consumer Page of the USB HID usage tables [7, Ch. 15] defines multiple usage names. The following two look especially interesting:
Application Launch Buttons, used to launch applications (configured by the operating system vendor, e.g. Microsoft)Generic GUI Application Controls, used to replicate control actions found in typical GUI applications such as pressing buttons and scrolling
[…]
In order to address the first objective set out by this project, I had to be able to send USB CCBs. As it would turn out, implementation of a "media keyboard" capable of sending arbitrary CCBs was trivial using a Teensyduino [10].
[…]
The following is a simple proof of concept, showcasing some interesting CCBs enabled by default in Windows 10 and 11.
/*
Simple CCB cycling example wherein the Teensyduino becomes a USB media keyboard and cycles through CCBs that have an action in Windows 10/11.
Values for keypresses are taken from the USB HID Class specification.
Before compiling, select "Keyboard" from the "Tools > USB Type" menu.
*/
void setup() {
}
void loop() {
Keyboard.press(( 0x183 | 0xE400 )); // Default media player
Keyboard.release(( 0x183 | 0xE400 ));
delay(500);
Keyboard.press(( 0x18A | 0xE400 )); // Default email client
Keyboard.release(( 0x18A | 0xE400 ));
delay(500);
Keyboard.press(( 0x192 | 0xE400 )); // Pop calc!
Keyboard.release(( 0x192 | 0xE400 ));
delay(500);
Keyboard.press(( 0x194 | 0xE400 )); // File Explorer (This PC)
Keyboard.release(( 0x194 | 0xE400 ));
delay(500);
Keyboard.press(( 0x223 | 0xE400 )); // Microsoft Edge
Keyboard.release(( 0x223 | 0xE400 ));
delay(500);
}
Compiling and uploading the above code to the Teensyduino board and subsequently plugging it into the USB port of a computer running a fresh Windows 10 launched the applications indicated by the comments in the code. That’s right, we just popped calc using CCBs. Note that these specific keys are the same as those defined in [9].
A small side note here is that I tried this using both a Teensyduino 2.0 and 3.2, they both work. However, I could only the latter of them to spoof Vendor ID and Product ID.
Distinguishing CCBs From Windows Keyboard Shortcuts
Equipped with the ability to send arbitrary CCBs using a Teensyduino, I set out to find out if CCBs are inherently different from builtin keyboard shortcuts in Windows, aiming to fulfill the second objective. To verify this, I disabled Windows keyboard shortcuts with the following command:
reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoWinKeys /t REG_DWORD /d 1 /f
After rebooting the machine for the registry change to take effect, I plugged in the Teensyduino. Lo and behold, Keyboard.press(( 0x194 | 0xE400 )); caused This PC to pop up, whereas Win+E did nothing (except put a smile on my face).
[…]
The following is a list of systems/devices I have experimented on with CCBs, with limited success:
- Windows 10/11 single-app kiosk [11]: CCBs seem to have no effect in a kiosk with Microsoft Edge
- Windows 10/11 digital signage mode [12]: The key
AC Home (0x223)opens up an InPrivate window - Various Samsung TVs: Possible to open and navigate the menu using CCBs
Additionally, I recently had the opportunity to experiment with an Android-based meeting room controller. With a regular keyboard, I was unable to perform any unintended action. However, when using CCBs (specifically the keys AL Contacts/Address Book (0x18D), AL Calendar/Schedule (0x18E), and AL Internet Browser (0x196)), I observed that they triggered the launch of the Android Contacts application, the Android Calendar application, and the default Internet browser of the tablet.
[…]
Source: USB Hid And Run | Github
Also: USB Consumer Control – POC for Flipper | Github
