| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 13 Jun 2018 16:38:14 +0200
From: Michael Rossberg <michael.rossberg@...ilmenau.de>
To: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>,
fulldisclosure@...lists.org
Subject: [FD] Multiple Security Issues in Ecos Secure Boot Stick (SBS)
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 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:_
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 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
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
ü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.
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: 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
»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 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
("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:_ 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 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[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, “Lest we forget: Cold-boot attacks
on scrambled DDR3 memory,” _Digital Investigation_, vol. 16, pp. S65–S74, 2016.
[2] S. F. Yitbarek, M. T. Aga, R. Das, and T. Austin, “Cold boot attacks are
still hot: Security analysis of memory scramblers in modern processors,” in
_High performance computer architecture (HPCA), 2017 IEEE international
symposium on_, 2017, pp. 313–324.
[3] G. Ravago, “Reverse engineering a USB flash drive.” 2015.
[4] A. Sergeev, V. Minchenkov, and V. Bashun, “Malicious hypervisor and hidden
virtualization of operation systems,” in _Application of information and
communication technologies (AICT), 2015 9th international conference on_, 2015,
pp. 178–182.
[5] J. Rutkowska, “Introducing blue pill,” _The official blog of the
invisiblethings.org_, vol. 22, p. 23, 2006.
[6] S. Embleton and S. Sparks, “SMM rootkits,” in _Proceedings of the 4th
International Conference on Security and Privacy in Communication Networks,
Securecomm_, 2008, vol. 8.
[7] J. Rutkowska, “Intel x86 considered harmful,” _the Invisible Things Lab_,
2015.
[8] K. Nohl and J. Lell, “BadUSB – on accessories that turn evil,” _Black Hat
USA_, 2014.
[1] Disclaimer for reasons of transparency: Guenter Schaefer is primarily
serving as full professor at Technische Universität Ilmenau. Furthermore, he is
also member of the supervisory board of secunet Security Networks AG.
========= GERMAN VERSION ==============
SICHERHEITSHINWEIS
MEHRERE SICHERHEITSLÜCKEN 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
- Veröffentlicht am: 13.06.2018
Die aktuellste Version des Dokuments ist unter
https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/advisory-de.html erhältlich.
1. Überblick
Der Ecos Secure Boot Stick soll auch aus unsicheren Umgebungen heraus einen
sicheren Zugriff auf Terminalserver und Webservices bieten. Dazu wird in einem
herkömmlichen PC, über den keine speziellen Annahmen getroffen werden, vom
USB-Stick ein Betriebssystem gebootet. Der Hersteller schreibt: "Der ECOS SECURE
BOOT STICK ermöglicht einen hochsicheren Zugang zu einer Terminalserver- oder
Virtual-Desktop-Infrastruktur und Webanwendungen aus einer gesicherten Umgebung
heraus."
Referenzkunden sind deutsche Behörden, Banken, Versicherungen und Krankenhäuser.
Die Zahlen auf der Webseite lassen darauf schließen, dass einige Tausend SBS im
Umlauf sind. Dieses Dokument beschreibt eine Reihe von Schwachstellen, die bei
einer Sicherheitsuntersuchung des Boot Sticks und der dazugehörigen Management
Appliance entdeckt wurden. Alle gefundenen Schwachstellen führen 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 Schlüsselmaterial.
Hinweis: Es werden keine Aussagen zur Vollständigkeit der Analyse gegeben.
Insbesondere können möglicherweise andere Schwachstellen existieren, die ein
höheres Risiko darstellen. Es wurde unsererseits weder eine systematische
Bedrohungsanalyse durchgeführt, noch wurden Sicherheitsanforderungen abgeleitet.
Stattdessen wird über die vom Hersteller formulierten Sicherheitsaussagen und
-maßnahmen sowie allgemein anerkannte Prinzipien (beispielsweise sollten private
Schlüssel nicht auslesbar sein) argumentiert.
In der Zwischenzeit wurden neue [SE]- und [SX]-Versionen des Produktes auf den
Markt gebracht und durch das Bundesamt für Sicherheit in der Informationstechnik
zum Schutz von VS-NfD-Daten zugelassen. Diese beiden Versionen standen uns für
Tests nicht zur Verfügung. Aus diesem Grund können wir keine Aussage darüber
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-öffentliche) Bedingungen knüpfen, die Risiken
mitigieren.
2. Beschreibung der Schwachstellen und mögliche Gegenmaßnahmen
1. Aktivierter root-Nutzer mit SSH-Zugang im Ecos System Management
Die System Management Appliance enthält einen aktivierten root-Nutzer, dem
SSH-Zugang erlaubt wird. Die Passwortdatei /etc/shadow zeigt außerdem, dass ein
Passwort für den Nutzer gesetzt ist. Die Datei selbst wird während der
Installation der Appliance von einem Ecos-Server heruntergeladen. Somit
kontrolliert Ecos das Passwort für den administrativen Zugang. Möglicherweise
werden hierbei von Ecos für unterschiedliche Kunden verschiedene Passwörter
gesetzt, da in die Download-Anfrage der Lizenzschlüssel 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 Rekapitulation:_
a. Installation des Ecos System Management in einer virtuellen Maschine
b. Öffnen des Festplatten-Images in einem externen Betriebssystem
c. Überprüfung, dass die Datei /usr/msrc/certs/shadow.new existiert und einen
Hash für das Passwort des root-Nutzer enthält
d. Setzen des Passwort-Hashes für 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 Möglichkeit den root-Nutzer als Hintertür zu
verwenden und kann sich bei direkter Netzkonnektivität jederzeit in die
Appliance einloggen.
- Der Hersteller kann geheime Konfigurationsparameter, wie private Schlüssel
und Passwörter, abrufen.
- Der Hersteller kann sicherheitskritische Konfigurationsparameter verändern,
etwa ein unsicheres Verschlüsselungsschema aktivieren oder VNC-Logins auf
den SBS aktivieren.
- Falls der Hersteller jemals selbst von einem Sicherheitsproblem betroffen
sein sollte, beispielsweise durch einen gekündigten Mitarbeiter oder eine
Software-Schwachstelle, könnten weitere Parteien das Passwort erhalten.
- Falls dasselbe Passwort für alle Kunden der Appliance verwendet wird:
- Ein Angreifer könnte durch einen Brute-Force-Angriff Kenntnis des
Passworts erhalten und Zugriff auf andere Installationen erhalten.
- Falls das Passwort je verwendet werden sollte, könnte es durch einen
Man-in-the-Middle-Angriff in die Hände eines Angreifers gelangen, der es
für eigene Zwecke missbrauchen kann.
_Mögliche Gegenmaßnahmen:_
Ein Angriff kann durch einen der folgenden Schritte verhindert werden:
- Das Passwort kann durch ein extern gebootetes System geändert werden. Dieser
Schritt erfordert unter Umständen die Abschaltung des Update-Systems, um
sicher zu stellen, dass diese Änderung nicht rückgä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
für Port 22 unterbunden werden. Der SSH-Prozess auf Port 909 scheint den
Zugriff durch "root" bereits deaktiviert zu haben.
2. Easy Enrollment empfänglich für Man-in-the-Middle-Angriffe
Das Easy Enrollment erlaubt es Nutzern ihren SBS (im Auslieferungszustand) über
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
gegenüber 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_ überprüft
wird, können 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 ausführen, die auch bei einem legitimen
Enrollment geschieht. Er kann den Prozess auch jederzeit abbrechen, um den
Code aktiviert zu lassen. Der Angriff kann transparent für den
Nutzer erfolgen.
- Der SBS des Nutzers kann durch den Angreifer impersonifiziert werden.
_Mögliche Gegenmaßnahmen:_ Easy Enrollment darf nur innerhalb von
vertrauenswürdigen Netzen durchgeführt werden. Beim Einsatz von Smartcards
könnte 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 darüber eine Reihe von HTTP-Anfragen an den Server. Die Antworten enthalten
alle Dateien, die für ein initiales Bootstrapping erforderlich sind,
beispielsweise private und öffentliche SSH-Schlüssel des SBS. Diese werden für
spätere SSH-Verbindungen verwendet. Nach Abschluss des initialen Downloads wird
der Activation Code aus der Datenbank gelöscht.
Ein Angreifer kann einen Activation Code jedoch auch für beliebige
SSH-Port-Weiterleitungen auf dem Management benutzen. Dadurch ist es ihm möglich
sich auf Ports zu verbinden, die durch Binden an 127.0.0.1 ausschließlich
innerhalb des Managements zur Verfügung stehen sollten. Die zentrale CouchDB des
Managements akzeptiert Anfragen auf Port 5984 und kann dazu gebracht werden die
Nutzerkonfigurationen _beliebiger_ Sticks und Nutzer auszugeben. Zusätzlich muss
der Angreifer den Activation Code nicht löschen, 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 gültigen Activation Code erhält
(Passphrase bietet durch geringe Entropie keinen Schutz) oder der einen
erfolgreichen Man-in-the-Middle-Angriff durchgeführt hat, kann die privaten
Schlüssel _aller_ Nutzer kompromittieren.
- Der Angreifer kann die Management Datenbank verändern und etwa einen
VNC-Server mit schwachem Passwort auf einigen SBS aktivieren.
- Möglicherweise können weitere private Dienste oder gar andere Hosts
zugänglich sein (wurde unsererseits nicht näher untersucht).
_Mögliche Gegenmaßnahmen:_ Easy Enrollment darf nur innerhalb von
vertrauenswürdigen Netzen durchgeführt werden (insbesondere nicht über das
Internet), beispielsweise durch Blockieren von Port 909 (mit Seiteneffekten, da
auch andere Management-Komponenten erreichbar sind).
4. Schlüsselmaterial zugreifbar nach Hardware-Reset von SBS
Ecos erklärt: "Die Nutzung des Sticks hinterlässt keinerlei Spuren, womit es
ausgeschlossen ist Rückschlüsse auf Verbindungsdaten oder Arbeitsdaten zu
nehmen."
Trotz dieser Aussage verbleibt nach einem harten Neustart des PCs (z.B. durch
Betätigen des Reset-Knopfs) während der Ausführung des SBS vertrauliches
Schlüsselmaterial im Speicher zurück. Ein kompromittiertes Betriebssystem auf
dem Hostrechner kann anschließend dieses Schlüsselmaterial aus dem
"uninitialisierten" Hauptspeicher lesen. Dies kann beispielsweise auch bei
folgendem Arbeitsablauf passieren: Ein Nutzer resettet das OS eines Ecos SBS
versehentlich, arbeitet weiter, fährt seine Ecos-SBS-Sitzung sauber herunter und
bootet in ein kompromittiertes OS. Der Speicher der ersten (abgebrochenen)
Ecos-Sitzung wird dabei nicht notwendigerweise vollständig von der zweiten
überschrieben.
_Schritte zur Rekapitualtion:_
a. Übersetzen und installieren des _RAM imaging utility_ von
https://github.com/dbrant/bios_memimage
b. Reset während das Betriebssystem des Ecos SBS läuft
c. Extraktion von Langzeit- und Sitzungsschlüsseln aus dem
erzeugten Speicherabbild. In Abhä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 Schlüsselmaterial
erhalten, welches durch den SBS gesichert werden sollte. Dies beinhaltet:
- Private Schlüssel um Sticks gegenüber dem Management zu authentisieren
- Private Schlüssel um Sticks gegenüber VPN-Konzentratoren oder Webseiten
zu authentisieren
- Sitzungsschlüssel die beispielsweise VPN-Verbindungen oder
Terminal-Server-Sitzungen schützen
- Symmetrische Schlüssel, welche die Stick-"Firmware" und
Nutzerkonfiguration sichern
- Angreifer können dieses Szenario bewusst hervorrufen, um Schlüsselmaterial
aus dem Stick zu extrahieren
- Angreifer können die Nutzerkonfiguration aus dem Stick extrahieren oder
diese auch manipulieren (siehe Schwachstellen 8 & 10).
_Mögliche Gegenmaßnahmen:_ Nach einem Neustart müssen Nutzer den PC vollständig
und für mehrere Sekunden vom Strom trennen, um sicherzustellen, dass der
Speicher seinen Zustand verloren hat. Bei Nutzung von älteren RAM-Typen muss der
PC unter Umständen eine längere Zeit vom Strom getrennt werden. Geräte, die
nicht sicher ausgeschaltet werden können, etwa weil die Akkus nicht zu entfernen
sind, sollten nicht verwendet werden. Langzeitgeheimnisse können möglicherweise
durch den Einsatz einer externen Smartcard besser geschützt 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 (wörtlich
"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 geschützt, da aktuelle
Generationen von USB-Speicher-Sticks schlicht über keine feste "Hardware-ID"
verfügen. Ein Angreifer kann Parameter wie die Vendor- und Product-ID sowie die
Seriennummern auf allgemein verfügbaren Speicher-Sticks frei ändern [3]. Ein
Angreifer beziehungsweise eine bösartige Software muss anschließend 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 könnte über das Internet übertragen
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 können 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 können "Backups" von bestimmten Stick-Konfigurationen erstellen
und den entsprechenden Zustand wiederherstellen falls diese zentral
verändert oder der SBS eingezogen wurde (beispielsweise nach Beendigung
eines Dienstverhältnisses).
_Mögliche Gegenmaßnahmen:_ Nutzer sollten den SBS nicht in Geräten verwenden,
deren Hard- und Software nicht in vollen Umfang vertraut werden kann. Dies
schließt möglicherweise 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 näher untersucht. Starke
Bootpasswörter können den "ersten Faktor" stärken, sodass der physische Besitz
des Sticks weniger relevant für 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 Sicherheitsmaßnahme vorzuziehen.
6. SBS kann in virtueller Maschine verwendet werden
Erklärung des Herstellers: "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."
Die Entwicklung guter Erkennungsstrategien einerseits und die Verbesserung von
VMs zur Vermeidung einer solchen Erkennung andererseits ist ein fortwährender
Wettlauf -- unter anderem zwischen Virenautoren und Antivirusherstellen. Aus
theoretischer Sicht ist eine Erkennung einer virtualisierten Umgebung nicht
unter allen Umständen zu garantieren. Allerdings kann es aus praktischer Sicht
vergleichsweise schwierig sein eine solche Virtualisierungsumgebung zu
implementieren (siehe z.B. [4]).
Dies führt zur Frage wie sich die Schutzmaßnahmen des SBS in diesem
Spannungsfeld einordnen. Fehlermeldungen während des Bootvorgangs deuten darauf
hin, dass die Erkennung ein Teil der kryptographischen Schutzmechanismen ist.
Zeichenketten in der verantwortlichen Executable zeigen verblüffende
Ähnlichkeiten 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
bösartige Angriffe zu bestehen, so dass es nicht überrascht, dass ein
unmodifiziertes KVM einfach instruiert werden kann einen SBS in einer VM zu
booten. Es genügt 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 führen kann:
1. Ein legitimer Benutzer virtualisiert eigeninitiativ, etwa aus Bequemlichkeit
oder weil er ein Bildschirmfoto machen möchte. Gerade Letzteres sollte laut
Herstelleraussage unmöglich sein: "Das Erstellen, Abspeichern, Drucken oder
Weiterleiten von Bildschirmkopien wird über eine sichere Zugangslösung
verhindert."
2. Der Nutzer weiß nicht, dass sein System virtualisiert betrieben wird. Wie
bereits vor mehr als 10 Jahren demonstriert wurde, ist es bösartiger
Software möglich, dass eigentliche Betriebssystem in einer VM auszuführen,
um die eigene Anwesenheit zu verbergen [5]. Auch für einen dediziert
gebooteten SBS sind verschiedene nutzertransparente Virtualisierungsangriffe
denkbar. Beispiele sind:
- Ein kompromittiertes Betriebssystem verä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, fä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 bösartige Software modifiziert den SBS, sodass er immer in einer VM
bootet (siehe Schwachstelle 10, warum dies möglich ist).
Ein virtualisiertes Ecos-SBS-System kann jederzeit vollständig überwacht und
modifiziert werden. Das bedeutet ein Angreifer ist in der Lage:
- Nutzerverhalten, Sitzung-, Langzeitschlüssel, PINs und Passwörter
aufzuzeichnen. Das heißt der Angreifer kontrolliert _beide_ Teile
der Zweifaktorauthentisierung.
- Er kann laufende Programme, das SBS-Betriebssystem und involvierte
Daten verändern.
- Alle extrahierten Daten können unter Umgehung der SBS-eigenen Firewall über
das Netzwerk versendet werden, sodass ein Angreifer keinen physischen
Zugang benötigt.
Zusammenfassend können keinerlei Sicherheitsziele garantiert werden, falls
Virtualisierungsangriffe nicht effektiv verhindert werden können.
_Mögliche Gegenmaßnahmen:_ Nutzer dürfen den SBS nicht in Geräte einstecken, die
unvertrauenswürdige Hard- oder Software enthalten könnten. Administratoren
müssen sich bewusst sein, dass Nutzer Virtualisierung verwenden, um ihre Sticks
zu betreiben. Falls den Nutzern nicht vollständig vertraut werden kann, kann der
SBS nicht sicher eingesetzt werden.
7. SBS ist anfällig für Hintertüren in Firmwares der Hardware
Der Hersteller erklärt: "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."
Diese Aussage ist recht überraschend, denn sie widerspricht:
- Früheren 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 freiverfügbare UEFI-Hintertür
von https://github.com/Cr4sh/SmmBackdoor leicht modifiziert. So wurde
beispielsweise eine einfache Speicherersetzungsstrategie implementiert, die es
erlaubt IPsec-Sitzungsschlüssel auf portable Art und Weise zu extrahieren und
über 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 genügt das Ausführen einer Datei mit einem
Administrator-Account in einer unmodifizierten Windows-Installation. Dafür wurde
ein aktuelles UEFI von der offiziellen MSI-Webseite bezogen, mittels eines
https://github.com/LongSoft/UEFITool modifiziert und anschließend mit dem
offiziellen MSI BIOS Upgrade Tool aufgespielt. Der Ansatz ist hochgradig
flexibel, da das veränderte UEFI beispielsweise über 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 Schlüsselmaterials nicht
verhindern. Ein Angreifer ist in der Lage, IPsec-Schlüssel auszuleiten und eine
gekapselte RDP-Session in Echtzeit abzuhören.
_Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/smmBackdoor.mp4
Durch Speichermanipulationen ist es ebenfalls möglich, Programmcode im SBS zur
Laufzeit zu verändern. Zur Demonstration wurde der login-Prozess verändert,
sodass er eine Root-Shell öffnet. Andere Veränderungen sind selbstverständlich
ebenfalls möglich.
_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 verändern ohne dass dies durch eine
Software festgestellt werden kann.
- Es können Daten, wie Sitzungs-, Langzeitschlüssel, Passwörter und PINs aus
Haupt- und Massenspeichern gelesen werden.
- Jegliche Art einer lokalen Firewall kann umgangen werden, um Informationen
über das Netz zu senden.
Zusammenfassend können keinerlei Sicherheitsziele garantiert werden, falls die
Firmware einer Hardware kompromittiert wurde auf der ein SBS ausgeführt wird.
_Mögliche Gegenmaßnahmen:_ Nutzer dürfen den SBS nicht in Geräte einstecken, die
unvertrauenswürdige Hard- oder Software enthalten könnten.
8. Konstruktion der Trust-Chain adressiert Problemstellung ungenügend
Ecos bewirbt die UEFI-Secure-Boot-Unterstützung als ein Sicherheitsmerkmal.
Weiterhin geben sie an: "In einer »Chain-of Trust« überprüfen 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 Integrität und Authentizität des gestarteten
Betriebssystems verifizieren muss, sondern dass das Betriebssystem in der Lage
sein müsste 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 Überprüfungen 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 Umständen
garantiert verhindern:
- Das UEFI und anderen Hardware-Komponenten sind nicht kompromittiert (siehe
vorhergehende Schwachstelle)
- Der Hersteller hat die Hoheit über alle in den Geräten installierten
UEFI-Schlüssel und stellt sicher, dass nur der eigene Bootloader startet.
Aktuell hat Microsoft die Hoheit über diese Schlüssel 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 vertrauenswürdige Instanz) verhindert das
Booten der Umgebung, falls die Hardware nicht über einen UEFI-Secure-Boot
unter den obigen Bedingungen verfügt.
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 tatsächlich aktiven
Bootloader). Auch diese Authentisierung geschieht nur an zwei Stellen; wir
werden uns im Folgenden auf die ausgeklügeltere konzentrieren. Hierbei geht der
gestartete Kernel in den Prozess zur Entschlüsselung des SBS-Dateisystems mit
ein. Ein tatsächliches Ausnutzen der ungenügenden vom UEFI-ausgehenden
Vertrauenskette wird im Rahmen von Schwachstelle 10 vorgestellt.
Um Schlüsselmaterial abzuleiten, mit dem auf die verschlüsselten Teile des SBS
zugegriffen werden kann, misst der initiale Userland-Prozess (das ì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
"Entschlüsselungsfehler", wenn Änderungen detektiert werden. Das heißt
Modifikationen an der Bootkette, z.B. durch vorheriges Starten eines Programms,
ändern die Messung und Modifikationen an später aktivierten Komponenten
scheitern, da diese Teile verschlüsselt und authentisiert sind. Ein Angreifer
könnte den Maschinencode der involvierten Executables analysieren, aber es
existiert ein weit bequemerer und flexiblerer Weg: Fortschritte bei der
Entwicklung von Sandboxing-Umgebungen können genutzt werden, den Prozess der
Schlüsselgenerierung kontrolliert auszuführen. Beispielsweise kann
https://usercorn.party verwendet werden, um alle Syscalls abzufangen,
gegebenenfalls zu modifizieren oder zu unterdrücken. Unter Nutzung dieser
Technik kann exakt kontrolliert werden, welche Informationen der Prozess erhält
und welche verborgen bleiben sollen. Zum Beispiel kann der Signaturprüfung
einfach ein anderes Image gegeben werden, als das welches später eingebunden
wird. Falls der Nutzer kein Bootpasswort gesetzt hat, können auf diese Weise
direkt alle Geheimnisse, die im SBS gespeichert sind, extrahiert werden.
Um ein vorzeitiges Abbrechen der Emulation zu verhindern, müssen weitere
Syscalls in usercorn abgefangen werden. Dabei ist es jedoch hinreichend dem
aufrufenden Prozess eine erfolgreiche Ausführung durch einen geeigneten
Rückgabewert zu signalisieren. Eine eigentliche Implementation der Syscalls ist
nicht erforderlich.
Die Verwendung von usercorn ist allerdings nicht die einzige Möglichkeit den
Kontrollfluss bei der Schlüsselgenerierung zu steuern. Zumindest die folgenden
fünf Ansätze sind denkbar:
1. Die Argumente, die der init-Prozess dem Linux-Kernel übergibt, könnten in
einem modifzierten Linux-Kernel vor der Ausführung geändert werden.
Beispielsweise könnte der gestartete Prozess geeignet markiert werden, und
beim Lesen von Dateien wie /proc/keys einfach den Inhalt einer anderen
Datei erhalten.
2. Syscall-Argumente können auch zur Laufzeit durch ptrace und seccomp
verä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 können anschließend die Argumente der Syscalls vor jeder
Ausführung verändert werden.
4. Eine String-Analyse des init-Programms legt die starke Vermutung nahe, dass
es GPL-lizensierten Programm-Code enthält, wodurch das komplette Programm
dieser Lizenz unterliegen würde. Der Hersteller wäre in diesem Fall
verpflichtet, jedem Nutzer den vollständigen Programm-Code zugänglich zu
machen, den dieser modifizieren und weitergeben könnte. Ein Angreifer könnte
mittels des auf diese Weise beschafften Codes ein eigenes, beliebig
modifiziertes init-Programm erzeugen.
5. Es ist möglich, spezifische Teile der init-Binary durch Analyse und
Veränderung des Maschinencodes in ihrem Verhalten zu modifizieren.
Beispielsweise können Signaturprüfungen übersprungen 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 Schlüssel.
- Falls ein Bootpasswort gesetzt wurde, kann ein Angreifer Passwörter durch
die Emulation automatisch durchprobieren lassen. Falls das Bootpasswort
nicht ausreichend Entropie besitzt können 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 für das Ausnutzen der folgenden Schwachstellen.
_Mögliche Gegenmaßnahmen:_
Die Folgenden drei Maßnahmen wirken nur in Kombination:
- Die Bootpasswörter dürfen nicht für Bruteforce-Angriffe empfänglich sein.
- Die Nutzer müssen sicherstellen, dass sie tatsächlich von einem angesteckten
Stick booten (PC abschalten, wieder anschalten im BIOS die Bootreihenfolge
überprüfen), da ein kompromittiertes Betriebssystem die SBS-Umgebung einfach
vortäuschen könnte. Dabei könnte es auch das Bootpasswort abfragen, indem
der initiale Prozess in einer Sandbox ausgeführt wird.
- Es dürfen ausschließlich USB-Sticks mit einem hardware-seitigen
Schreibschutz genutzt werden (Details folgen in Schwachstelle 10). Der
Schreibmodus darf lediglich in vollständig vertrauenswürdigen Umgebungen
aktiviert werden.
9. Aktivierter SSH-Zugang für vorkonfigurierten root-Nutzer im Ecos SBS
Unter Nutzung der Entschlüsselungsmethode ist es nicht nur möglich, 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 für alle unterschiedlichen
Bootmethoden gleich ist. Diese Konfiguration ist nicht durch das Bootpasswort
geschützt und kann daher in jedem Fall extrahiert werden. Das Verzeichnis
enthält unter anderem eine verschlüsselte 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 tatsächlich um einen Zugang handelt, der vom Hersteller
auch über SSH genutzt werden könnte, wird im Zuge der nächsten Schwachstelle
demonstriert.
_Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/sbsRootAccess.mp4
_Potentielle Implikationen:_
- Der Hersteller hat die Möglichkeit den root-Nutzer als Hintertür 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 enthält das "gehärtete" Linux-Betriebssystem
des SBS sogar einen NTFS-Dateisystem-Treiber, der über SSH genutzt
werden kann.
- Der Hersteller kann vertrauliche Konfigurationsparameter, wie private
Schlüssel und Passwörter, einsehen.
- Der Hersteller kann die Konfiguration des Sticks verändern, z.B. auf ein
unsicheres Verschlüsselungsschema wechseln.
- Falls der Hersteller jemals selbst von einem Sicherheitsproblem betroffen
sein sollte, beispielsweise durch einen gekündigten Mitarbeiter oder eine
Software-Schwachstelle, könnten weitere Parteien das Passwort erhalten.
- Falls dasselbe Passwort für alle Kunden verwendet wird:
- Ein Angreifer könnte durch einen Brute-Force-Angriff Kenntnis des
Passworts erhalten und Zugriff auf andere Installationen erhalten.
- Falls das Passwort je verwendet werden sollte, könnte es durch einen
Man-in-the-Middle-Angriff in die Hände eines Angreifers gelangen, der es
für eigene Zwecke missbrauchen kann.
_Mögliche Gegenmaßnahmen:_ Der SBS darf nicht in Szenarien eingesetzt werden in
denen ein Zugriff auf den SSH-Dienst möglich ist.
10. Daten des SBS können bösartig verändert werden
Herstelleraussage: "Schreibgeschützte Partition für Firmware und Applikationen"
Technisch sauberer ist die Aussage, dass unautorisierte Modifikationen am Stick
-- etwa durch Signaturüberprüfungen -- erkannt werden. Allerdings ist auch diese
relaxierte Aussage nicht in jedem Fall aufrecht zu erhalten, wie anhand der
folgenden drei Szenarien diskutiert wird.
Vollständiges Überschreiben des SBS
Der SBS ist hardware-seitig ein völlig gewöhnliches USB-Speichermedium. Ein
kompromittiertes Betriebssystem könnte den Inhalt des gesamten Stick also
vollständig überschreiben, wenn der Nutzer den Stick einsteckt während das OS
noch aktiv ist. Beispielsweise könnte es ein minimales OS auf dem Stick
platzieren, welches nach dem Booten sofort alle Massenspeicher absucht und
darauf vorhandene Betriebssysteme infiziert. Danach könnte es ein Ecos Logo mit
der Fehlermeldung "Ihr PC wird nicht unterstützt, bitte verwenden Sie den SBS in
einem anderen PC" zeigen.
Dieser Ansatz könnte es einem Angreifer erlauben, Malware von einem
Heimarbeitsplatz auf einen PC innerhalb eines Firmennetzes zu verbreiten.
Missbrauch des root-Nutzers
Wie bereits erwähnt ist zwar die sogenannte "Firmware", also die eigentliche
Arbeitsumgebung des SBS, durch eine Signatur geschützt, die Stick-Konfiguration
jedoch nur über einen von außen zu berechnenden symmetrischen
Authentisierungswert. Das bedeutet, dass das Schlüsselmaterial welches zur
Entschlüsselung verwendet wurde (siehe Punkt 8) auch dazu verwendet werden kann
die Konfiguration zu verändern; möglicherweise ohne dass diese Modifikation
erkannt wird. Die Stick-Konfiguration kann dabei selbst dann verändert werden,
wenn das Bootpasswort _nicht_ bekannt ist. Das bedeutet, die im Rahmen der
letzten Schwachstelle beschriebene shadow-Datei kann verändert und so ein
eigenes root-Passwort gesetzt werden. Eine Hürde 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 präsent zu
sein und enthä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 über SSH auf den SBS zugreifen,
unabhängig davon auf welchem Computer dieser gebootet wurde (sofern
SSH-Netzwerkzugriff gegeben ist). Über die SSH-Sitzung können
Langzeitgeheimnisse, Sitzungsschlüssel und Daten von der privaten Festplatte des
Nutzers abgegriffen werden (der SBS enthält hierzu bereits einen
NTFS-Dateisystem-Treiber). Zum Teil können diese auch modifiziert werden.
Außerdem enthält das "gehärtete" Betriebssystem auch ein Werkzeug um Screenshots
von der aktiven Nutzersitzung zu machen (/bin/xwd) und einen funktionsfähigen
VNC-Server, sodass es möglich ist den Nutzer live zu beobachten oder sogar mit
der Sitzung zu interagieren. Passives Beobachten wird dem SBS-Nutzer gegenüber
nicht angezeigt (falls der Angreifer dies nicht explizit möchte).
_Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/stickMod1.mp4
Selektives Modifizieren ausführbarer Dateien auf dem SBS
Auch ohne Ausnutzen des schwach geschützten Teils der Konfiguration ist es
möglich den Stick auf geschickte Art zu modifizieren. So ist es möglich
Signaturüberprüfungen vollständig zu entfernen und den Stick mit einer Hintertür
zu versehen, die beispielsweise andere Betriebssysteme infiziert und den SBS als
Wirt benutzt. Dazu können die initialen Signaturüberprüfungen durch einen
eigenen Bootloader (mit Ecos-Theme) und Kernel ausgehebelt werden. Durch einen
modifizierten Kontrollfluss während des init-Prozesses, fällt dies, ebenso wie
eine Veränderung des squashfs-Dateisystems, nicht auf. Im Rahmen von
Schwachstelle 8 wurden verschiedene Wege beschrieben mit denen eine solche
Veränderung des Kontrollflusses erreicht werden kann.
Es verbleiben die Überprüfungen 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 Sicherheitsüberprüfung überhaupt auszulösen, da sie auf
einer (sehr kleinen) Whitelist zu basieren scheint. Von den 663 Dateien im
/bin-Verzeichnis des "gehärteten" Betriebssystems scheint dies nur auf eine
Handvoll zuzutreffen. Es ist daher sehr einfach diesen Schutzmechanismus zu
umgehen. Für Demonstrationszwecke wurde das Werkzeug /bin/insmod im Ecos-OS
ausgetauscht, um eine Windows-Installation zu infizieren. Die Datei wird
regelmäßig ausgeführt und ist nicht durch die Whitelist geschützt.
_Video:_ https://telematik.prakinf.tu-ilmenau.de/ecos-sbs/stickMod2.mp4
Diskussion bösartiger Veränderungen
_Potentielle Implikationen:_ Die Auswirkungen dieser Schwachstelle hä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 übertragen. Möglicherweise könnten so weitere SBS infiziert werden.
- Der Angreifer kann Daten vom privaten Massenspeicher des PCs sowie
Konfigurationsparameter, Passwörter und private Schlüssel vom SBS auslesen
(ohne ein möglicherweise starkes Bootpasswort zu kennen).
- Der Angreifer kann den init-Prozess verändern, sodass das Bootpasswort oder
die Smartcard PIN aufgezeichnet werden (falls er diese an anderer
Stelle benötigt).
- 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 selbstständig eine Kommunikation initiieren, etwa zu
einem zentralen Command-and-Control-Server.
- In Abhängigkeit von den Fähigkeiten des Angreifers können alle aufgezählten
Angriffe verdeckt ablaufen, das heißt der Nutzer ist nicht in der Lage diese
zu erkennen, da funktionale Aspekte des SBS weiterhin gewährleistet sind.
_Mögliche Gegenmaßnahmen:_
Nutzer dürfen den SBS nicht in Geräte einstecken, die unvertrauenswürdige Hard-
oder Software enthalten könnten. 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
Broschüren zumindest aktuell nicht zu halten sind. Dies umfasst:
- "Die Nutzung des Sticks hinterlässt keinerlei Spuren, womit es
ausgeschlossen ist Rückschlüsse auf Verbindungsdaten oder Arbeitsdaten zu
nehmen.", Schwachstelle 4
- "Zertifikat, gekoppelt an die Hardware-ID des Sticks", Schwachstelle 5
- "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.", Schwachstelle 6
- "Das Erstellen, Abspeichern, Drucken oder Weiterleiten von Bildschirmkopien
wird über eine sichere Zugangslösung verhindert.", Schwachstellen 6 und 9
- "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.", Schwachstelle 7
- "In einer »Chain-of Trust« überprüfen 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
- "Schreibgeschützte Partition für 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
Außerdem, wurden mögliche Herstellerhintertüren, eine Schwachstelle gegen
Man-in-the-Middle-Angriffe und die Möglichkeit aufgedeckt, die interne
Management-Datenbank auszulesen, inklusive aller privaten Schlüssel assoziierter
SBS.
Einige dieser Schwachstellen mögen auf einfache Nachlässigkeiten zurückzuführen
sein, etwa die aktivierten root-Nutzer oder die Möglichkeit die Datenbank zu
spiegeln. Ein großer Anteil basiert jedoch auf konzeptionellen Fehlern. Von
diesen könnten 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 können nach Meinung der
Autoren nicht ohne zusätzliche hardware-seitige Fähigkeiten oder die
ausschließliche und exklusive Nutzung vertrauenswürdiger Hardware behoben
werden.
Aus makroskopischer Sicht sind die beschriebenen Schwachstellen ebenfalls
interessant, da sie zeigen wie wenig verlässlich punktuelle IT-Sicherheitstest
bei Einführung eines Produktes sind. Die meisten Referenzkunden, die von Ecos
angeführt werden, gaben an, dass sie interne oder externe Sicherheitstests
durchgeführt haben. Die Empfehlungen implizieren, dass dabei keinerlei
schwerwiegende Fragen bezüglich der Sicherheit aufgekommen sind.
Die Analyse unsererseits erstreckte sich über einen Zeitraum von ungefähr einem
Monat und wurde neben unseren eigentlichen Forschungsprojekten durchgeführt.
Professionelle Pentester werden vermutlich weniger Zeitressourcen haben, sodass
sie die verschiedenen kryptographischen Verschleierungsschichten nicht
durchdringen können. Selbst unser weniger beschränkter Zeitplan erlaubte keine
vollständige Überprüfung 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
dürfen nicht als sicher angenommen werden.
- USB-Geräten darf nur unter sehr strenge Auflagen vertraut werden ([8]
enthält einen weiteren Angriffsvektor).
Selbst der einfache BSI IT-Grundschutz enthält in Abschnitt M 4.63 die
Anforderung "Der Telearbeitsrechner sollte über einen Boot-Schutz verfügen, um
zu verhindern, dass unbefugt von auswechselbaren Datenträgern, z.B. von DVD oder
USB-Stick, gebootet werden kann." Es existieren jedoch keine
Hardware-Mechanismen, die zusichern könnten, dass nur authentische Sticks
gebootet werden können. 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 führte Guenter Schaefer[1].
Fragen und Anmerkungen können 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 Veröffentlichung
- 13. April 2018 - Hersteller informiert
- 30. April 2018 - BSI lässt [SX] und [SE] Varianten des Sticks zur
Verarbeitung von VS-NfD-Daten zu
- 13. Juni 2018 - Veröffentlichung
6. Referenzen
[1] J. Bauer, M. Gruhn, und F. C. Freiling, „Lest we forget: Cold-boot attacks
on scrambled DDR3 memory“, _Digital Investigation_, Bd. 16, S. S65–S74, 2016.
[2] S. F. Yitbarek, M. T. Aga, R. Das, und T. Austin, „Cold boot attacks are
still hot: Security analysis of memory scramblers in modern processors“, in
_High performance computer architecture (HPCA), 2017 IEEE international
symposium on_, 2017, S. 313–324.
[3] G. Ravago, „Reverse engineering a USB flash drive“. 2015.
[4] A. Sergeev, V. Minchenkov, und V. Bashun, „Malicious hypervisor and hidden
virtualization of operation systems“, in _Application of information and
communication technologies (AICT), 2015 9th international conference on_, 2015,
S. 178–182.
[5] J. Rutkowska, „Introducing blue pill“, _The official blog of the
invisiblethings.org_, Bd. 22, S. 23, 2006.
[6] S. Embleton und S. Sparks, „SMM rootkits“, in _Proceedings of the 4th
International Conference on Security and Privacy in Communication Networks,
Securecomm_, 2008, Bd. 8.
[7] J. Rutkowska, „Intel x86 considered harmful“, _the Invisible Things Lab_,
2015.
[8] K. Nohl und J. Lell, „BadUSB – on accessories that turn evil“, _Black Hat
USA_, 2014.
[1] Transparenzerklärung: Guenter Schaefer arbeitet Vollzeit als Professor an
der Technischen Universität Ilmenau. Weiterhin ist er nebenberuflich ein
Mitglied des Aufsichtsrats der secunet Security Networks AG.
Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
Powered by blists - more mailing lists