caldera
caldera copied to clipboard
Displaying un-encoded commands when using obfuscation
Description
When using obfuscation for commands (e.g., Base64), the operations timeline now also contains the plaintext command to decode the actual command (e.g. eval "$(echo d2hvYW1p | base64 --decode)").
Type of change
Please delete options that are not relevant.
- [x] New feature (non-breaking change which adds functionality)
How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [ ] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my feature works
I believe the reports are now working as expected, if there is any non-standard behaviour please let me know since I don't have a deep understanding of the reports structure
@clenk On another note, the SonarCloud job is complaining that the Link class has too many parameters in its constructor (cap is 13, we have 16, not including self). Any tips on how to best handle that?
@argaudreau The usual solution for this is to refactor the code to use an object that stores some of the parameters, but that may not be ideal in our case. We could add a rule to our Sonar configuration to ignore that rule (python:S107) for this file. I'd want to get some consensus before doing so though, just in case.
@clenk I did a local refactor to try and use raw_command instead of adding plaintext_command, but all that'd do is un-encode the command which is stored in base64. So if a command was obfuscated from the operation, we still wouldn't see the plaintext command.
As a workaround I've added a sonarcube exemption to the c_link.py class so it can have more than the allowed constructor parameters. Since it's a fairly large refactor to reduce the number of parameters as well as store the commands un-encoded, we can revisit that at a later date.









