Advisory

Multiple Security Issues in Ecos Secure Boot Stick (SBS)

• Software: Ecos Secure Boot Stick
• Version: Stick Version 5.6.5, System Management Version 5.2.68
• Vendor Status: Vendor informed
• Release Date: 13/06/2018

The latest version of this document may be downloaded from tu-ilmenau.de. A German version is available.

1. General Overview

The Ecos Secure Boot Stick shall provide a secure enclave in an untrustworthy environment, i.e. it is intended to be booted on a commodity PC and shall allow a secure access to confidential data. The vendor states: "The ECOS SECURE BOOT STICK (SBS) provides a highly secure access to Citrix, Microsoft Terminal Server, VMware, View/Horizon and web applications within a protected remote access environment."

Reference customers include German authorities, banks, insurances, and hospitals. The numbers on the website indicate that a multiple thousand SBSes are circulating.

During a security audit of the boot stick and its management we discovered multiple vulnerabilities. All of them lead to SBS failing to assure the claimed security properties, i.e. a compromised host or third party may access private data and key material.

Disclaimer: We can neither make claims on the completeness nor the following findings being the most significant ones. From a theoretic point of view, we have not performed any independent thread modeling and not derived any security requirements. Instead, we rely on the security measures and statements of the SBS vendor as well as common sense, e.g. private keys should not be accessible. Furthermore, we give ideas on potential mitigation measures, but we cannot make statements about their completeness.

The novel [SE] and [SX] versions of the product were in the meantime certified to protect VS-NfD (the German clearance level for Restricted) data by the German Federal Office for Information Security (BSI). We do not have access to these versions of the product and although the [SE] and [SX] versions may work similar (except for the fact of using smartcards), the advisory may not be applicable to it. The approval of the BSI may also be tied to certain precoditions for a secure operation, which are usually not made public and which may mitigate risks.

2. Description of Vulnerabilities & Potential Mitigations Measures

1. Remote root login in Ecos System Management

The System Management Appliance contains root user with a set password and enabled SSH access. The password file /etc/shadow that contains the password is downloaded during installation of the appliance from a server operated by Ecos. Ecos is able to provide individual passwords depending on the used license key. Our shadow file has the following content (please note the base64 encoded signature by Ecos):

root:$6$ys8MpGD8fzOj1CMa$8S5YZ2UasC5IVMOoshDevPYeGEfxe/t.WUYL1nOHzR6g38VQmUO6t5vLsNQvk1thPJhTygDsvUyd9tfbJz5ib.:10091:0:99999:7:::
setup:*:12101:0:99999:7:::
remotesetup:*:12101:0:99999:7:::
RUNPUyBUZWNobm9sb2d5IEdtYkg6IGNvbmYtc2lnbtlpePrdaFQhGVMzvKCum1Se8f8kAQBUo7BcQAy9GeRSx2+cRPHJPzSg792pvZ4Ib5RYVbb6GOJdO92mrdFN4JwQhcb5unnmJLa9GX3XpBC2Ujh8AmZsBW2Q06h0ka0qfxJMkcmRDZ3LxOU/GjG/vGnyiymlk1g8iUdYf6u7NNZ0HVoz1HC8dQdZgcH1J5cHnOFGgVl4oak207tnUpgziAwSkALddZHR0jJ7sNiNlboIMToqPmM2lxYJulRCzWcplFoiHkvhEZos0m1TI9NnEA+nlp38cSWBf5lOytN10eeVnaov+uGAp2Xl22avmZmOz6c0K4TttTKGdi1+i2/Tzgs3Jhwegn3b4fNrvp5iB8/umBsYR3i2AQYBHxQAAAAAAAECfk1vZHVsZSBzaWduYXR1cmUgYXBwZW5kZWR+Cg==

Steps to reproduce:

1. Install the Ecos System Management in a virtual machine and shut the VM down
2. Mount disk image in an external OS
3. Verify a file /usr/msrc/certs/shadow.new exists and contains the hash of a set password for user root
4. Change the password in /etc/shadow by modifying the hash
5. Boot appliance again
6. Log into the appliance using SSH and your password

Potential implications:

• The vendor has the possibility to use the root account as backdoor and log into the appliance at any time.
• The vendor may download private configuration, e.g. private keys and passwords.
• The vendor may modify existing configurations, e.g. switch to an insecure encryption scheme or activate VNC connections to associated SBSes.
• If the vendor should ever have a security problem itself, e.g. an disloyal employee or compromised software, other parties might use this backdoor.
• If the same password is used for all customers:
  • An attacker might brute-force the root account and use the backdoor in other installations.
  • If the password is ever used, an attacker might record it using a man-in-the-middle attack and make it available to third parties.

Potential mitigation measures:

1. Either mount the Ecos System Management partition using an external system and reset the password. It may be required to disable the update system to make changes permanent. OR
2. Disable root access in sshd_config. OR
3. Disable access to the Ecos System Management on port 22 using an external firewall. The SSH process listening at port 909 seems to have root access disabled.

Assigned CVE ID: CVE-2018-12338

Update June 15th 2018

The management appliance contains a documented remote acesss user remotesetup with very limited access rights (see ECOS SMA V5 Handbook section 3.4.5 for example). This access must not be confused with the root user, which is discussed in the section above and cannot be deactivated by a user or administrator. The handbook (revision 0111, december 2017) rules out such an acess very explictly:

In jedem Fall ist über die Konsole kein Shell- oder Root-Zugang möglich, sondern nur zu einem Menü, das grundlegende Wartungsaufgaben, wie z. B. Setzen der IP-Adresse oder Senden eines ping etc., erlaubt.

In all of our security tests the documented remote access accounts have been disabled. However, the root account has not been disabled and we were able to open a shell via SSH.

2. Easy enrollment susceptible to man-in-the-middle attacks

The easy enrollment feature allows remote users to initialize their new SBS by entering an "activation code" and a six digit "passphrase". This initial enrollment is technically performed by downloading the required configuration from a central management appliance, whose IP address is encoded in the activation code. To authenticate with the management appliance the SBS uses an SSH connection to port 909. It uses password authentication scheme with a username and password directly derived from activation code and passphrase. As the SSH fingerprint of the authentication server is not checked, activation code and passphrase may be obtained by a simple man-in-the-middle attack.

Video: enrollmentMITM.mp4

Potential implications:

• An attacker may perform any action happening in a legitimate easy enrollment. He may also abort an enrollment process at any time to keep the activation code legitimate. The attack may happen transparent to the end-user.
• The stick of a user may be impersonated.

Potential mitigation measures: Use easy enrollment only in trusted networks. Using easy enrollment with a smartcard may be secure, as it requires a smartcard initialization in an offline step, but we have not verified this.

Assigned CVE ID: CVE-2018-12331

Update June 15th 2018

According to the vendor SBS versions 5.4.43 and 5.6.11 address this issue, when used in combination with management 5.2.70 and 5.3.40.

3. Easy enrollment allows download of arbitrary user credentials

After easy enrollment established an SSH connection, the stick tunnels HTTP requests through it. The answers contain files for an initial bootstrapping, e.g. they include public and private keys to connect over SSH in a later step. After obtaining the files, the activation code is usually deleted from the database.

However, we found that by using an activation code/passphrase pair, an attacker may establish arbitrary port forwardings in the management appliance. Hence, an attacker may use the credential above to connect to ports that are solely bound to the localhost of the management appliance. The central CouchDB is listening on port 5984 and may be instructed to dump the credentials of arbitrary sticks and users. Furthermore, the activation code does not have to be deleted, so that the attack may stay unnoticed.

Video: enrollmentKeyExtraction.mp4

Potential implications:

• An attacker, who gained access to a valid activation code (the passphrase does not contain suffient entropy) or who performed a successful man-in-the-middle attack, may compromise the keys of all users.
• The attacker may also modify the management database, e.g. enabling VNC server with a weak password.
• Further internal services or even other hosts might be accessed (which we have not explored).

Potential mitigation measures: Make sure easy enrollment may only be used inside trusted networks, i.e. not over the Internet, by blocking port 909 (will have side effects). Only trusted users must obtain an activation code.

Assigned CVE ID: CVE-2018-12335

Update June 15th 2018

According to the vendor management versions 5.2.70 and 5.3.40 address this issue.

4. SBS leaks key material on reset

Ecos states: The usage of the stick does not leave traces. It is hence ruled out that conclusions on connection or working data may be drawn. ("Die Nutzung des Sticks hinterlässt keinerlei Spuren, womit es ausgeschlossen ist Rückschlüsse auf Verbindungsdaten oder Arbeitsdaten zu nehmen.")

Despite this statement, we (obviously) found that after cold reset of an Ecos SBS, i.e. user hits the reset button, confidential key material is left in main system memory. A compromised host OS may read this key material from "uninitialized" memory. This may also happen, if the user is resetting a PC using Ecos SBS, continuing his work with the SBS, properly shutting it down and booting into the untrusted OS (the memory is not completely overwritten by the OS).

Steps to reproduce:

1. Download and prepare RAM imaging utility from Github
2. Hit Reset while running Ecos Secure Boot Stick OS
3. Extract long-term and short term secrets using the RAM imaging utility. Depending on the used hardware an interpretation may require an additional descrambling (see [1] or [2] for details). The MSI Z170A GAMING M7 board is verified to work without descrambling.

Video: coldBoot.mp4

Potential implications:

• A compromised host OS (or with lower probability even applications) may obtain secrets that should have been securely kept in the SBS. Keying material that may be compromised includes:
  • Private keys to authenticate the stick to the management
  • Private keys to establish connections to VPN/websites
  • Symmetric keys that protect VPN connections and terminal server sessions
  • Symmetric keys that protect firmware and user configuration
• Attackers may enforce this situation to extract key material "contained" in a stick.
• A malicious user may extract or modify the user configuration on a stick by using extracted keys (see findings 8 & 10).

Potential mitigation measures: After a reset users must unplug power supply and potentially remove laptop batteries for several seconds to ensure the memory is wiped, before booting an untrusted OS. Older types of RAM may require a power off for an even longer period of time. Devices, that cannot be securely turned off, i.e. without removable batteries, should not be used. Long-term secrets should be better protected when a smartcard is used, however we have not verified this option.

Assigned CVE ID: CVE-2018-12332

5. SBS may be cloned

The vendor advertises the stick as a 2-factor-authenticator with a certificate being paired with "the" hardware ID of the stick (Ecos: "Zertifikat, gekoppelt an die Hardware-ID des Sticks"). This suggests that the stick may not be cloned by an attacker or compromised software.

We found that the SBS is not sufficiently protected against cloning, as the idea of a "hardware ID" is deceptive for current generations of USB storage sticks. An attacker may set parameters such as vendor and product ID as well as the serial number on generic USB storage sticks [3]. A malicious software must then only perform a byte-level reproduction of the stick, e.g. using the well know dd-tool on a Unix system. Note that this copying does not require physical access, but the content may be transferred to a remote site, if the stick is plugged into a PC that is running compromised OS.

Video: stickClone.mp4

Potential implications:

• Sticks may be remotely or locally duplicated without the user noticing this, violating the possession requirement of the 2-factor-authentication.
• As the "firmware" of the stick is not activated, this may be performed even if a boot passphrase is set.
• Attackers may create "backups" of certain stick configurations and restore state if a configuration is remotely revoked or the SBS is seized.

Potential mitigation measures: Users must not plug an SBS into a device running untrusted hard- or software. This may include compromised USB equipment, like hubs, etc. Using a different form of a second factor, i.e. smart cards should help, but has not been verified by us. Strong passphrases increase the strength of the "first factor", i.e. the actual physical possession of a stick is less relevant for the established level of security. Rely on certificate revocation in accessible remote services (VPN concentrator, RDP servers or internal websites) in the case of a compromise, not on possession of an SBS. In case of a central VPN concentrator, it may be useful to monitor sessions for parallel logins.

Assigned CVE ID: CVE-2018-12329

6. SBS may be booted in virtual environment

The vendor statement: Before execution of the firmware a check is performed, to determine if the stick was booted in a virtual machine. This prevents that security measures of the stick are undermined and, for example, a keylogger or Trojan on the host records screen content or keyboard strokes. ("Vor Ausführung der Firmware erfolgt eine Prüfung, ob der Stick in einer virtuellen Maschine gebootet wurde. Dies verhindert, dass die Schutzmaßnahmen des Sticks unterlaufen werden und beispielsweise ein Keylogger oder Trojaner auf dem Hostsystem Bildschirminhalte oder Tastaturanschläge protokolliert.")

Developing good detection and concealment strategies for virtual machines is an ongoing war between virus authors and anti-virus vendors, for example. From a theoretical point of view the detection of a VM environment is not possible under all circumstances. However, practically it may be difficult to build an undetectable virtualization environment (see [4]).

This raises the question how well protection mechanisms against virtualization attacks work in SBS. Error messages indicate it is part of the cryptographic protection mechanisms. Strings in the involved executable show astonishing similarities to the virtualization detection in systemd (see Github repository for the involved GPL code). However, systemd was never build to protect against malicious activities, so it is not surprising that starting KVM with the following command is sufficient to boot the stick in a VM:

kvm -m 2048 \
  -cpu host,kvm=off,-hypervisor \
  -usb -device usb-ehci,id=ehci \
  -device usb-host,bus=ehci.0,vendorid=0x8564,productid=0x1000 \
  -smbios 'type=0,vendor=' -smbios 'type=1,manufacturer=,product=' \
  -vga cirrus

In case an attacker should not have direct access to a stick, but only to an image (e.g. copied from a compromised OS), a simple patching of QEMU may make the same approach feasible. Blueprints are available in the Internet.

Video: virtualization.mp4

Potential implications:

There are two main scenarios how this finding may lead to a successful attack:

1. The legitimate user virtualizes himself by intend, e.g. for reasons of convenience or to capture video output. The latter should explicitly be impossible according to the SBS vendor. (Creating, saving, printing or forwarding screen captures is prevented by a secure access solution, "Das Erstellen, Abspeichern, Drucken oder Weiterleiten von Bildschirmkopien wird über eine sichere Zugangslösung verhindert.")

2. The user is not aware of the system being virtualized. Like demonstrated over 10 years ago, it is possible for malicious software to simply virtualize operating systems to hide their existence (see [5]). Even for the dedicatedly booted SBS numerous transparent virtualization attacks are imaginable, e.g.:

   • A compromised OS may change the UEFI NVRAM to modify the boot order, which is an official API function. It makes sure to be always booted first. If an Ecos sticks is plugged-in, it is booted in a virtual machine.
   • A compromised OS does not properly shutdown, after the user clicked "reboot". Instead it shows a short video of a BIOS output and starts the Ecos stick in a virtual machine.
   • A malicious software modifies the SBS, such that it always boots in a virtual machine (see finding 10 why this is possible).

A virtualized Ecos SBS system may be introspected and modified at any time. Hence, it is possible to

• Record user behavior, session and long-term keys, PINs as well as passphrases. Thus, giving both factors of the 2-factor-authenticaton in the hands of an attacker
• The virtualizer may modify running programs, the SBS OS and the involved data.
• Any extracted data may be communicated to remote locations, i.e. the attacker does not have to get physical access to the SBS.

All in all, no security goals may be accomplished if virtualization is not effectively prevented.

Potential mitigation measures: Users must not plug an SBS into a device running untrusted hard- or software. Administrators must be aware that users might use virtualization to run their sticks. If users cannot be fully trusted the SBS cannot ensure the claimed security objectives.

Assigned CVE ID: CVE-2018-12334

7. SBS is susceptible to backdoors in hardware firmware

Firmware backdoors may access and modify sensible data during operation of Ecos SBS. The vendor states: ECOS SECURE LINUX takes control of the connected periphery, so that even malicious software residing in BIOS or UEFI does not pose a thread ("Zusätzlich übernimmt das ECOS SECURE LINUX die Hoheit über die angeschlossene Peripherie, so dass selbst eine Schadsoftware im BIOS oder im UEFI keine Bedrohung darstellt.").

This statement is rather surprising, as it contradicts to:

• Past and current opinion of the research community (see [6] or [7])
• The view of a notable privacy project also relying on a secure boot medium in untrustworthy hardware (Tails: "It is also impossible for Tails to protect against attacks made through the BIOS or other firmware embedded in the computer.")
• Statements by Intel (e.g. "The SMM environment is initialized by the BIOS prior to booting the operating system and is entered at runtime when a System Management Interrupt (SMI) is asserted. The SMI itself is neither visible to, nor maskable by the operating system.")

To validate the vendor statement, we decided to modify an open-source UEFI backdoor from Github. We added a very simple memory replacement strategy, which allows to portably extract IPsec keys and transmit them over the Internet. The result are about 600 lines of C code, which we could install in our MSI Z170A GAMING M7 motherboard from an administrative account in the host OS (an unmodified Windows). To do so we simply downloaded a current UEFI from the MSI website, modified it using UEFI Tool, and "upgraded" using the official MSI tool chain. The approach is highly flexible and may be also deployed using targeted mails or a Rubber Ducky (see video).

As expected, the Ecos SBS cannot protect against the extraction of key material residing in the memory of an untrusted PC. We were able to extract IPsec keys from the "hardened" Linux kernel of the SBS and decrypt an encapsulated RDP session in real time.

Video: smmBackdoor.mp4

We can also show that it is possible to patch executables in an SBS on the fly. For demonstration purposes this has been the login process, but others are also possible.

Video: loginPatch.mp4

Potential implications:

• A firmware backdoor may modify any running OS, program, and user data on the fly and unnoticeable.
• It may extract data, such as long-term and session keys, passphrases and PINs from memory and read storage devices.
• It can bypass any host-local firewall rules to communicate gathered results to Internet hosts.

All in all, no security goals may be accomplished if the hardware or the involved firmware is compromised.

Potential mitigation measures: Users must not plug an SBS into a device running untrusted hard- or software.

Assigned CVE ID: CVE-2018-12330

8. Constructed trust-chain does not suit operational needs

Ecos advertises UEFI Secure Boot support of its stick to be a security feature. They furthermore state: In a "Chain-of Trust" bootloader, kernel and applications verify each other in a permanently repeating process ("In einer »Chain-of Trust« überprüfen sich Bootloader, Kernel und Applikationen gegenseitig durch einen sich permanent wiederholenden Prozess.").

Already the previous two findings indicate that it is not the BIOS/UEFI that needs to verify integrity and authenticity of the booted OS, but the booted OS must verify that it started in an authentic environment. UEFI Secure Boot does simply not realize this security property. While there has been considerable effort by Ecos to realize the signature verification "top-down" from the UEFI, an attacker might just remove signature verifications in each component or replace them with own components, e.g. a vanilla Linux kernel. UEFI Secure Boot only effectively prevents the boot of such a modified system if all of the following conditions are met:

• The UEFI and other hardware components are not compromised (see finding above).
• The vendor has sovereignty over all UEFI keys and make sure their bootloader is the only one booting. Currently Microsoft owns the keys and allows signature of third-party bootloaders. Also their own bootloader is known to be vulnerable (see heise).
• The USB stick (or some other trusted instance) prevents to be booted on a system that is not protected by UEFI Secure Boot under the conditions above.

The last condition implies that the stick must verify its surrounding somehow. The stick currently performs measurements of the booted kernel only (not the BIOS/UEFI nor the actually active bootloader). However, even this authentication happens only at two places; the process decrypting the OS image and configuration being the more sophisticated one. We concentrate at the robustness of this verification step in the following. An actual exploitation of the insufficient trust-chain will happen in finding 10.

To access the encrypted parts on the SBS, an initial user-land process (the init binary contained in the Linux' initrd image on partition 4) measures kernel, stick and active user environment and uses this information to derive keying material. The system stops with a decryption failed error, if modifications have been made. Modification of the load chain, i.e. by starting other processes first, change the measurement, and modifications later in the boot chain are impossible as the following parts are encrypted. An attacker might decompile and reverse engineer the involved binaries, however there is a more convenient and flexible way: Recently, there have been advances in sandboxing environments, so we used usercorn to run the key derivation process and trap its system calls. Using this technique we can tightly control what the process sees and things that should be hidden from it, e.g. it is possible to give the signature verification a different image than the one being mounted later on etc. If no boot passphrase is set, this attack will allow the extraction of all secrets stored on the SBS.

Note that some additional syscalls need to be mocked in usercorn to prevent premature termination. However, these do not need to provide any real functionality other than indicating successful execution to the caller and are therefore a straight forward addition.

Furthermore, note that usercorn is not the only way to perform such a modification of the control flow. We see at least five other ways:

1. Modify syscall arguments in a custom Linux kernel, e.g., mark the process and if it wants to read the contents of /proc/keys give it some other file to read.
2. Modify syscall arguments using ptrace and seccomp during runtime. (Example)
3. Start the binary in a debugger and place breakpoints at each int 80h (i.e. syscall) instruction. Modify the contents of the registers that contain arguments to the syscall.
4. A string analysis of the init binary strongly suggests that it contains code under GPL, which would mean that all of its code needs to comply with GPL. In this case the vendor would be required to provide the full source code to its users, who may modify and redistribute it. If an attacker obtains the published code, he can build his own init binary with arbitrary changes.
5. An attacker may reverse engineer and change parts of the init binary's machine code directly in order to modify its behavior, e.g., to skip signature verifications or redirect file system access.

Video: offlineKeyExtraction.mp4

Potential implications:

• If no boot passphrase is set, this finding will allow an attacker to extract of all user configurations, including but not limited to private keys.
• If a boot passphrase is set, the decryption will allow for an automatic offline brute-forcing of passphrases. If the passphrase is weak, the very same files may be extracted.
• In either case, encryption keys of stick-specific configuration files and firmware images may be derived without booting the SBS. This is a prerequisite for exploitation of the following two findings.

Potential mitigation measures:

• Enforce boot passphrases that are not susceptible to bruteforce attacks. AND
• Users must ensure that they really boot from the plugged-in stick (turn off computer and enter BIOS to verify boot order before starting SBS), as a compromised OS may simply mock the Ecos environment using application layer emulation and the decrypted firmware to obtain cryptographic material to bruteforce the passphrase. AND
• Use a stick with hardware support to make it read-only (see finding 10 for details) and use the stick only in read-write mode in fully trusted environments.

Assigned CVE ID: CVE-2018-12337

9. Remote root login in Ecos SBS

Using the method sketched above, it is not only possible to extract the so called "firmware" image and user-specific configurations, but also a global configuration for the stick (residing in basedata/certs on the forth partition). This is always possible, even if a passphrase is set, and not known to the attacker. This folder contains (among others) an encrypted and signed shadow file. In our case it has the following content:

root:$6$kD.Sv/YPnhZqNwXw$xHvghwrKESSS4inwjPRFt5UNgsLXRuuCtUUIP1.W7qK08NkBF.n/vT7iRpSH4hLB2aZ8iPtuNQ20mlVoEaNgk1:10091:0:99999:7:::
setup:*:12101:0:99999:7:::
remotesetup:*:12101:0:99999:7:::
RUNPUyBUZWNobm9sb2d5IEdtYkg6IGNvbmYtc2lnbtlpePrdaFQhGVMzvKCum1Se8f8kAQAytCKRbYYaeiWywek18P0AAJ43Yhy/VUvpMUBdRom8Wd/WISBXe23ZqumopgwNDglYvcSm28AK+tufQxcX8P4MspVLuI07CH9CGLmPqgzffP0gqpPFbSsEGtBiCX/9h5epu7ARnGfKst/2uWLLSvXidcKqht2A6f38QxNO7MGxrKZ5wDOkqTnJx3nxjKFfN5Rpmlyz7gLo8s+VscAPqf6if8QzH6rksRHRAKFzPGcCtVKExNA5dxURNFGU10NUtuZUE5ZbawLSfhbxNenLBf3bAMLdKNxIPVZsJhPUEvHJntyK73Dype5o3JXiLmiPo/GSXmp31NCl50cAyvNFyIYpAQYBHxQAAAAAAAECfk1vZHVsZSBzaWduYXR1cmUgYXBwZW5kZWR+Cg==

The base64-encoded signature points to Ecos, i.e., it is not generated by the management appliance. A shadow file is already present on sticks that come directly from the vendor, and that have not been enrolled. This indicates the possibility for another undocumented root login, not only to the management appliance, but also to sticks itself. We have verified this login to work remotely over SSH in another finding below.

Video: sbsRootAccess.mp4

Potential implications:

• The vendor has the possibility to use the root account as backdoor and log into SBS when it is active.
• The vendor may access files on the private hard drive of the PC (Vendor statement: No access to private photos and mails, "Schutz vor Zugriff auf private Fotos und E-Mails"). Nevertheless, the operating system kernel contains an NTFS driver, which may be used by a remotely logged-in root user.
• The vendor may download private configuration, e.g. private keys and passwords.
• The vendor may modify existing configurations, e.g. switch to an insecure encryption scheme.
• If the vendor should ever have a security problem itself, e.g. an disloyal employee or compromised software, other parties might use this backdoor.
• If the same password is used for all customers:
  • An attacker might brute-force the root account and use the backdoor in other installations.
  • If the password is ever used, a fake SSH service might record it and make it available to third parties.

Potential mitigation measures: Users must not use the SBS in scenarios where a remote SSH access is possible, e.g. the open Internet without an external firewall that supresses incoming SSH connections.

Assigned CVE ID: CVE-2018-12336

Update June 15th 2018

Please note the discussion of the documented remote access acount at [the end of section 2.1]((#update-june-15th-2018). It applies also for the SBS.

10. Content on SBS may be maliciously modified

Vendor statement: Write protected partition for firmware and applications ("Schreibgeschützte Partition für Firmware und Applikationen")

Thus, a more technically correct statement would be that unauthorized writes will be detected, e.g. by verifying signatures. However, also this more relaxed statement is not always kept, as we discuss with the help the following three scenarios.

Replacing the SBS completely

As the SBS is a "normal" USB mass storage device, a compromised OS may simply overwrite the whole stick with malicious content. For example, it could place a minimal OS on the stick, which instantly infects any host operating system, e.g. a Windows. Afterwards it could show an Ecos SBS logo and an error message, e.g. "Your PC is unsupported, please plug the SBS in a different one".

Using this approach an attacker could try to spread his malware from a users home PC to others inside the company network.

Hijacking the root login

As mentioned above, the so-called "firmware", i.e. the main OS of the SBS, is protected by a signature. However, the configuration is only protected by an authentication code. Hence, we can use the keys obtained for decryption (see finding 8) to also modify the content of the configuration; possibly without being noticed. Note, that there are two configurations: one being specific to one of the boot configurations and one being stick specific. Only the first one is protected by the boot passphrase. Therefore, an attacker may modify the stick-specific configuration without knowing the boot passphrase. Using the knowledge from the finding 8 we can modify the shadow file to set a custom password. There is an obstacle to avoid: use the old crypt method to create the shadow file and make sure there is an update.conf file, which seems to be present on some sticks only. It contains the following data:

reltype=V5.6.5
bbtype=mthc
fn1=ca.crt
fn2=base.pem
fn3=runtime.pem
fn4=shadow
fn5=my.pem

force-reltype=1

After this modification an attacker may access the stick via SSH regardless on which computer it is booted from (given a network connection). Over the SSH session he may obtain long- and short-term secrets, access the "private" hard drive of the user (remember the SBS even contains an NTFS driver for this) or modify the user's SBS configuration. Furthermore, the "hardened" OS contains a tool to create screenshots of the active session (xwd) and even a VNC server, so that it is possible to monitor the session in real time or even interact. The passive monitoring is not indicated to the SBS user, unless the attacker chooses to do so.

Video: stickMod1.mp4

Modifying executables in the SBS

Even without the exploitation of the weakly protected part of the configuration, it is possible to modify a stick in a way, such that signature checks are completely removed and a backdoor is implanted, which infects user OSes and spreads over SBS, for example. To do so, the initial static signature checks of the stick may be evaded by installing a custom bootloader (using the Ecos theme) and kernel, as well as an init-Stage with a slightly modified control flow. See finding 8 for different ways to influence the control flow.

Ecos states: If a modification is detected, the stick shuts itself down. A manipulation of the stick, no matter if running or in power-cycled state, is therefore effectively prevented. ("Wird eine Manipulation erkannt, schaltet sich der Stick sofort ab. Eine Manipulation des Sticks, egal ob im laufenden Betrieb oder im ausgeschalteten Zustand, wird so wirkungsvoll verhindert.") However, we found it rather difficult to trigger this security monitoring, which seems to be based on whitelists. It seems only few files are monitored, e.g. out of the 663 files in the /bin directory of the hardened operating system, we found only a handful being supervised. Hence, it is rather simple to evade this protection mechanism. In our case we simply replaced /bin/insmod in the root partition of the Ecos OS, as it is called on a regular basis and not protected by the above means.

Video: stickMod2.mp4

Discussion of malicious modification

Potential implications:

The implications of this finding heavily depend on the scenario of attack and attacker sophistication. Main threats are:

• The attacker might use the SBS to spread malware from host to host; possibly infecting other SBSes.
• While doing so he may exfiltrate private data stored on the PCs as well as credentials and configurations stored on the stick (despite a potentially strong boot passphrase).
• When modifying the init process, he may capture the boot passphrase (if he should need it somewhere else, as the configuration is available in decrypted form) or smart card PIN.
• If a smartcard is used, the attacker may make use of it as long as the SBS is active.
• The attacker may disable any SBS-internal firewall.
• The attacker may trigger communication from the compromised SBS, e.g. to contact a command and control server.
• Depending on the abilities of the attacker, all of these attacks may be concealed, i.e. the user will not be able to recognize it as the functional aspects of SBS still continue to work correctly.

Potential mitigation measures:

Users must not plug an SBS into a device running untrusted hard- or software. Do not use the stick in multiple PCs to prevent a spreading of malware via the SBS itself.

Assigned CVE ID: CVE-2018-12333

3. Conclusion

This document presented various weaknesses in the Ecos SBS and its management platform. We concentrated our analysis on the boot process and the Easy Enrollment feature. Nevertheless we found many of the security statements communicated by the website and brochures to be violated, among others:

• The usage of the stick does not leave traces. It is hence ruled out that conclusions on connection or working data may be drawn. ("Die Nutzung des Sticks hinterlässt keinerlei Spuren, womit es ausgeschlossen ist Rückschlüsse auf Verbindungsdaten oder Arbeitsdaten zu nehmen.", finding 4)
• Certificate paired with the hardware ID of the stick ("Zertifikat, gekoppelt an die Hardware-ID des Sticks", finding 5)
• Before execution of the firmware a check is performed, to determine if the stick was booted in a virtual machine. This prevents that security measures of the stick are undermined and, for example, a keylogger or Trojan on the host records screen content or keyboard strokes. ("Vor Ausführung der Firmware erfolgt eine Prüfung, ob der Stick in einer virtuellen Maschine gebootet wurde. Dies verhindert, dass die Schutzmaßnahmen des Sticks unterlaufen werden und beispielsweise ein Keylogger oder Trojaner auf dem Hostsystem Bildschirminhalte oder Tastaturanschläge protokolliert.", finding 6)
• Creating, saving, printing or forwarding screen captures is prevented by a secure access solution, ("Das Erstellen, Abspeichern, Drucken oder Weiterleiten von Bildschirmkopien wird über eine sichere Zugangslösung verhindert.", finding 6 and 9)
• ECOS SECURE LINUX takes control of the connected periphery, so that even malicious software residing in BIOS or UEFI does not pose a thread ("Zusätzlich übernimmt das ECOS SECURE LINUX die Hoheit über die angeschlossene Peripherie, so dass selbst eine Schadsoftware im BIOS oder im UEFI keine Bedrohung darstellt.", finding 7).
• In a "Chain-of Trust" bootloader, kernel and applications verify each other in a permanently repeating process ("In einer »Chain-of Trust« überprüfen sich Bootloader, Kernel und Applikationen gegenseitig durch einen sich permanent wiederholenden Prozess.", finding 8 and 10).
• No access to private photos and mails ("Schutz vor Zugriff auf private Fotos und E-Mails", finding 9 and 10)
• Write protected partition for firmware and applications ("Schreibgeschützte Partition für Firmware und Applikationen", finding 10)
• A manipulation of the stick, no matter if running or in power-cycled state, is therefore effectively prevented. ("Wird eine Manipulation erkannt, schaltet sich der Stick sofort ab. Eine Manipulation des Sticks, egal ob im laufenden Betrieb oder im ausgeschalteten Zustand, wird so wirkungsvoll verhindert.", finding 10)

Additionally, we found potential vendor backdoors, a man-in-the-middle vulnerability and the possibility to mirror the internal management database, containing all private keys of associated sticks.

While some of the findings may be results of sloppiness, e.g. having enabled root logins or being able to download all private keys, most of them are based on conceptual mistakes. Out of these, the [SE] and [SX] version of the stick might mitigate finding 5 if used with a smartcard. However, the root causes of findings 4, 6, 7 & 8 lay within limitations of the current x86 platform. We do not believe they can be fixed, without requiring additional hardware capabilities or trustworthy hardware all together.

In macroscopic scale our findings are also rather interesting, as they emphasize the low value of IT security tests, when introducing a new product in a company. Most of the reference companies and authorities cited by Ecos claimed that they have done internal or external tests to validate the security of the product. The testimonials imply that no severe security issues have been found at all. We invested about a month besides our main projects for the above findings. Most likely a pentester, with less resources, can simply not surpass the multiple layers of cryptographic obfuscation. Even our less constrained time schedule did not allow a full coverage of the attack vectors the SBS approach offers. It is particularly alarming that some of the vendor claims contradict to common opinions of security experts -- apparently with causing significant suspicion. Most prominently:

• The detection of virtualized environment cannot be guaranteed.
• Current firmwares (EFI but also Intel ME and others) must not be considered secure.
• USB devices must not be trusted (see [8] for further ways of exploitation).

Furthermore, already the basic BSI IT-Grundschutz contains in section M4.63 the requirement "The telecommuting computer should provide a boot protection mechanism to prevent booting from removable data media, e.g. from DVDs or USB sticks, without authorisation." However, there are no hardware mechanisms to ensure that only authentic sticks can be boot, yet Ecos claims conformance to M4.63.

4. Credits

Findings discovered and exploited by Robert Lasch, Franz Girlich and Michael Rossberg (in no particular order). Guenter Schaefer served as scientific advisor¹.

Please contact Michael Rossberg via michael [dot] rossberg [at] tu [dash] ilmenau [dot] de for questions or comments. GPG fingerprint: FD9B 425C 8DE5 69D6 77ED 52C2 CC00 C314 0337 76C9

5. Disclosure Timeline

• 13/04/2018 - Vendor informed
• 30/04/2018 - BSI allows usage of [SX] and [SE] variants of the stick for VS-NfD data (i.e. Germany national level: Confidential)
• 13/06/2018 - Disclosure
• 14/06/2018 - Added CVE IDs
• 14/06/2018 - Vendor published statement at https://www.ecos.de/stellungnahme-illmenau/
• 15/06/2018 - Added notes regaring statement of vendor (1, 2, 3, 4); More detailed notes are available at https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/notes-180615.html.

6. References

Imprint