encrypt user-uploaded payloads and decrypt on read#3361
Open
uruwhy wants to merge 4 commits into
Open
Conversation
4 tasks
|
Azure Pipelines: 1 pipeline(s) were filtered out due to trigger conditions. |
|
|
1 similar comment
|
|
❌ The last analysis has failed. |
1 similar comment
|
❌ The last analysis has failed. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Description
Encrypt user-provided payloads on disk in
data/payloadsand have the file_svc decrypt them in memory when reading from disk. This avoids attack vectors that attempt to import user-provided python modules from disk.The encryption methodology generates a random 32-byte AES key and 16-byte IV for each payload and prepends the ciphertext with an encryption flag (marking the file as an encrypted user-provided payload and distinguishing it from typical CALDERA-encrypted files), the key, and IV. The key is embedded in the ciphertext blob on disk because the purpose is not to secure the payload contents but rather to prevent the files on disk from being directly executed. Keys are generated separately from the caldera configuration to allow user-provided payloads to still be accessible if the crypt/salt values in the caldera config change for any reason.
Existing user payloads that were uploaded prior to this change will not be affected
Also adds additional payload API unit test coverage and addresses some warnings
Type of change
How Has This Been Tested?
Unit tests, tested with local caldera installation (uploaded payloads via curl and UI)
Checklist: