We were doing a security assessment and came across a scenario where a dedicated admin workstation is compromised (Ubuntu), with access is done via SSH. When the attacker authenticates on the system, the vault is initialised automatically without having to authenticate again. Therefore they can read all the users and shared secrets…which is pretty bad.
This probably makes use of the token file, which I noticed was stored in the user’s home directory (which I’m guessing is there because the user is actively using vault as well at the same time the attacker is on the system).
I’m quite new to Vault so my question is whether it’s possible to protect against situations like these. I’m assuming this would require not having the token file stored on disk otherwise, an attacker with read access to it who is also on the host can just re-use it. But then the user has to authenticate each time they need to do access Vault’s content ?
I’m doing the parallel with password managers, where the database auto-locks after a timeout and you’re required to re-authenticate (which can be password/biometrics/key/etc.). Not sure if Vault supports that operating model. Please enlighten me !
I’m making an assumption that this is the default token helper that saves the token in the home directory on login. There is a -no-store option on the cli, but it is not default and would require a login or a token everytime.
If this is the case, you could shorten the TTL on the token itself to match you corporate policy. This would depend depend on how the token is created ( what login method ), but if its LDAP, ( LDAP - Auth Methods - HTTP API | Vault | HashiCorp Developer ) - there is a max_ttl parameter.
Another would be to just delete on exit, or better yet - run vault token revoke on exit. Though getting something to run on exit seems to vary wildly in the unix world.
Thank you for your detailed response. I think your assumption might be correct.
-no-store might be the best option for security, but not for user experience especially as these users are meant to use the Vault quite frequently.
As such, I don’t think a shorter TTL would make a big difference because when users are actively using the host then the token could be stolen from the home directory.
!