# Riverbed RiOS insecure cryptographic storage (CVE-2017-5670)

## Description

Riverbed Steelhead hardware appliances are used to optimize and
accelerate network traffic.
There can be implemented as TLS endpoints, so they have a secure vault
aimed to store private TLS certificates for servers.
The secure vault has FIPS mode support.

## Improper encryption implementation

The secure vault used on the Steelhead appliance (and potentially other
that we could not test) is not efficient in its default form, because of
the lack of boot loader security.

**Threat**

An adversary can boot an appliance and recover all private keys of the
server certificates that are configured on it. It may happen in various
situation (subcontractors, hardware decommissioning, etc.).

**Expectation**

With proper encryption (FDE) and sanitization procedures, certificates
should be unrecoverable, as quoted from the documentation:

> Since the information is only in memory, when an appliance is rebooted
or powered off, the information is no longer available".

**CVE ID**: CVE-2017-5670

**Access Vector**: local

**Security Risk**: medium

**Vulnerability**: CWE-310, CWE-321

**CVSS Base Score**: 7.1

**CVSS Vector**: CVSS:3.0/AV:P/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L

### Defeating system encryption with anonymous console access

We followed the steps below to take over the appliance and recover
private keys from the file system, with zero knowledge of the appliance
and its configuration :

**1/** Connect to the appliance in RS232.

**2/** Turn on the appliance and edit the Grub line to boot in `single` mode

**3/** Proceed with the boot to get the root shell. But at this stage,
vault decryption has not happened yet.

**4/** Reset the *admin* password, which can be achieved with the
`/sbin/resetpw.sh` script.

**5/** Modify the firmware to replace `/opt/tms/bin/cli` with `bash` :

```
# mount / -o remount, rw
# cd /opt/tms/bin/
# mv cli cli.bask
# cp /bin/bash cli
# reboot
```

**5/** Reboot to now get a full admin access with a `bash` shell.

**6/** Use the `mount` command to confirm that decryption has happened:

```
# mount
encfs on /var/opt/rbt/decrypted type fuse.encfs
(rw,nosuid,nodev,relatime,user_id=0)
# ls /var/opt/rbt/decrypted
available framework notes ssl tmp
```

**7/** Now insert an USB key and retrieve the whole vault. Note that
non-exportable certificates can be extracted without any issue (from
`./decrypted/server_certs/names/NOExportableCA/`).
The exportation is only based on a local file that acts as a flag:

```
# cat /var/opt/rbt/decrypted/server_certs/names/NOExportableCA/exportable
false
```

**8/** Note that encryption is made by the `/sbin/secure_vault.sh`
script, which makes EncFS encryption based on fixed and hard-coded keys:

```
[...]
MAGIC_STRING='This ********* motorcycle'
[...]
PASSWORD="${MAGIC_STRING}_{SERIAL_NUM}
[...]
```

So the passphrase is basically a concatenation of a constant magic
string and the appliance serial number, two pieces of information that
an attacker can easily retrieve.

> With this knowledge, it is trivial to reproduce the decryption on any
Linux computer with EncFS. Thus, it is actually not necessary anymore to
root the appliance to decrypt data, the disk content could be copied
offline.

Several weaknesses lead to the certificate exposure:

- The boot loading chain is not password protected (starting with Grub)
and there is no integrity control, so it is trivial to "root" the appliance.
- File-system level encryption is inefficient for protecting local
storage, especially when the system lacks of integrity protection : the
disk can be accessed and the data can be retrieved while it is decrypted.
- A fixed and hard-coded value is used by the system as an encryption
key. It even makes offline decryption easy.
- Do not claim to encrypt with PBKDF-2 in the documentation. The user
password is used with no derivation.

### A look at the user password mode

In an improved vault encryption mode, the appliance allows the user to
encrypt with its own key.
The documentation advertises that the key is based on PBKDF-2, so we
expect that the encryption to be a hash.

We set this mode and tracked system calls while unlocking a certificate
in the Web interface :

```
# strace -e write -o /tmp/out /opt/tms/bin/mgmtd & 1 > /dev/null 2>&1
[...]
write(19, "Pass123_EC6R*****0\n", 22) = 22
[...]
```

So we found the password that we set for the vault, appended with the
appliance serial number. With this information, we succeeded in
decrypting the vault offline, from another Linux box.

Riverbed advertises that the use of PBKDF-2 makes the password stronger
to prevent brute force attacks (as it is used in EncFS).
However, a poorly chosen pass phrase (in the absence of password policy
enforcement) and a physically readable salt (the serial number on the
appliance) would yet defeat the benefits of EncFS encryption.


## Insecure secure vault deletion

Two scripts are used at different times to delete the secure vault:
`/sbin/secure_vault_clear.sh` and `/sbin/scrub.sh`.

They simply use the `rm` system command to delete the files, as follows:

```
[...]
umount /var/opt/rbt/decrypted
rm -rf /var/opt/rbt/decrypted
rm -rf /var/opt/rbt/encrypted
rm -f /var/opt/rbt/ssl
[...]
```

A better practice would be to use `shred` or `srm` utilities to wipe
files securely.

## Affected versions

RiOS versions prior to 9.0.1 regarding the single boot mode.

Potentially all version regarding secure vault weak encryption and wiping.

### Solution

Sysdream considers that the encryption scheme needs a complete
re-factoring in relevance with the secrets it protects. We believe that
full disk encryption should be implemented, with better boot loader
security features. Default security and clarifications should be
mandatory for this kind of appliance.

As of now, Riverbed advises:

> 1) Ensure physical access is protected
> 2) Keep your software up-to-date
> 3) Set a bootloader password
> 4) Set a BIOS password
> 5) Change the default secure-vault password
> 6) Take proper steps when decommissioning including erasing hard-disk data

We could not verify that all these items can be implemented (for
instance, on our model and RiOS version, no setting allowed to set a
Grub and BIOS password, and the user guide did not mention anything).
So, please refer to your documentation (deployment guide) or support to
check how you can implement these security settings.

## Timeline (dd/mm/yyyy)

* 7/12/2016 Initial discovery
* 11/12/2016    First e-mail contact
* 17/12/2016    Sent all details to Riverbed contact
* 26/01/2017    After several requests to the support, got contact with
the security team. Riverbed position is that customers should put proper
physical protections in place in any case. Also, version 9.0.1 removed
single mode boot.
* 11/02/2017  Disclosure

## Credits

* Jean-Christophe Baptiste, aka phocean, Sysdream (jc.baptiste -at-
sysdream -dot- com)


-- 
SYSDREAM Labs <labs@sysdream.com>

GPG :
47D1 E124 C43E F992 2A2E
1551 8EB4 8CD9 D5B2 59A1

* Website: https://sysdream.com/
* Twitter: @sysdream