Client-side cookie encryption vulnerable to brute force decryption

[f1337]

Summary

This request is based on an chain-exploit from Metasploit. It is based on our using an encrypted cookie for session storage.

Exploit outline

1. Visit va.gov, login, get encrypted session cookie from vets-api.
2. Brute force decrypt the encrypted session cookie, getting the contents and the encryption key.
3. Add arbitrary Ruby objects (Kernel, for example) into the decrypted session contents.
4. Re-encrypt the contetns using the key obtained in step #2, replacing the old cookie.
5. Connect to vets-api, sending the altered encrypted session cookie.
6. Rails will decrypt the cookie, then Marshal.load everything in the contents, including protected class access.
7. Get a shell via Kernel.exec, then get our MPI certificates, then have full access to MPI.
8. If the session cookie is encrypted using the same Rails secret key as the database, then the actor will also have full access to decrypt all the PII we cache.

Suggested Remediation

@f1337 recommends we start rotating session keys, or move to server side session storage. However, database sessions can be SLOW, so consider storing sessions in redis, shared memory, etc.

AC

• [x] Investigate the above exploit steps further
• [x] Determine how to rotate our keys
• [x] Create docs around rotating key
• [x] Alerting mechanism that our key is needing rotation (at the ~1 year mark)
• [x] Create a issue for splitting out our attr_encrypted key and rotating it as well

[ericboehs]

We should also use a separate key for our session encryption vs our database encryption. More investigation on how this cookie encryption key is set/stored is needed.

[ericboehs]

This has been bumped in priority. Let's pick it up next sprint.

[LindseySaari]

Great article comparing/contrasting various session storage options

[LindseySaari]

This gem may be exactly what we're looking for!

Scratch that... it looks like this is only for signed key rotation "Graceful secret key rotation for the signed cookie store in Rails"

[LindseySaari]

Here's an example that gracefully rotates the keys

[LindseySaari]

va.gov has two cookies that I'm aware of. The api_session cookie belongs to the vets-api session, but we also have an sso_cookie, which pertains to the shared cookie between MHV and va.gov. If we ever do rotate the sso key, this will need to be coordinated between va.gov and MHV (https://dsva.slack.com/archives/CQHBJ5U06/p1624652893152200?thread_ts=1624650862.151000&cid=CQHBJ5U06)

The sso cookie is custom encrypted via the SSOEncryptor/Aes256CbcEncryptor whereas the vets_api_session cookie is encrypted/decrypted via the the secret_key_base value

[LindseySaari]

vets-api Key Rotation

ZenHub Ticket

This explains how session cookies are used in vets-api along with encryption methods. Also explained is how vets-api encrypts db attributes with proposed solutions on how to rotate encryption keys gracefully.

Session Cookies in vets-api

Background

The vets-api api_session cookie gets encrypted using the apps secret_key_base The secret key base is stored in credstash and accessed via settings.yml. Each environment has it’s own secret_key_base, located in the devops repo. Rails 5 introduced encrypted creds, which is typically where the secret_key_base would be stored, but vets-api uses credstash for sensitive key storage.

Since vets-api is in api_only mode, out of the box it doesn’t include the session/cookie middleware. The middleware was extended in order to add back the session layer. See application.rb here.

Proposed Solution

The proposed solution is to gracefully rotate out the old keys (secret_key_base) in order to avoid logging users out that have a current session.

Upon visiting vets-api with a session encrypted with the old key, the session will be rotated and re-encrypted with the new secret_key_base value. Given this, currently logged in users have a chance to visit vets-api, get their cookie read with the old_secret_key_base and have it rewritten with the new secret_key_base.

I’ve created a branch and started to poke at the cookie_rotation initializer which will gracefully rotate cookies.

In the devops repo, I’ve created a branch that adds the settings config for the secret_key_base and old_secret_key_base values. I’ve created the old_secret_key_base values in credstash, which are a copy of the current secret_key_base values. I still need to create version 2 of the secret_key_base values. I believe you can generate new keys via the rails secret command.

Malicious User Scenario

Currently, local and dev environment login is broken (see slack conversation) so I did a test in staging. I was able to successfully decrypt the cookie, given that I had the secret_key_base. A malicious actor could hijack a session. See the steps below:

Steps to reproduce:

1. Logged in - staging environment
2. Grabbed my session cookie (api_session)
3. Grabbed the staging secret_key_base out of credstash (pasted into secret_key_base locally in Settings.yml)
4. Started up the rails console
5. Copied the decrypt_session_cookie method from the cookies_spec
6. Called the method and passed in my cookie as a parameter
7. Session was successfully decrypted

Next steps for api_session cookie key rotation:

• [X] Create a credstash key old_secret_key_base with the value of secret_key_base for each environment
• [ ] Create version 2 for the secret_key_base for each environment in credstash
• [X] Create a PR
  • [X] (See Branch) Add the old_secret_key_base as a new key
  • [ ] Generate a new secret_key_base for each env
  • [X] (See branch) Update secret_key_base to point to v 0000002
  • [ ] Review Instance Key rotation? -- Investigate this. See the review instance settings

Questions & Unknowns?

• Is the key defined in config/initializers/session_store.rb overridden by the session/cookie middleware key defined here? I believe it is because because we’re adding the session middleware back in.

Deploy strategy

Questions:

• Will we run into any issues with the rolling deploy when rotating the new/old secret_key_base
• See this article for potential issues

Here are some of the articles that I found useful:

• https://blog.kmkonline.co.id/rotating-ruby-on-rails-secret-key-base-9a4dcdf0d817
  • https://guides.rubyonrails.org/security.html#rotating-encrypted-and-signed-cookies-configurations
  • https://api.rubyonrails.org/v6.1.3.2/classes/ActiveSupport/MessageEncryptor.html
  • Comparing storage options: https://gist.github.com/jcasimir/1210255 https://newbedev.com/adding-cookie-session-store-back-to-rails-api-app

DB encryption/attr_encrypted gem:

• It doesn’t appear that we use the same encryption keys for our session encryption vs our database encryption.
• DB Attributes are encrypted via the db_encryption_key found in the settings.yml
• See some of the solutions here for how to migrate and rotate the encryption key

sso_session cookie

• sso_session cookie (not to be confused with SSOe)
• According to this conversation, SSOe will be fully live on Thursday July 1st, so we may not have to worry about this cookie!

Background info

• There is an sso cookie, used between vets-api and MHV. We encrypt the cookies ourselves with a custom method (see sso_encryptor.rb and aes_256_cbc_encryptor.rb
• See cookies.rb - the to_header method sets the sso and api specific cookies