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 https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/advisory.html. A German version may be found below. 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 Confidential) data by the German Federal Office for Information Security (BSI). 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:_ a. Install the Ecos System Management in a virtual machine and shut the VM down b. Mount disk image in an external OS c. Verify a file /usr/msrc/certs/shadow.new exists and contains the hash of a set password for user root d. Change the password in /etc/shadow by modifying the hash e. Boot appliance again f. 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:_ a. 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 b. Disable root access in sshd_config. OR c. 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. 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:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/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. 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:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/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. 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 hinterlA$?sst keinerlei Spuren, womit es ausgeschlossen ist RA1/4ckschlA1/4sse 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:_ a. Download and prepare RAM imaging utility from https://github.com/dbrant/bios_memimage b. Hit Reset while running Ecos Secure Boot Stick OS c. 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:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/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. 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:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/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. 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 AusfA1/4hrung der Firmware erfolgt eine PrA1/4fung, ob der Stick in einer virtuellen Maschine gebootet wurde. Dies verhindert, dass die SchutzmaAnahmen des Sticks unterlaufen werden und beispielsweise ein Keylogger oder Trojaner auf dem Hostsystem Bildschirminhalte oder TastaturanschlA$?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 https://github.com/systemd/systemd/blob/master/src/basic/virt.c) 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=' 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 https://lists.gnu.org/archive/html/qemu-discuss/2015-07/msg00072.html. _Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/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 A1/4ber eine sichere ZugangslAPsung 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. 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 ("ZusA$?tzlich A1/4bernimmt das ECOS SECURE LINUX die Hoheit A1/4ber 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: https://tails.boum.org/doc/about/warning/index.en.html) - Statements by Intel (e.g. https://firmware.intel.com/sites/default/files/STM_User_Guide-001.pdf) To validate the vendor statement, we decided to modify an open-source UEFI backdoor from https://github.com/Cr4sh/SmmBackdoor. 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 https://github.com/LongSoft/UEFITool, and "upgraded" using the official MSI tool chain. The approach is highly flexible and may be also deployed using targeted mails or a https://hakshop.com/products/usb-rubber-ducky-deluxe) (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:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/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:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/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. 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 A>>Chain-of TrustA<< A1/4berprA1/4fen 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 https://www.heise.de/security/meldung/Kardinalfehler-Microsoft-setzt-aus-Versehen-Secure-Boot-schachmatt-3291946.html). - 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 https://usercorn.party 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. (https://github.com/alfonsosanchezbeato/ptrace-redirect) 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:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/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. 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:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/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. 10. Content on SBS may be maliciously modified Vendor statement: Write protected partition for firmware and applications ("SchreibgeschA1/4tzte Partition fA1/4r 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:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/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:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/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. 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 hinterlA$?sst keinerlei Spuren, womit es ausgeschlossen ist RA1/4ckschlA1/4sse 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 AusfA1/4hrung der Firmware erfolgt eine PrA1/4fung, ob der Stick in einer virtuellen Maschine gebootet wurde. Dies verhindert, dass die SchutzmaAnahmen des Sticks unterlaufen werden und beispielsweise ein Keylogger oder Trojaner auf dem Hostsystem Bildschirminhalte oder TastaturanschlA$?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 A1/4ber eine sichere ZugangslAPsung 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 ("ZusA$?tzlich A1/4bernimmt das ECOS SECURE LINUX die Hoheit A1/4ber 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 A>>Chain-of TrustA<< A1/4berprA1/4fen 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 ("SchreibgeschA1/4tzte Partition fA1/4r 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[1]. 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 6. References [1] J. Bauer, M. Gruhn, and F. C. Freiling, aLest we forget: Cold-boot attacks on scrambled DDR3 memory,a _Digital Investigation_, vol. 16, pp. S65aS74, 2016. [2] S. F. Yitbarek, M. T. Aga, R. Das, and T. Austin, aCold boot attacks are still hot: Security analysis of memory scramblers in modern processors,a in _High performance computer architecture (HPCA), 2017 IEEE international symposium on_, 2017, pp. 313a324. [3] G. Ravago, aReverse engineering a USB flash drive.a 2015. [4] A. Sergeev, V. Minchenkov, and V. Bashun, aMalicious hypervisor and hidden virtualization of operation systems,a in _Application of information and communication technologies (AICT), 2015 9th international conference on_, 2015, pp. 178a182. [5] J. Rutkowska, aIntroducing blue pill,a _The official blog of the invisiblethings.org_, vol. 22, p. 23, 2006. [6] S. Embleton and S. Sparks, aSMM rootkits,a in _Proceedings of the 4th International Conference on Security and Privacy in Communication Networks, Securecomm_, 2008, vol. 8. [7] J. Rutkowska, aIntel x86 considered harmful,a _the Invisible Things Lab_, 2015. [8] K. Nohl and J. Lell, aBadUSB a on accessories that turn evil,a _Black Hat USA_, 2014. [1] Disclaimer for reasons of transparency: Guenter Schaefer is primarily serving as full professor at Technische UniversitA$?t Ilmenau. Furthermore, he is also member of the supervisory board of secunet Security Networks AG. ========= GERMAN VERSION ============== SICHERHEITSHINWEIS MEHRERE SICHERHEITSLACKEN IN ECOS SECURE BOOT STICK (SBS) - Software: Ecos Secure Boot Stick - Version: Stick Version 5.6.5, System Management Version 5.2.68 - Status: Hersteller informiert - VerAPffentlicht am: 13.06.2018 Die aktuellste Version des Dokuments ist unter https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/advisory-de.html erhA$?ltlich. 1. Aberblick Der Ecos Secure Boot Stick soll auch aus unsicheren Umgebungen heraus einen sicheren Zugriff auf Terminalserver und Webservices bieten. Dazu wird in einem herkAPmmlichen PC, A1/4ber den keine speziellen Annahmen getroffen werden, vom USB-Stick ein Betriebssystem gebootet. Der Hersteller schreibt: "Der ECOS SECURE BOOT STICK ermAPglicht einen hochsicheren Zugang zu einer Terminalserver- oder Virtual-Desktop-Infrastruktur und Webanwendungen aus einer gesicherten Umgebung heraus." Referenzkunden sind deutsche BehAPrden, Banken, Versicherungen und KrankenhA$?user. Die Zahlen auf der Webseite lassen darauf schlieAen, dass einige Tausend SBS im Umlauf sind. Dieses Dokument beschreibt eine Reihe von Schwachstellen, die bei einer Sicherheitsuntersuchung des Boot Sticks und der dazugehAPrigen Management Appliance entdeckt wurden. Alle gefundenen Schwachstellen fA1/4hren zu einem Versagen von herstellerseitigen Sicherheitsaussagen oder allgemein akzeptierten Sicherheitszielen. Typischerweise bedeutet dies den unautorisierten Zugriff eines kompromittierten Hosts oder einer dritten Partei auf private Daten oder kryptographisches SchlA1/4sselmaterial. Hinweis: Es werden keine Aussagen zur VollstA$?ndigkeit der Analyse gegeben. Insbesondere kAPnnen mAPglicherweise andere Schwachstellen existieren, die ein hAPheres Risiko darstellen. Es wurde unsererseits weder eine systematische Bedrohungsanalyse durchgefA1/4hrt, noch wurden Sicherheitsanforderungen abgeleitet. Stattdessen wird A1/4ber die vom Hersteller formulierten Sicherheitsaussagen und -maAnahmen sowie allgemein anerkannte Prinzipien (beispielsweise sollten private SchlA1/4ssel nicht auslesbar sein) argumentiert. In der Zwischenzeit wurden neue [SE]- und [SX]-Versionen des Produktes auf den Markt gebracht und durch das Bundesamt fA1/4r Sicherheit in der Informationstechnik zum Schutz von VS-NfD-Daten zugelassen. Diese beiden Versionen standen uns fA1/4r Tests nicht zur VerfA1/4gung. Aus diesem Grund kAPnnen wir keine Aussage darA1/4ber treffen, ob die in diesem Dokument beschriebenen Schwachstellen auch bei den beiden zugelassenen Produktvarianten zutreffen -- es kann aber auf Basis unseres Erkenntnisstandes auch nicht ausgeschlossen werden. Das BSI kann eine Zulassung auch an (in der Regel nicht-APffentliche) Bedingungen knA1/4pfen, die Risiken mitigieren. 2. Beschreibung der Schwachstellen und mAPgliche GegenmaAnahmen 1. Aktivierter root-Nutzer mit SSH-Zugang im Ecos System Management Die System Management Appliance enthA$?lt einen aktivierten root-Nutzer, dem SSH-Zugang erlaubt wird. Die Passwortdatei /etc/shadow zeigt auAerdem, dass ein Passwort fA1/4r den Nutzer gesetzt ist. Die Datei selbst wird wA$?hrend der Installation der Appliance von einem Ecos-Server heruntergeladen. Somit kontrolliert Ecos das Passwort fA1/4r den administrativen Zugang. MAPglicherweise werden hierbei von Ecos fA1/4r unterschiedliche Kunden verschiedene PasswAPrter gesetzt, da in die Download-Anfrage der LizenzschlA1/4ssel eingeht. Die in unserem Setup installierte shadow-Datei hat den folgenden Inhalt (die letzte Zeile ist eine base64-kodierte Signatur von 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== _Schritte zur ReAkaApiAtuAlaAtiAon:_ a. Installation des Ecos System Management in einer virtuellen Maschine b. Affnen des Festplatten-Images in einem externen Betriebssystem c. AberprA1/4fung, dass die Datei /usr/msrc/certs/shadow.new existiert und einen Hash fA1/4r das Passwort des root-Nutzer enthA$?lt d. Setzen des Passwort-Hashes fA1/4r den root-Nutzer in /etc/shadow auf einen selbstbestimmten Wert e. Booten der Appliance f. SSH-Login mit dem neu gesetzten Passwort _Potentielle Implikationen:_ - Der Hersteller hat die MAPglichkeit den root-Nutzer als HintertA1/4r zu verwenden und kann sich bei direkter NetzkonnektivitA$?t jederzeit in die Appliance einloggen. - Der Hersteller kann geheime Konfigurationsparameter, wie private SchlA1/4ssel und PasswAPrter, abrufen. - Der Hersteller kann sicherheitskritische Konfigurationsparameter verA$?ndern, etwa ein unsicheres VerschlA1/4sselungsschema aktivieren oder VNC-Logins auf den SBS aktivieren. - Falls der Hersteller jemals selbst von einem Sicherheitsproblem betroffen sein sollte, beispielsweise durch einen gekA1/4ndigten Mitarbeiter oder eine Software-Schwachstelle, kAPnnten weitere Parteien das Passwort erhalten. - Falls dasselbe Passwort fA1/4r alle Kunden der Appliance verwendet wird: - Ein Angreifer kAPnnte durch einen Brute-Force-Angriff Kenntnis des Passworts erhalten und Zugriff auf andere Installationen erhalten. - Falls das Passwort je verwendet werden sollte, kAPnnte es durch einen Man-in-the-Middle-Angriff in die HA$?nde eines Angreifers gelangen, der es fA1/4r eigene Zwecke missbrauchen kann. _MAPgliche GegenmaAnahmen:_ Ein Angriff kann durch einen der folgenden Schritte verhindert werden: - Das Passwort kann durch ein extern gebootetes System geA$?ndert werden. Dieser Schritt erfordert unter UmstA$?nden die Abschaltung des Update-Systems, um sicher zu stellen, dass diese Anderung nicht rA1/4ckgA$?ngig gemacht wird. - Der Zugriff durch den Nutzer "root" kann in der sshd_config deaktiviert werden. - Der Zugriff auf das Ecos System Management kann durch eine externe Firewall fA1/4r Port 22 unterbunden werden. Der SSH-Prozess auf Port 909 scheint den Zugriff durch "root" bereits deaktiviert zu haben. 2. Easy Enrollment empfA$?nglich fA1/4r Man-in-the-Middle-Angriffe Das Easy Enrollment erlaubt es Nutzern ihren SBS (im Auslieferungszustand) A1/4ber das Internet mit dem Management zu koppeln und zu initialisieren. Die Authentisierung erfolgt mithilfe eines "Activation Code" und einer "Passphrase", die aus sechs Ziffern besteht. Diese initiale Inbetriebnahme erfolgt technisch durch das Kopieren der Konfigurationsparameter von der zentralen Management Appliance, deren IP-Adresse in den Activation Code kodiert ist. Um sich gegenA1/4ber dem Management zu authentisieren, baut der SBS eine SSH-Verbindung auf Port 909 auf. Hierzu wird das SSH-Password-Authentisierungschema benutzt, wobei der Nutzername und das Passwort sich direkt aus Activation Code und Passphrase ergeben. Da der kryptographische Fingerprint des SSH Servers _nicht_ A1/4berprA1/4ft wird, kAPnnen Activation Code und Passphrase durch einen einfachen Man-in-the-Middle-Angriff abgefangen werden. _Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/enrollmentMITM.mp4 _Potentielle Implikationen:_ - Ein Angreifer kann jegliche Aktion ausfA1/4hren, die auch bei einem legitimen Enrollment geschieht. Er kann den Prozess auch jederzeit abbrechen, um den Code aktiviert zu lassen. Der Angriff kann transparent fA1/4r den Nutzer erfolgen. - Der SBS des Nutzers kann durch den Angreifer impersonifiziert werden. _MAPgliche GegenmaAnahmen:_ Easy Enrollment darf nur innerhalb von vertrauenswA1/4rdigen Netzen durchgefA1/4hrt werden. Beim Einsatz von Smartcards kAPnnte das Easy Enrollment von diesem Angriff nicht betroffen sein, da die Smartcard-Initialisierung in einem separaten Offline-Schritt erfolgt. Wir haben dies jedoch nicht verifiziert. 3. Easy Enrollment erlaubt die Extraktion beliebiger Nutzerkonfigurationen Nach dem der Easy-Enrollment-Prozess einen SSH-Tunnel aufgebaut hat, sendet der SBS darA1/4ber eine Reihe von HTTP-Anfragen an den Server. Die Antworten enthalten alle Dateien, die fA1/4r ein initiales Bootstrapping erforderlich sind, beispielsweise private und APffentliche SSH-SchlA1/4ssel des SBS. Diese werden fA1/4r spA$?tere SSH-Verbindungen verwendet. Nach Abschluss des initialen Downloads wird der Activation Code aus der Datenbank gelAPscht. Ein Angreifer kann einen Activation Code jedoch auch fA1/4r beliebige SSH-Port-Weiterleitungen auf dem Management benutzen. Dadurch ist es ihm mAPglich sich auf Ports zu verbinden, die durch Binden an 127.0.0.1 ausschlieAlich innerhalb des Managements zur VerfA1/4gung stehen sollten. Die zentrale CouchDB des Managements akzeptiert Anfragen auf Port 5984 und kann dazu gebracht werden die Nutzerkonfigurationen _beliebiger_ Sticks und Nutzer auszugeben. ZusA$?tzlich muss der Angreifer den Activation Code nicht lAPschen, sodass der Angriff unbemerkt geschehen kann. _Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/enrollmentKeyExtraction.mp4 _Potentielle Implikationen:_ - Ein Angreifer, der Zugriff auf einen gA1/4ltigen Activation Code erhA$?lt (Passphrase bietet durch geringe Entropie keinen Schutz) oder der einen erfolgreichen Man-in-the-Middle-Angriff durchgefA1/4hrt hat, kann die privaten SchlA1/4ssel _aller_ Nutzer kompromittieren. - Der Angreifer kann die Management Datenbank verA$?ndern und etwa einen VNC-Server mit schwachem Passwort auf einigen SBS aktivieren. - MAPglicherweise kAPnnen weitere private Dienste oder gar andere Hosts zugA$?nglich sein (wurde unsererseits nicht nA$?her untersucht). _MAPgliche GegenmaAnahmen:_ Easy Enrollment darf nur innerhalb von vertrauenswA1/4rdigen Netzen durchgefA1/4hrt werden (insbesondere nicht A1/4ber das Internet), beispielsweise durch Blockieren von Port 909 (mit Seiteneffekten, da auch andere Management-Komponenten erreichbar sind). 4. SchlA1/4sselmaterial zugreifbar nach Hardware-Reset von SBS Ecos erklA$?rt: "Die Nutzung des Sticks hinterlA$?sst keinerlei Spuren, womit es ausgeschlossen ist RA1/4ckschlA1/4sse auf Verbindungsdaten oder Arbeitsdaten zu nehmen." Trotz dieser Aussage verbleibt nach einem harten Neustart des PCs (z.B. durch BetA$?tigen des Reset-Knopfs) wA$?hrend der AusfA1/4hrung des SBS vertrauliches SchlA1/4sselmaterial im Speicher zurA1/4ck. Ein kompromittiertes Betriebssystem auf dem Hostrechner kann anschlieAend dieses SchlA1/4sselmaterial aus dem "uninitialisierten" Hauptspeicher lesen. Dies kann beispielsweise auch bei folgendem Arbeitsablauf passieren: Ein Nutzer resettet das OS eines Ecos SBS versehentlich, arbeitet weiter, fA$?hrt seine Ecos-SBS-Sitzung sauber herunter und bootet in ein kompromittiertes OS. Der Speicher der ersten (abgebrochenen) Ecos-Sitzung wird dabei nicht notwendigerweise vollstA$?ndig von der zweiten A1/4berschrieben. _Schritte zur Rekapitualtion:_ a. Abersetzen und installieren des _RAM imaging utility_ von https://github.com/dbrant/bios_memimage b. Reset wA$?hrend das Betriebssystem des Ecos SBS lA$?uft c. Extraktion von Langzeit- und SitzungsschlA1/4sseln aus dem erzeugten Speicherabbild. In AbhA$?ngigkeit von der verwendeten Hardware kann die Interpretation ein weiteres Descrambling erforderlich machen (siehe [1] und [2]). Das MSI Z170A GAMING M7 Mainboard, welches zu Demonstrationszwecken verwendet wurde, funktioniert ohne einen solchen Schritt. _Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/coldBoot.mp4 _Potentielle Implikationen:_ - Ein kompromittiertes Host-Betriebssystem (oder mit niedrigerer Wahrscheinlichkeit sogar Anwendungen) kann Zugriff auf SchlA1/4sselmaterial erhalten, welches durch den SBS gesichert werden sollte. Dies beinhaltet: - Private SchlA1/4ssel um Sticks gegenA1/4ber dem Management zu authentisieren - Private SchlA1/4ssel um Sticks gegenA1/4ber VPN-Konzentratoren oder Webseiten zu authentisieren - SitzungsschlA1/4ssel die beispielsweise VPN-Verbindungen oder Terminal-Server-Sitzungen schA1/4tzen - Symmetrische SchlA1/4ssel, welche die Stick-"Firmware" und Nutzerkonfiguration sichern - Angreifer kAPnnen dieses Szenario bewusst hervorrufen, um SchlA1/4sselmaterial aus dem Stick zu extrahieren - Angreifer kAPnnen die Nutzerkonfiguration aus dem Stick extrahieren oder diese auch manipulieren (siehe Schwachstellen 8 & 10). _MAPgliche GegenmaAnahmen:_ Nach einem Neustart mA1/4ssen Nutzer den PC vollstA$?ndig und fA1/4r mehrere Sekunden vom Strom trennen, um sicherzustellen, dass der Speicher seinen Zustand verloren hat. Bei Nutzung von A$?lteren RAM-Typen muss der PC unter UmstA$?nden eine lA$?ngere Zeit vom Strom getrennt werden. GerA$?te, die nicht sicher ausgeschaltet werden kAPnnen, etwa weil die Akkus nicht zu entfernen sind, sollten nicht verwendet werden. Langzeitgeheimnisse kAPnnen mAPglicherweise durch den Einsatz einer externen Smartcard besser geschA1/4tzt werden, wir haben diese Option jedoch nicht untersucht. 5. SBS kann geklont werden Der Hersteller bewirbt den Stick zur Nutzung als zweiten Authentisierungsfaktor, bei dem das Zertifikat an die Hardware-ID des Sticks gekoppelt wird (wAPrtlich "Zertifikat, gekoppelt an die Hardware-ID des Sticks"). Dies suggeriert, dass der Stick nicht durch einen Angreifer beziehungsweise kompromittierte Software geklont werden kann. Der SBS ist nicht ausreichend gegen ein Klonen geschA1/4tzt, da aktuelle Generationen von USB-Speicher-Sticks schlicht A1/4ber keine feste "Hardware-ID" verfA1/4gen. Ein Angreifer kann Parameter wie die Vendor- und Product-ID sowie die Seriennummern auf allgemein verfA1/4gbaren Speicher-Sticks frei A$?ndern [3]. Ein Angreifer beziehungsweise eine bAPsartige Software muss anschlieAend nur eine 1:1-Kopie des Sticks erstellen (zum Beispiel durch Nutzung von dd auf einem Unix-System). Anzumerken ist, dass hierzu kein physischer Zugang erforderlich ist. Alle erforderlichen Inhalte des Sticks kAPnnte A1/4ber das Internet A1/4bertragen werden, sobald der Stick in einen PC gesteckt wird auf dem eine kompromittierte Software aktiv ist. _Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/stickClone.mp4 _Potentielle Implikationen:_ - Sticks kAPnnen lokal oder entfernt dupliziert werden, sodass der Faktor "Besitz" umgangen wird. Dies kann vom Nutzer unbemerkt erfolgen. - Da die "Firmware" des Sticks nicht aktiviert wird, kann dies auch ohne Wissen des Bootkennworts erfolgen. - Angreifer kAPnnen "Backups" von bestimmten Stick-Konfigurationen erstellen und den entsprechenden Zustand wiederherstellen falls diese zentral verA$?ndert oder der SBS eingezogen wurde (beispielsweise nach Beendigung eines DienstverhA$?ltnisses). _MAPgliche GegenmaAnahmen:_ Nutzer sollten den SBS nicht in GerA$?ten verwenden, deren Hard- und Software nicht in vollen Umfang vertraut werden kann. Dies schlieAt mAPglicherweise kompromittiertes USB-Equipment, wie Hubs, mit ein. Die Nutzung eines anderen zweiten Faktors, wie einer Smartcard sollte das Problem beheben, dies wurde im Rahmen der Analyse jedoch nicht nA$?her untersucht. Starke BootpasswAPrter kAPnnen den "ersten Faktor" stA$?rken, sodass der physische Besitz des Sticks weniger relevant fA1/4r das Erreichen des angestrebten Sicherheitsniveaus ist. Das Sperren von Nutzerzertifikaten an zentralen Punkten (VPN-Konzentratoren, Terminal-Server oder internen Webseiten) ist einem Einziehen des SBS als SicherheitsmaAnahme vorzuziehen. 6. SBS kann in virtueller Maschine verwendet werden ErklA$?rung des Herstellers: "Vor AusfA1/4hrung der Firmware erfolgt eine PrA1/4fung, ob der Stick in einer virtuellen Maschine gebootet wurde. Dies verhindert, dass die SchutzmaAnahmen des Sticks unterlaufen werden und beispielsweise ein Keylogger oder Trojaner auf dem Hostsystem Bildschirminhalte oder TastaturanschlA$?ge protokolliert." Die Entwicklung guter Erkennungsstrategien einerseits und die Verbesserung von VMs zur Vermeidung einer solchen Erkennung andererseits ist ein fortwA$?hrender Wettlauf -- unter anderem zwischen Virenautoren und Antivirusherstellen. Aus theoretischer Sicht ist eine Erkennung einer virtualisierten Umgebung nicht unter allen UmstA$?nden zu garantieren. Allerdings kann es aus praktischer Sicht vergleichsweise schwierig sein eine solche Virtualisierungsumgebung zu implementieren (siehe z.B. [4]). Dies fA1/4hrt zur Frage wie sich die SchutzmaAnahmen des SBS in diesem Spannungsfeld einordnen. Fehlermeldungen wA$?hrend des Bootvorgangs deuten darauf hin, dass die Erkennung ein Teil der kryptographischen Schutzmechanismen ist. Zeichenketten in der verantwortlichen Executable zeigen verblA1/4ffende Ahnlichkeiten zur Virtualisierungserkennung von systemd (der GPL-Code kann im https://github.com/systemd/systemd/blob/master/src/basic/virt.c) eingesehen werden. Allerdings wurde die Erkennung von systemd nie entwickelt, um gegen bAPsartige Angriffe zu bestehen, so dass es nicht A1/4berrascht, dass ein unmodifiziertes KVM einfach instruiert werden kann einen SBS in einer VM zu booten. Es genA1/4gt folgendes Kommando: 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=' Falls ein Angreifer keinen physischen Zugang zu einem Stick haben sollte, sondern nur ein Image (beispielsweise von einem kompromittierten Rechner), kann er durch einen simplen Patch von QEMU den gleichen Ansatz verwenden. Blaupausen sind im https://lists.gnu.org/archive/html/qemu-discuss/2015-07/msg00072.html. _Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/virtualization.mp4 _Potentielle Implikationen:_ Es existieren zwei Szenarien in denen die Schwachstelle zu einem erfolgreichen Angriff fA1/4hren kann: 1. Ein legitimer Benutzer virtualisiert eigeninitiativ, etwa aus Bequemlichkeit oder weil er ein Bildschirmfoto machen mAPchte. Gerade Letzteres sollte laut Herstelleraussage unmAPglich sein: "Das Erstellen, Abspeichern, Drucken oder Weiterleiten von Bildschirmkopien wird A1/4ber eine sichere ZugangslAPsung verhindert." 2. Der Nutzer weiA nicht, dass sein System virtualisiert betrieben wird. Wie bereits vor mehr als 10 Jahren demonstriert wurde, ist es bAPsartiger Software mAPglich, dass eigentliche Betriebssystem in einer VM auszufA1/4hren, um die eigene Anwesenheit zu verbergen [5]. Auch fA1/4r einen dediziert gebooteten SBS sind verschiedene nutzertransparente Virtualisierungsangriffe denkbar. Beispiele sind: - Ein kompromittiertes Betriebssystem verA$?ndert im UEFI NVRAM die Bootreihenfolge (offizielle API-Funktion). Es stellt auf diese Weise sicher, dass das Booten vom USB-Stick deaktiviert wird. Falls beim Booten ein Ecos-Stick detektiert wird, fA$?hrt es den Stick in einer VM hoch. - Ein kompromittiertes Betriebssystem rebootet den PC nicht nach Nutzeranweisung. Stattdessen wird ein kurzes Video mit BIOS-Ausgaben gezeigt und der SBS in einer virtuellen Maschine gestartet. - Eine bAPsartige Software modifiziert den SBS, sodass er immer in einer VM bootet (siehe Schwachstelle 10, warum dies mAPglich ist). Ein virtualisiertes Ecos-SBS-System kann jederzeit vollstA$?ndig A1/4berwacht und modifiziert werden. Das bedeutet ein Angreifer ist in der Lage: - Nutzerverhalten, Sitzung-, LangzeitschlA1/4ssel, PINs und PasswAPrter aufzuzeichnen. Das heiAt der Angreifer kontrolliert _beide_ Teile der Zweifaktorauthentisierung. - Er kann laufende Programme, das SBS-Betriebssystem und involvierte Daten verA$?ndern. - Alle extrahierten Daten kAPnnen unter Umgehung der SBS-eigenen Firewall A1/4ber das Netzwerk versendet werden, sodass ein Angreifer keinen physischen Zugang benAPtigt. Zusammenfassend kAPnnen keinerlei Sicherheitsziele garantiert werden, falls Virtualisierungsangriffe nicht effektiv verhindert werden kAPnnen. _MAPgliche GegenmaAnahmen:_ Nutzer dA1/4rfen den SBS nicht in GerA$?te einstecken, die unvertrauenswA1/4rdige Hard- oder Software enthalten kAPnnten. Administratoren mA1/4ssen sich bewusst sein, dass Nutzer Virtualisierung verwenden, um ihre Sticks zu betreiben. Falls den Nutzern nicht vollstA$?ndig vertraut werden kann, kann der SBS nicht sicher eingesetzt werden. 7. SBS ist anfA$?llig fA1/4r HintertA1/4ren in Firmwares der Hardware Der Hersteller erklA$?rt: "ZusA$?tzlich A1/4bernimmt das ECOS SECURE LINUX die Hoheit A1/4ber die angeschlossene Peripherie, so dass selbst eine Schadsoftware im BIOS oder im UEFI keine Bedrohung darstellt." Diese Aussage ist recht A1/4berraschend, denn sie widerspricht: - FrA1/4heren und aktuellen Aussagen der Forschungsgemeinschaft (siehe [6] oder [7]) - Der Ansicht eines angesehenen Anonymisierungsprojektes, welches ebenfalls auf ein sicheres Bootmedium setzt (Tails: https://tails.boum.org/doc/about/warning/index.en.html) - Aussagen von Intel (z.B. https://firmware.intel.com/sites/default/files/STM_User_Guide-001.pdf) Um die Herstelleraussage zu validieren, wurde eine freiverfA1/4gbare UEFI-HintertA1/4r von https://github.com/Cr4sh/SmmBackdoor leicht modifiziert. So wurde beispielsweise eine einfache Speicherersetzungsstrategie implementiert, die es erlaubt IPsec-SitzungsschlA1/4ssel auf portable Art und Weise zu extrahieren und A1/4ber das Internet zu versenden. Das Resultat ist ein circa 600 Zeilen C-Code umfassendes EFI-Modul, welchen in einem MSI Z170A GAMING M7 Motherboard installiert wurde. Dazu genA1/4gt das AusfA1/4hren einer Datei mit einem Administrator-Account in einer unmodifizierten Windows-Installation. DafA1/4r wurde ein aktuelles UEFI von der offiziellen MSI-Webseite bezogen, mittels eines https://github.com/LongSoft/UEFITool modifiziert und anschlieAend mit dem offiziellen MSI BIOS Upgrade Tool aufgespielt. Der Ansatz ist hochgradig flexibel, da das verA$?nderte UEFI beispielsweise A1/4ber gezielte Mails oder einen https://hakshop.com/products/usb-rubber-ducky-deluxe) (siehe Video injiziert werden kann. Wie zu erwarten, kann der Ecos SBS die Extraktion des SchlA1/4sselmaterials nicht verhindern. Ein Angreifer ist in der Lage, IPsec-SchlA1/4ssel auszuleiten und eine gekapselte RDP-Session in Echtzeit abzuhAPren. _Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/smmBackdoor.mp4 Durch Speichermanipulationen ist es ebenfalls mAPglich, Programmcode im SBS zur Laufzeit zu verA$?ndern. Zur Demonstration wurde der login-Prozess verA$?ndert, sodass er eine Root-Shell APffnet. Andere VerA$?nderungen sind selbstverstA$?ndlich ebenfalls mAPglich. _Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/loginPatch.mp4 _Potentielle Implikationen:_ - Eine manipulierte PC-Firmware kann jegliche laufenden Betriebssysteme, Programme und Nutzerdaten in Echtzeit verA$?ndern ohne dass dies durch eine Software festgestellt werden kann. - Es kAPnnen Daten, wie Sitzungs-, LangzeitschlA1/4ssel, PasswAPrter und PINs aus Haupt- und Massenspeichern gelesen werden. - Jegliche Art einer lokalen Firewall kann umgangen werden, um Informationen A1/4ber das Netz zu senden. Zusammenfassend kAPnnen keinerlei Sicherheitsziele garantiert werden, falls die Firmware einer Hardware kompromittiert wurde auf der ein SBS ausgefA1/4hrt wird. _MAPgliche GegenmaAnahmen:_ Nutzer dA1/4rfen den SBS nicht in GerA$?te einstecken, die unvertrauenswA1/4rdige Hard- oder Software enthalten kAPnnten. 8. Konstruktion der Trust-Chain adressiert Problemstellung ungenA1/4gend Ecos bewirbt die UEFI-Secure-Boot-UnterstA1/4tzung als ein Sicherheitsmerkmal. Weiterhin geben sie an: "In einer A>>Chain-of TrustA<< A1/4berprA1/4fen sich Bootloader, Kernel und Applikationen gegenseitig durch einen sich permanent wiederholenden Prozess." Bereits die vorhergehenden zwei Schwachstellen unterstreichen, dass nicht die BIOS/UEFI-Komponente die IntegritA$?t und AuthentizitA$?t des gestarteten Betriebssystems verifizieren muss, sondern dass das Betriebssystem in der Lage sein mA1/4sste zu verifizieren, dass es in einer authentischen Umgebung gestartet wurde. Dieses Sicherheitsmerkmal wird durch UEFI-Secure-Boot schlicht nicht realisiert. Ecos hat signifikanten Aufwand betrieben, um eine vom UEFI ausgehende eine "Top-Down"-Verifikation zu realisieren, allerdings kann ein Angreifer die AberprA1/4fungen einfach entfernen oder die Komponenten ersetzen, zum Beispiel einen Vanilla-Kernel oder einen eigenen Bootloader. UEFI-Secure-Boot kann den Start eines so modifizierten Sticks nur unter folgenden UmstA$?nden garantiert verhindern: - Das UEFI und anderen Hardware-Komponenten sind nicht kompromittiert (siehe vorhergehende Schwachstelle) - Der Hersteller hat die Hoheit A1/4ber alle in den GerA$?ten installierten UEFI-SchlA1/4ssel und stellt sicher, dass nur der eigene Bootloader startet. Aktuell hat Microsoft die Hoheit A1/4ber diese SchlA1/4ssel und erlaubt auch die Signatur von Bootloadern dritter Parteien. Ferner unterlaufen auch Microsoft sicherheitskritische Fehler (siehe https://www.heise.de/security/meldung/Kardinalfehler-Microsoft-setzt-aus-Versehen-Secure-Boot-schachmatt-3291946.html). - Der USB-Stick (oder eine andere vertrauenswA1/4rdige Instanz) verhindert das Booten der Umgebung, falls die Hardware nicht A1/4ber einen UEFI-Secure-Boot unter den obigen Bedingungen verfA1/4gt. Die letzte Bedingung impliziert, dass der Stick auf eine geeignete Art seine Umgebung verifizieren muss. Der Stick verifiziert allerdings aktuell nur den gestarteten Kernel (weder das BIOS/UEFI noch den tatsA$?chlich aktiven Bootloader). Auch diese Authentisierung geschieht nur an zwei Stellen; wir werden uns im Folgenden auf die ausgeklA1/4geltere konzentrieren. Hierbei geht der gestartete Kernel in den Prozess zur EntschlA1/4sselung des SBS-Dateisystems mit ein. Ein tatsA$?chliches Ausnutzen der ungenA1/4genden vom UEFI-ausgehenden Vertrauenskette wird im Rahmen von Schwachstelle 10 vorgestellt. Um SchlA1/4sselmaterial abzuleiten, mit dem auf die verschlA1/4sselten Teile des SBS zugegriffen werden kann, misst der initiale Userland-Prozess (das A!nit-Programm aus dem initrd-Image auf Partition 4) den Kernel, den Stick selbst und die aktiven Userland-Prozesse. Der Bootprozess beendet sich mit einem "EntschlA1/4sselungsfehler", wenn Anderungen detektiert werden. Das heiAt Modifikationen an der Bootkette, z.B. durch vorheriges Starten eines Programms, A$?ndern die Messung und Modifikationen an spA$?ter aktivierten Komponenten scheitern, da diese Teile verschlA1/4sselt und authentisiert sind. Ein Angreifer kAPnnte den Maschinencode der involvierten Executables analysieren, aber es existiert ein weit bequemerer und flexiblerer Weg: Fortschritte bei der Entwicklung von Sandboxing-Umgebungen kAPnnen genutzt werden, den Prozess der SchlA1/4sselgenerierung kontrolliert auszufA1/4hren. Beispielsweise kann https://usercorn.party verwendet werden, um alle Syscalls abzufangen, gegebenenfalls zu modifizieren oder zu unterdrA1/4cken. Unter Nutzung dieser Technik kann exakt kontrolliert werden, welche Informationen der Prozess erhA$?lt und welche verborgen bleiben sollen. Zum Beispiel kann der SignaturprA1/4fung einfach ein anderes Image gegeben werden, als das welches spA$?ter eingebunden wird. Falls der Nutzer kein Bootpasswort gesetzt hat, kAPnnen auf diese Weise direkt alle Geheimnisse, die im SBS gespeichert sind, extrahiert werden. Um ein vorzeitiges Abbrechen der Emulation zu verhindern, mA1/4ssen weitere Syscalls in usercorn abgefangen werden. Dabei ist es jedoch hinreichend dem aufrufenden Prozess eine erfolgreiche AusfA1/4hrung durch einen geeigneten RA1/4ckgabewert zu signalisieren. Eine eigentliche Implementation der Syscalls ist nicht erforderlich. Die Verwendung von usercorn ist allerdings nicht die einzige MAPglichkeit den Kontrollfluss bei der SchlA1/4sselgenerierung zu steuern. Zumindest die folgenden fA1/4nf AnsA$?tze sind denkbar: 1. Die Argumente, die der init-Prozess dem Linux-Kernel A1/4bergibt, kAPnnten in einem modifzierten Linux-Kernel vor der AusfA1/4hrung geA$?ndert werden. Beispielsweise kAPnnte der gestartete Prozess geeignet markiert werden, und beim Lesen von Dateien wie /proc/keys einfach den Inhalt einer anderen Datei erhalten. 2. Syscall-Argumente kAPnnen auch zur Laufzeit durch ptrace und seccomp verA$?ndert werden (https://github.com/alfonsosanchezbeato/ptrace-redirect). 3. Die init-Datei kann in einem Debugger gestartet und Breakpoints bei jeder int 80h-Instruktion (Syscall) gesetzt werden. Beim Anspringen der Breakpoints kAPnnen anschlieAend die Argumente der Syscalls vor jeder AusfA1/4hrung verA$?ndert werden. 4. Eine String-Analyse des init-Programms legt die starke Vermutung nahe, dass es GPL-lizensierten Programm-Code enthA$?lt, wodurch das komplette Programm dieser Lizenz unterliegen wA1/4rde. Der Hersteller wA$?re in diesem Fall verpflichtet, jedem Nutzer den vollstA$?ndigen Programm-Code zugA$?nglich zu machen, den dieser modifizieren und weitergeben kAPnnte. Ein Angreifer kAPnnte mittels des auf diese Weise beschafften Codes ein eigenes, beliebig modifiziertes init-Programm erzeugen. 5. Es ist mAPglich, spezifische Teile der init-Binary durch Analyse und VerA$?nderung des Maschinencodes in ihrem Verhalten zu modifizieren. Beispielsweise kAPnnen SignaturprA1/4fungen A1/4bersprungen oder Dateizugriffe umgeleitet werden. _Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/offlineKeyExtraction.mp4 _Potentielle Implikationen:_ - Falls kein Bootpasswort gesetzt wurde, kann ein Angreifer die gesamte Nutzerkonfiguration einsehen, inklusive der privaten SchlA1/4ssel. - Falls ein Bootpasswort gesetzt wurde, kann ein Angreifer PasswAPrter durch die Emulation automatisch durchprobieren lassen. Falls das Bootpasswort nicht ausreichend Entropie besitzt kAPnnen die gleichen Daten extrahiert werden. - In jedem Fall kann der stick-spezifische Teil der Konfiguration und die "Firmware" des Sticks ausgelesen werden, ohne den SBS zu booten. Dies ist eine Voraussetzung fA1/4r das Ausnutzen der folgenden Schwachstellen. _MAPgliche GegenmaAnahmen:_ Die Folgenden drei MaAnahmen wirken nur in Kombination: - Die BootpasswAPrter dA1/4rfen nicht fA1/4r Bruteforce-Angriffe empfA$?nglich sein. - Die Nutzer mA1/4ssen sicherstellen, dass sie tatsA$?chlich von einem angesteckten Stick booten (PC abschalten, wieder anschalten im BIOS die Bootreihenfolge A1/4berprA1/4fen), da ein kompromittiertes Betriebssystem die SBS-Umgebung einfach vortA$?uschen kAPnnte. Dabei kAPnnte es auch das Bootpasswort abfragen, indem der initiale Prozess in einer Sandbox ausgefA1/4hrt wird. - Es dA1/4rfen ausschlieAlich USB-Sticks mit einem hardware-seitigen Schreibschutz genutzt werden (Details folgen in Schwachstelle 10). Der Schreibmodus darf lediglich in vollstA$?ndig vertrauenswA1/4rdigen Umgebungen aktiviert werden. 9. Aktivierter SSH-Zugang fA1/4r vorkonfigurierten root-Nutzer im Ecos SBS Unter Nutzung der EntschlA1/4sselungsmethode ist es nicht nur mAPglich, das sogenannte "Firmware"-Image und die nutzerspezifische Konfiguration zu extrahieren, sondern es findet sich auch eine weitere Konfiguration im Verzeichnis basedata/certs der vierten Partition, die fA1/4r alle unterschiedlichen Bootmethoden gleich ist. Diese Konfiguration ist nicht durch das Bootpasswort geschA1/4tzt und kann daher in jedem Fall extrahiert werden. Das Verzeichnis enthA$?lt unter anderem eine verschlA1/4sselte und signierte shadow Datei. Im untersuchten Stick hatte sie den folgenden Inhalt: 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== Die base64-kodierte Signatur verweist auf Ecos, wurde also nicht durch die Management Appliance generiert. Weiterhin ist die shadow-Datei bereits werksseitig auf Sticks vorhanden, die noch nicht initialisiert wurden, also auch noch keinen Kontakt zum Management des Kunden hatten. Dies weist auf einen weiteren undokumentierten root-Zugang hin. Im Unterschied zu Schwachstelle 1 allerdings nicht in der Management Appliance, sondern direkt auf den Sticks selbst. Dass es sich tatsA$?chlich um einen Zugang handelt, der vom Hersteller auch A1/4ber SSH genutzt werden kAPnnte, wird im Zuge der nA$?chsten Schwachstelle demonstriert. _Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/sbsRootAccess.mp4 _Potentielle Implikationen:_ - Der Hersteller hat die MAPglichkeit den root-Nutzer als HintertA1/4r zu nutzen und sich in einen SBS einzuloggen, wenn dieser aktiv ist. - Der Hersteller kann auf Dateien auf der privaten Festplatte des Nutzers zugreifen. Ecos behauptet zwar: "Schutz vor Zugriff auf private Fotos und E-Mails". Allerdings enthA$?lt das "gehA$?rtete" Linux-Betriebssystem des SBS sogar einen NTFS-Dateisystem-Treiber, der A1/4ber SSH genutzt werden kann. - Der Hersteller kann vertrauliche Konfigurationsparameter, wie private SchlA1/4ssel und PasswAPrter, einsehen. - Der Hersteller kann die Konfiguration des Sticks verA$?ndern, z.B. auf ein unsicheres VerschlA1/4sselungsschema wechseln. - Falls der Hersteller jemals selbst von einem Sicherheitsproblem betroffen sein sollte, beispielsweise durch einen gekA1/4ndigten Mitarbeiter oder eine Software-Schwachstelle, kAPnnten weitere Parteien das Passwort erhalten. - Falls dasselbe Passwort fA1/4r alle Kunden verwendet wird: - Ein Angreifer kAPnnte durch einen Brute-Force-Angriff Kenntnis des Passworts erhalten und Zugriff auf andere Installationen erhalten. - Falls das Passwort je verwendet werden sollte, kAPnnte es durch einen Man-in-the-Middle-Angriff in die HA$?nde eines Angreifers gelangen, der es fA1/4r eigene Zwecke missbrauchen kann. _MAPgliche GegenmaAnahmen:_ Der SBS darf nicht in Szenarien eingesetzt werden in denen ein Zugriff auf den SSH-Dienst mAPglich ist. 10. Daten des SBS kAPnnen bAPsartig verA$?ndert werden Herstelleraussage: "SchreibgeschA1/4tzte Partition fA1/4r Firmware und Applikationen" Technisch sauberer ist die Aussage, dass unautorisierte Modifikationen am Stick -- etwa durch SignaturA1/4berprA1/4fungen -- erkannt werden. Allerdings ist auch diese relaxierte Aussage nicht in jedem Fall aufrecht zu erhalten, wie anhand der folgenden drei Szenarien diskutiert wird. VollstA$?ndiges Aberschreiben des SBS Der SBS ist hardware-seitig ein vAPllig gewAPhnliches USB-Speichermedium. Ein kompromittiertes Betriebssystem kAPnnte den Inhalt des gesamten Stick also vollstA$?ndig A1/4berschreiben, wenn der Nutzer den Stick einsteckt wA$?hrend das OS noch aktiv ist. Beispielsweise kAPnnte es ein minimales OS auf dem Stick platzieren, welches nach dem Booten sofort alle Massenspeicher absucht und darauf vorhandene Betriebssysteme infiziert. Danach kAPnnte es ein Ecos Logo mit der Fehlermeldung "Ihr PC wird nicht unterstA1/4tzt, bitte verwenden Sie den SBS in einem anderen PC" zeigen. Dieser Ansatz kAPnnte es einem Angreifer erlauben, Malware von einem Heimarbeitsplatz auf einen PC innerhalb eines Firmennetzes zu verbreiten. Missbrauch des root-Nutzers Wie bereits erwA$?hnt ist zwar die sogenannte "Firmware", also die eigentliche Arbeitsumgebung des SBS, durch eine Signatur geschA1/4tzt, die Stick-Konfiguration jedoch nur A1/4ber einen von auAen zu berechnenden symmetrischen Authentisierungswert. Das bedeutet, dass das SchlA1/4sselmaterial welches zur EntschlA1/4sselung verwendet wurde (siehe Punkt 8) auch dazu verwendet werden kann die Konfiguration zu verA$?ndern; mAPglicherweise ohne dass diese Modifikation erkannt wird. Die Stick-Konfiguration kann dabei selbst dann verA$?ndert werden, wenn das Bootpasswort _nicht_ bekannt ist. Das bedeutet, die im Rahmen der letzten Schwachstelle beschriebene shadow-Datei kann verA$?ndert und so ein eigenes root-Passwort gesetzt werden. Eine HA1/4rde ist noch zu nehmen: Der Angreifer muss die historische crypt-Methode benutzen, um den Hash des root-Passworts zu generieren und sicherstellen, dass eine update.conf-Datei im gleichen Verzeichnis existiert. Diese scheint nur auf manchen Sticks prA$?sent zu sein und enthA$?lt die folgenden Daten: reltype=V5.6.5 bbtype=mthc fn1=ca.crt fn2=base.pem fn3=runtime.pem fn4=shadow fn5=my.pem force-reltype=1 Nach dieser Modifikation kann ein Angreifer A1/4ber SSH auf den SBS zugreifen, unabhA$?ngig davon auf welchem Computer dieser gebootet wurde (sofern SSH-Netzwerkzugriff gegeben ist). Aber die SSH-Sitzung kAPnnen Langzeitgeheimnisse, SitzungsschlA1/4ssel und Daten von der privaten Festplatte des Nutzers abgegriffen werden (der SBS enthA$?lt hierzu bereits einen NTFS-Dateisystem-Treiber). Zum Teil kAPnnen diese auch modifiziert werden. AuAerdem enthA$?lt das "gehA$?rtete" Betriebssystem auch ein Werkzeug um Screenshots von der aktiven Nutzersitzung zu machen (/bin/xwd) und einen funktionsfA$?higen VNC-Server, sodass es mAPglich ist den Nutzer live zu beobachten oder sogar mit der Sitzung zu interagieren. Passives Beobachten wird dem SBS-Nutzer gegenA1/4ber nicht angezeigt (falls der Angreifer dies nicht explizit mAPchte). _Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/stickMod1.mp4 Selektives Modifizieren ausfA1/4hrbarer Dateien auf dem SBS Auch ohne Ausnutzen des schwach geschA1/4tzten Teils der Konfiguration ist es mAPglich den Stick auf geschickte Art zu modifizieren. So ist es mAPglich SignaturA1/4berprA1/4fungen vollstA$?ndig zu entfernen und den Stick mit einer HintertA1/4r zu versehen, die beispielsweise andere Betriebssysteme infiziert und den SBS als Wirt benutzt. Dazu kAPnnen die initialen SignaturA1/4berprA1/4fungen durch einen eigenen Bootloader (mit Ecos-Theme) und Kernel ausgehebelt werden. Durch einen modifizierten Kontrollfluss wA$?hrend des init-Prozesses, fA$?llt dies, ebenso wie eine VerA$?nderung des squashfs-Dateisystems, nicht auf. Im Rahmen von Schwachstelle 8 wurden verschiedene Wege beschrieben mit denen eine solche VerA$?nderung des Kontrollflusses erreicht werden kann. Es verbleiben die AberprA1/4fungen der geladenen Betriebssystemumgebung. Ecos beschreibt: "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." Allerdings ist es relativ schwierig diese SicherheitsA1/4berprA1/4fung A1/4berhaupt auszulAPsen, da sie auf einer (sehr kleinen) Whitelist zu basieren scheint. Von den 663 Dateien im /bin-Verzeichnis des "gehA$?rteten" Betriebssystems scheint dies nur auf eine Handvoll zuzutreffen. Es ist daher sehr einfach diesen Schutzmechanismus zu umgehen. FA1/4r Demonstrationszwecke wurde das Werkzeug /bin/insmod im Ecos-OS ausgetauscht, um eine Windows-Installation zu infizieren. Die Datei wird regelmA$?Aig ausgefA1/4hrt und ist nicht durch die Whitelist geschA1/4tzt. _Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/stickMod2.mp4 Diskussion bAPsartiger VerA$?nderungen _Potentielle Implikationen:_ Die Auswirkungen dieser Schwachstelle hA$?ngen stark vom Angriffsszenario und den Ressourcen des Angreifers ab. Hauptbedrohungen sind: - Der Angreifer kann den SBS nutzen, um Malware von Host zu Host zu A1/4bertragen. MAPglicherweise kAPnnten so weitere SBS infiziert werden. - Der Angreifer kann Daten vom privaten Massenspeicher des PCs sowie Konfigurationsparameter, PasswAPrter und private SchlA1/4ssel vom SBS auslesen (ohne ein mAPglicherweise starkes Bootpasswort zu kennen). - Der Angreifer kann den init-Prozess verA$?ndern, sodass das Bootpasswort oder die Smartcard PIN aufgezeichnet werden (falls er diese an anderer Stelle benAPtigt). - Falls eine Smartcard genutzt wird, kann ein Angreifer diese nutzen solange der SBS aktiv ist. - Der Angreifer kann jegliche SBS-interne Firewall abschalten. - Der Angreifer kann selbststA$?ndig eine Kommunikation initiieren, etwa zu einem zentralen Command-and-Control-Server. - In AbhA$?ngigkeit von den FA$?higkeiten des Angreifers kAPnnen alle aufgezA$?hlten Angriffe verdeckt ablaufen, das heiAt der Nutzer ist nicht in der Lage diese zu erkennen, da funktionale Aspekte des SBS weiterhin gewA$?hrleistet sind. _MAPgliche GegenmaAnahmen:_ Nutzer dA1/4rfen den SBS nicht in GerA$?te einstecken, die unvertrauenswA1/4rdige Hard- oder Software enthalten kAPnnten. SBS sollten nicht an unterschiedlichen PCs verwendet werden, um ein etwaiges Verbreiten von Malware zu unterbinden. 3. Zusammenfassung In diesem Dokument wurden verschiedene Schwachstellen des Ecos SBS und seiner Management Plattform diskutiert. Die Sicherheitsanalyse hat sich dabei auf den Bootprozess und das Easy Enrollment fokussiert. Nichtsdestoweniger zeigen die Resultate, dass eine Reihe von Sicherheitsaussagen der Herstellerwebseite und BroschA1/4ren zumindest aktuell nicht zu halten sind. Dies umfasst: - "Die Nutzung des Sticks hinterlA$?sst keinerlei Spuren, womit es ausgeschlossen ist RA1/4ckschlA1/4sse auf Verbindungsdaten oder Arbeitsdaten zu nehmen.", Schwachstelle 4 - "Zertifikat, gekoppelt an die Hardware-ID des Sticks", Schwachstelle 5 - "Vor AusfA1/4hrung der Firmware erfolgt eine PrA1/4fung, ob der Stick in einer virtuellen Maschine gebootet wurde. Dies verhindert, dass die SchutzmaAnahmen des Sticks unterlaufen werden und beispielsweise ein Keylogger oder Trojaner auf dem Hostsystem Bildschirminhalte oder TastaturanschlA$?ge protokolliert.", Schwachstelle 6 - "Das Erstellen, Abspeichern, Drucken oder Weiterleiten von Bildschirmkopien wird A1/4ber eine sichere ZugangslAPsung verhindert.", Schwachstellen 6 und 9 - "ZusA$?tzlich A1/4bernimmt das ECOS SECURE LINUX die Hoheit A1/4ber die angeschlossene Peripherie, so dass selbst eine Schadsoftware im BIOS oder im UEFI keine Bedrohung darstellt.", Schwachstelle 7 - "In einer A>>Chain-of TrustA<< A1/4berprA1/4fen sich Bootloader, Kernel und Applikationen gegenseitig durch einen sich permanent wiederholenden Prozess.", Schwachstelle 8 und 10 - "Schutz vor Zugriff auf private Fotos und E-Mails", Schwachstelle 9 und 10 - "SchreibgeschA1/4tzte Partition fA1/4r Firmware und Applikationen", Schwachstelle 10 - "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.", Schwachstelle 10 AuAerdem, wurden mAPgliche HerstellerhintertA1/4ren, eine Schwachstelle gegen Man-in-the-Middle-Angriffe und die MAPglichkeit aufgedeckt, die interne Management-Datenbank auszulesen, inklusive aller privaten SchlA1/4ssel assoziierter SBS. Einige dieser Schwachstellen mAPgen auf einfache NachlA$?ssigkeiten zurA1/4ckzufA1/4hren sein, etwa die aktivierten root-Nutzer oder die MAPglichkeit die Datenbank zu spiegeln. Ein groAer Anteil basiert jedoch auf konzeptionellen Fehlern. Von diesen kAPnnten Schwachstelle 5 durch die korrekte Nutzung mit einer Smartcard abgewendet werden. Die Kernprobleme von Schwachstellen 4, 6, 7 & 8 liegen jedoch in Limitierungen der aktuellen x86-Plattform. Sie kAPnnen nach Meinung der Autoren nicht ohne zusA$?tzliche hardware-seitige FA$?higkeiten oder die ausschlieAliche und exklusive Nutzung vertrauenswA1/4rdiger Hardware behoben werden. Aus makroskopischer Sicht sind die beschriebenen Schwachstellen ebenfalls interessant, da sie zeigen wie wenig verlA$?sslich punktuelle IT-Sicherheitstest bei EinfA1/4hrung eines Produktes sind. Die meisten Referenzkunden, die von Ecos angefA1/4hrt werden, gaben an, dass sie interne oder externe Sicherheitstests durchgefA1/4hrt haben. Die Empfehlungen implizieren, dass dabei keinerlei schwerwiegende Fragen bezA1/4glich der Sicherheit aufgekommen sind. Die Analyse unsererseits erstreckte sich A1/4ber einen Zeitraum von ungefA$?hr einem Monat und wurde neben unseren eigentlichen Forschungsprojekten durchgefA1/4hrt. Professionelle Pentester werden vermutlich weniger Zeitressourcen haben, sodass sie die verschiedenen kryptographischen Verschleierungsschichten nicht durchdringen kAPnnen. Selbst unser weniger beschrA$?nkter Zeitplan erlaubte keine vollstA$?ndige AberprA1/4fung aller Angriffsvektoren, die der SBS durch seinen Ansatz bietet. Dennoch ist es alarmierend, dass einige Herstelleraussage direkt der verbreiteten Meinung von Sicherheitsexperten widersprechen -- offensichtlich ohne signifikante Zweifel zu wecken. Am markantesten sind die folgenden Punkte: - Die Erkennung einer virtualisierten Umgebung kann nicht garantiert werden. - Firmwares (EFI aber auch Intel ME und weitere) in aktueller x86-Hardware dA1/4rfen nicht als sicher angenommen werden. - USB-GerA$?ten darf nur unter sehr strenge Auflagen vertraut werden ([8] enthA$?lt einen weiteren Angriffsvektor). Selbst der einfache BSI IT-Grundschutz enthA$?lt in Abschnitt M 4.63 die Anforderung "Der Telearbeitsrechner sollte A1/4ber einen Boot-Schutz verfA1/4gen, um zu verhindern, dass unbefugt von auswechselbaren DatentrA$?gern, z.B. von DVD oder USB-Stick, gebootet werden kann." Es existieren jedoch keine Hardware-Mechanismen, die zusichern kAPnnten, dass nur authentische Sticks gebootet werden kAPnnen. Dennoch behauptet Ecos zu M4.63 konform zu sein. 4. Autoren Die Schwachstellen wurden von Robert Lasch, Franz Girlich und Michael Rossberg (ohne bestimmte Reihenfolge) gefunden und mit Demonstrationen unterlegt. Wissenschaftliche Aufsicht fA1/4hrte Guenter Schaefer[1]. Fragen und Anmerkungen kAPnnen an Michael Rossberg via michael [dot] rossberg [at] tu [dash] ilmenau [dot] de gerichtet werden. Der korrespondierende GPG-Fingerprint lautet: FD9B 425C 8DE5 69D6 77ED 52C2 CC00 C314 0337 76C9 5. Ablauf der VerAPffentlichung - 13. April 2018 - Hersteller informiert - 30. April 2018 - BSI lA$?sst [SX] und [SE] Varianten des Sticks zur Verarbeitung von VS-NfD-Daten zu - 13. Juni 2018 - VerAPffentlichung 6. Referenzen [1] J. Bauer, M. Gruhn, und F. C. Freiling, aLest we forget: Cold-boot attacks on scrambled DDR3 memorya, _Digital Investigation_, Bd. 16, S. S65aS74, 2016. [2] S. F. Yitbarek, M. T. Aga, R. Das, und T. Austin, aCold boot attacks are still hot: Security analysis of memory scramblers in modern processorsa, in _High performance computer architecture (HPCA), 2017 IEEE international symposium on_, 2017, S. 313a324. [3] G. Ravago, aReverse engineering a USB flash drivea. 2015. [4] A. Sergeev, V. Minchenkov, und V. Bashun, aMalicious hypervisor and hidden virtualization of operation systemsa, in _Application of information and communication technologies (AICT), 2015 9th international conference on_, 2015, S. 178a182. [5] J. Rutkowska, aIntroducing blue pilla, _The official blog of the invisiblethings.org_, Bd. 22, S. 23, 2006. [6] S. Embleton und S. Sparks, aSMM rootkitsa, in _Proceedings of the 4th International Conference on Security and Privacy in Communication Networks, Securecomm_, 2008, Bd. 8. [7] J. Rutkowska, aIntel x86 considered harmfula, _the Invisible Things Lab_, 2015. [8] K. Nohl und J. Lell, aBadUSB a on accessories that turn evila, _Black Hat USA_, 2014. [1] TransparenzerklA$?rung: Guenter Schaefer arbeitet Vollzeit als Professor an der Technischen UniversitA$?t Ilmenau. Weiterhin ist er nebenberuflich ein Mitglied des Aufsichtsrats der secunet Security Networks AG.