Vault CLI security concerns

Vault
1

Hello,

I’ve been testing Hashicorp Vault (non enterprise edition) v1.12.x and came across a security issue when using the cli.

When using the vault login command this will prompt you to enter a token, this can be a user token or the root token generated during the setup process.

Whilst this information is hidden when pasting/typing into a terminal, a hidden file called .vault-token is created inside the home directory of the user account issuing the command.

The file is NOT encrypted and the token used is saved as plain-text, which the vault cli references when issuing commands to retrieve information or modify information stored in the vault database.

Removing the token line from this file will result in 403 errors (permission denied) when re-launching vault cli commands as it can no longer authenticate.

Exiting the current shell does NOT disconnect the authenticated session, nor does it remove/clear the .vault-token file located in the home folder.

SCENARIO

AdminUser1 logged into the Vault server via SSH and uses the vault login option to perform some tasks via the cli, once they’ve completed their tasks, the shell session is terminated and they go about their day.

AdminUser2 logged into the Vault server via SSH to update some packages. This user does not have permission under normal circumstances to access the data stored in Vault. However as the .vault-token file still exists they can easily run vault cli commands or retrieve the saved token to access the webUI as the previous user or root depending on which token was used.

SUGGESTIONS

Add a logout command for vault cli that removes all authentication data.
Add some level of encryption to the .vault-token file (or remove it completely).
When a session is closed the local authentication should be revoked from the server/service.
Add TTL (time-to-live) duration for this type of authentication.

If anyone has found a solution to this or if one already exists, don’t hesitate to reply here :slight_smile:

2

That file is created to allow the token to be used within subsequent CLI commands. You could if you wanted remove that file via your shell logout script. Encrypting the file would destroy the purpose, as it needs to be readable to allow the CLI to use it for commands. The token details it contains will automatically expire - that depends on the lease time you set for the token.

Note this behaviour is pretty normal and similar to other tools such as git or the AWS/Azure CLI.

3

Use vault login -no-store xxxxxxxx , it will not store it locally.

4

Thanks for the reply stuart-c, it’s what I suspected. I’ll look into the shell logout script to find a suitable solution.

5

Thanks for the suggestion tsiamer, the problem is if you use -no-store option which I’ve tried already before you can’t interact with the database as you’re not logged in.

7

The .vault-token is personnal. You must not use a shared account to use the vault CLI. You must use vault CLI from your personnal account via TCP. You don’t need to be logged on the server hosting the Vault.
In my compagny, is it strictly forbbiden to connect on Vault. (And it is not possible without adding someone to an AD group, but Splunk is looking after this changed)