Multiple Vulnerabilities in Barco ClickShare

The ClickShare family of products is designed to provide end users with wireless presenting capabilities, eliminating the need for wired connections such as HDMI.

The solution is composed of the following items:

• The ClickShare Button device to be connected to the end user's computer
• The ClickShare Base Unit device to be connected to a display or a projector
• The ClickShare client software to be executed by the end user
• A driver package for Windows 10 allowing a seamless presenting experience

According to the manufacturer, these systems are widely deployed across the globe and can be found in meeting rooms of a wide variety of businesses.

Multiple vulnerabilities have been identified that ultimately allow attackers to compromise hardware units and backdoor them, execute arbitrary code on end users' systems, as well as observe and manipulate contents being presented.

As the amount of findings affecting these products is significant, the technical details below were sorted according to the specific devices and/or software components. For clarity reasons and easy referencing, each finding is provided with a unique identifier.

The table below summarises the findings.

• Finding identifier: BCSD-FSC-RND-F001
• CVE reference: CVE-2017-7932

The System-on-Chip (SoC) used in the device is MCIMX283DVM4B (i.MX28), mask revision M06Z, which has silicon revision 1.2.

This revision is known to be affected by a previously disclosed vulnerability pertaining to the High Assurance Boot (HAB) functionality (providing Secure Boot). NXP, the manufacturer of the affected SoC devices, has issued an erratum ERR010873 confirming the issue. This is also tracked as CVE-2017-7932.

In order to reach the HAB vulnerability the attacker must either have access to the Data Encryption Key (DEK) to be able to encrypt forged content, or the device is configured to accept unencrypted firmware images.

It was also investigated whether the image authentication code, which is part of the boot image according to the existing documentation, is effective in ensuring authenticity of the image. It was found that due to exploitation requirements outlined above, this measure would not provide any additional protection: an attacker with DEK access can forge the authentication code as it is encrypted with DEK. It is possible for an attacker to extract the DEK using vulnerability BCSD-FSC-RND-F002.

An attacker can bypass the High Assurance Boot security feature and subsequently compromise the device.

• Finding identifier: BCSD-FSC-RND-F002
• CVE reference: CVE-2019-18827

The i.MX28 uses the industry standard JTAG interface to perform debugging, providing insight into the ARM CPU core for developers. However, such access can be abused by attackers to manipulate the state of an otherwise secured device.

The official documentation provided by NXP, the SoC manufacturer, does not specify any way of disabling the JTAG access permanently for production devices. The only mention of JTAG access protection comes in the form of the JTAG_SHIELD bit in the HW_DIGCTL_CTRL register, which has to be set by user software; on system reset, JTAG access is enabled. The following reproduces the official documentation regarding this bit:

This means that JTAG access is possible when the system is running code from ROM before handing control over to user software. This has been confirmed experimentally, although winning the race requires building a customised debugger capable of fast operation; this should be within reach of a moderately skilled attacker. Another way of exploiting this is booting the SoC in the "wait for JTAG" boot mode, where ROM code enters an infinite loop that can only be exited via manipulating certain registers via JTAG.

As such, this issue leaves the devices open to manipulations without any control from the device designer's side.

An attacker with access to the JTAG interface can win a race condition and gain JTAG access at the very early, and the most privileged, stage of system start-up. The attacker can then proceed to e.g. extract data encryption keys.

This has been exploited to gain initial access to the target system, and subsequently to disclose DEK values.

• Finding identifier: BCSD-FSC-RND-F003
• CVE reference: CVE-2019-18832

The SoC used in the device provides a way to provision a one-time programmable (OTP) AES encryption key to be used for multiple purposes, one of which is the decryption of software images during boot. When used in that role, this key is named the Key Encryption Key (KEK).

By inspecting the update process for the dongle device, it was discovered that a pre-encrypted software image, in the form of a SB file, is passed to the device during update. This image is subsequently written to the Flash storage and booted at the next power-up.

After updating the device to a fixed version, the contents of the boot partition were extracted and compared against the known SB file in which the contents were found to be identical. This proves there is not a re-encryption step involved during the update. This leads to the conclusion that, in order for a single image to be bootable on multiple devices, the devices have to be able to decrypt the embedded Data Encryption Key (DEK) correctly and therefore must share the same KEK.

Furthermore, it should be noted that the KEK remains accessible at any time when the device is powered on, for example, after the system boots. In addition, there are no limitations to key usage: the KEK cannot be limited to decryption only. 

An attacker with access to the OTP key from one device is able to forge arbitrary software images which will be accepted as bootable on all units of the specified model. To obtain a fully working exploit, an attacker would need to combine this issue with another one allowing to bypass HAB restrictions.

• Finding identifier: BCSD-FSC-RND-F004
• CVE reference: CVE-2019-18830

The dongle bridge program controlling USB functionality is responsible for the implementation of multiple commands used by the USB host to control the dongle's behaviour. The same set of commands is available to both the client software, provided through the USB mass storage interface on the device itself, as well as to the base unit for provisioning the device.

It was discovered that the program contains multiple OS command injections due to unsafe use of the system() C runtime library function, where user provided input is used to build a command line without any prior validation or sanitisation.

The following screenshot provides a decompiled example of the affected implementation, where data supplied through the buffer argument is user controlled:

The following methods were found to be affected:

• DongleCtrl::mpSetConfigParam()
• DongleCtrl::mpSetConfigList()
• DongleCtrl::mpSetDongleInfo()
• DongleCtrl::mpProcessConfigurationMessage()

An attacker able to send commands to the ClickShare Button is able to inject and execute arbitrary OS commands with the privileges of the dongle bridge process, in this case running as the 'nobody' user.

This issue was used during the research effort to gain initial foothold on the device through the USB connection. For example, it was used to start the interactive console available through the serial port that granted root level access by exploiting issues detailed elsewhere in the advisory as well as execute scripts allowing to manipulate data on the UBIFS partition.

• Finding identifier: BCSD-FSC-RND-F005
• CVE reference: CVE-2019-18831

It was discovered that a "testing" certificate, together with the corresponding private key, is stored in the device's file system; these were found under /usr/barco/data/testcerts/. Furthermore, it was also discovered that these credentials are signed by the production root certificate authority, allowing their use in all circumstances where normal certificates would be used.

Contents of the production CA certificate (the first line presents the MD5 hash and the file name or path):

Contents of the test certificate:

The corresponding private key:

An attacker able to gain access to a software image running on the device may obtain credentials used to authenticate to arbitrary devices. Furthermore, these credentials allow to carry out a Man-in-the-Middle attack against legitimate connections between dongle devices and base units.

The extracted certificate allowed authentication against the dongle and subsequent issuance of sensitive commands manipulating the dongle configuration. Furthermore, the same certificate was also used to conduct Man-in-the-Middle attacks against connections between client software and the base unit.

• Finding identifier: BCSD-FSC-RND-F006
• CVE reference: CVE-2019-18826

The dongle bridge program implements certificate-based mutual peer authentication using factory provisioned certificates in order to protect privileged functionality such as changing device configuration, updating software components, and so on. Specifically, leaf certificates are signed by a root certificate authority and are used to sign authentication requests.

The verification process is implemented in the Verifier::verifyCA() method, reconstruction of which is presented below in parts as needed to demonstrate the discovered issues.

The first issue pertains to certificate store initialization. The certificate store is used to provide a set of trusted certificates against which the tested certificate is verified. It was found that the implementation adds both the trusted CA and the user-provided peer certificate to the trusted store.

Due to this, a self-signed root certificate provided by the attacker will be able to pass verification unconditionally.

The second issue pertains to the way the verification context is created. The verification context is used to actually verify a given certificate against certificates in the trusted store. Picking up where the previous fragment left, the implementation proceeds with creation of the verification context and initializes it with the certificate to be verified, which in this case is the CA certificate, effectively making the verification always pass. See documentation concerning the X509_STORE_CTX_init() function.

This issue was tested by generating a self-signed certificate and using it to authenticate against the device; the authentication was successful.

In absence of properly signed certificates which could be obtained via other methods detailed elsewhere in the advisory, an attacker can use self-signed certificates to authenticate against the device, gaining access to otherwise restricted commands.

• Finding identifier: BCSD-FSC-RND-F008
• CVE reference: CVE-2019-18824

The device keeps various mutable content on a separate UBIFS partition mounted under /store during normal operation of the device. The content stored on this partition includes the USB mass storage file system image presented to the client connected via USB.

It was found that the content of this partition is not validated before being used; specifically, the mass storage file system image can be manipulated arbitrarily without being detected by the system; the only step required is updating the checksum file containing the image's MD5 hash. This could be exploited to backdoor the devices and serve specially crafted files to any victim plugging in the device through USB.

The attack itself can be carried out by e.g. physically taking the button apart and modifying data stored on the Flash IC, or alternatively using the "send file" functionality to deliver the image to a temporary location or exploiting OS command injection or any other means to move it to the final location on the UBIFS file system.

An attacker may manipulate the file system, placing crafted data which will be presented to any user plugging in the device via USB. This can be exploited to e.g. plant malware on the device.

To prove the concept, a USB mass storage image with crafted contents was written to the file system. The device proceeded to expose this image to the USB host, resulting in crafted contents presented to the client. This allowed exploitation of user's trust towards these devices.

• Finding identifier: BCSD-FSC-RND-F010
• CVE reference: CVE-2019-18828

Security of the operating system depends on multiple key variables, one of which is credential strength for accounts that have administrative access to the system, for example, the root account on Linux deployments.

It was found that the root account is using a weak, guessable password 'letmein' which was found by cracking the password hash extracted from /etc/shadow, a copy of which is provided below for reference:

This allowed login via the serial console (once enabled) and perform in vivo reconnaissance on the device. Some physical connections are required to gain access to the serial console.

Furthermore, there is no way for deployment administrators to change or otherwise disable the root account as the /etc/shadow file is included as part of the immutable system image.

An attacker with physical access is able to gain access to the system and obtain administrative rights, taking full control over the execution environment.

This was used to log into the device's interactive shell (once enabled) and conduct further reconnaissance actions and attacks.

• Finding identifier: BCSD-FSC-RND-F011
• CVE reference: None

Syslog is a standard for message logging. It allows separation of the software that generates messages, the system that stores them, and the software that reports and analyses them. This standard is in wide use in Linux-based systems.

Once connected to the base unit's Wi-Fi network, the device starts transmitting its syslog data towards the IP address of the base unit in cleartext.

Below is example data captured to demonstrate the way data is transmitted:

An attacker able to intercept traffic, whether by spoofing the base unit's Wi-Fi network or conducting ARP spoofing attacks, can gain valuable insight into the system's internal workings not available via other communication channels e.g. the debug port. This is most useful when attempting an initial compromise of the device.

• Finding identifier: BCSD-FSC-RND-F012
• CVE reference: CVE-2019-18829

Beginning from v1.8.0.6, according to the changelog, Windows automatically installs a driver and service for the ClickShare dongle. The purpose of this is to improve the user experience by automatically launching the Clickshare_For_Windows.exe binary present on the dongle.

The functionality verifies that the binary is signed by Barco, so any modification of the main executable will prevent automatic execution. This binary will however load a number of DLL files based on the standard DLL search order, allowing for a zero-interaction compromise.

It was also confirmed this functionality being invoked when the lock screen is active, thus eliminating the typical requirement for the machine to be unlocked.

An attacker able to modify the file system image presented by the dongle to the host system is able to plant arbitrary code which will be side-loaded into the client process on start, while preserving the signature of the client binary.

This was exploited to demonstrate how an attacker is able to compromise a user's system when the user plugs in a compromised device (e.g. in a meeting room) or without any interaction from the user (in cases of a lost or stolen laptop). Note that the victim does not have to own any Barco products in order to be compromised.

• Finding identifier: BCSD-FSC-RND-F013
• CVE reference: CVE-2019-18833

The client makes use of two communication channels, one for control and one for media back haul. Both channels are encrypted: the control channel uses TLS, while the media channel uses symmetric encryption based on the Salsa20 cipher.

It was found that the encryption key used to protect data passed through the media channel can be easily disclosed by conducting a Man-in-the-Middle attack against the Button's TCP connections towards the base unit. This was made possible using "test credentials" discussed elsewhere in this document – the X.509 certificate and the corresponding private key were used to configure a TLS proxy service; the same attack can be conducted by obtaining a base unit certificate from any unit via other means as well.

The Salsa20 encryption key itself was found to be passed unprotected through the TLS channel within parameters of the compositor.receiverNotification method invoked by the base unit. For demonstration purposes, one such message is shown below:

The absence of a key agreement protocol makes interception of this key sufficiently easy for a full Man-in-the-Middle attack with media data decryption to be practical.

An attacker positioned to carry out Man-in-the-Middle attacks against clients is able to disclose symmetric encryption key and gain access to otherwise protected media.

This was exploited to prove the concept of media stream interception by a Man-in-the-Middle attacker, resulting in the ability to record and decrypt H.264 streams being presented. The attack was made significantly easier and more practical due to the fact that the Wi-Fi network provided by the base unit does not implement client isolation.

• Finding identifier: BCSBU-FSC-RND-F001
• CVE reference: CVE-2017-7936 and CVE-2017-7932

The SoC used in the device is marked as SC667520EVM10CC maskset ID 3N81E, which was identified to be a customised version of the i.MX6 DualLite SoC manufactured by NXP.

This maskset revision, corresponding to silicon revision 1.3, is known to be affected by two previously disclosed vulnerabilities pertaining to the High Assurance Boot functionality. NXP, the manufacturer of the affected SoC devices, has issued errata ERR010872 and ERR010873 confirming the issues. These are also tracked as CVE-2017-7936 and CVE-2017-7932.

To verify the SoC is affected, the ROM code was extracted from the device and compared byte-wise against known vulnerable version; no differences were found confirming this is indeed a vulnerable revision.

An attacker can bypass the High Assurance Boot security feature and subsequently compromise the device by executing arbitrary, untrusted code. This issue can also be exploited in a persistent manner by writing a crafted image to the eMMC storage.

This has been exploited to force the SoC to execute a modified U-Boot program and subsequently allow full access to the device through the serial console. Serial Download Protocol (SDP) was used to deliver the crafted image.

• Finding identifier: BCSBU-FSC-RND-F003
• CVE reference: CVE-2019-18825

In order to protect confidentiality and integrity of the device's embedded software, the device uses hardware-accelerated partition encryption via the device-mapper driver. Four keys are provisioned, used as disk encryption keys for the root file system, the store file system, firmware update blobs (in fact, an encrypted ext4 partition image), and the data file system.

Inspection of the software update process showed that the root file system is provided "as is" within the update blob and is simply copied over to the non-volatile storage using dd. This implies that the root file system key is shared between devices within the same family, otherwise copying data verbatim would not allow subsequent decryption of root file system contents.

By attempting to replicate the software update process with the software blob produced for CSE-200 against a CS-100 unit, it was found that the blob can be decrypted successfully thus verifying that the update key is shared between device families. Furthermore, by successfully mounting the encrypted root file system blob it was confirmed that the root file system keys are also shared between device families.

It is expected that the other keys, while not as critical, are shared as well.

The following snippet from the secure-system-update script provides further evidence of key provisioning from the same initial image:

This issue may affect other device families apart from CS-100 and CSE-200; this has not been verified during this research effort.

An attacker who successfully compromised one unit gains the ability to decrypt as well as produce valid encrypted images for any unit, whether within one family or across families. This can be exploited to e.g. directly overwrite non-volatile memory contents such as the fallback partition with crafted images.

Further, such an attacker may gain access to sensitive data at rest such as the configured Wi-Fi PSK and certificates.

• Finding identifier: BCSBU-FSC-RND-F004
• CVE reference: None

The root file system is located within an encrypted ext4 partition, which is mounted by the init script executed from the initial RAM disk. The file system is mounted as read-only.

However, it is possible to remount this file system as read-write:

Subsequently, one can make arbitrary changes to this file system which will persist across device boots.

This means that there is no sufficient guarantee of file system integrity and any compromise can be easily persisted by a human attacker or malware.

File system encryption does not provide integrity guarantees except against an external attacker and only a weak one (introduction of uncontrolled changes) depending on the exact encryption algorithm in use.

An attacker is able to manipulate file systems contents contrary to immutability expectations and break the chain of trust.

During research, this was used to persist changes to /etc/shadow and certain other files in order to allow easy logins to the test unit via SSH (once enabled).

The vulnerabilities have been confirmed affecting CS-100 software versions 1.6.1.2 and 1.8.1.2 and the bundled USB button firmware version. Other versions are also believed to be affected.

As of publication, Barco have released a new version reportedly mitigating findings F002, F004, F005, F006, and F010 affecting button units. Fixes for other reported issues are not currently available.