You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I was unsure about categorizing this as a bug, but this does feel like an abnormal behavior.
In a manual operation, editing a link's command before approving the link will display the edited command as obfuscated command. In other words, Caldera does not differentiate between an obfuscated command and a command that has been edited by the user before approving it. Actually, they seem to use the same variable.
This also means that when using any kind of obfuscation, the edition window provides the obfuscated command, and this is what we can edit, even though the result may be that the obfuscated command does not correspond to the plaintext command.
To Reproduce
Steps to reproduce the behavior:
NB: this uses mitre/magma#48 and mitre/magma#49 to make manual approvals work.
First case
Start a manual operation with any adversary, no obfuscation.
Edit the command before approving a link.
The edited command appears as "obfuscated command" (and is the one that's actually executed)
Second case
Start a manual operation with any adversary and b64 obfuscation.
Edit the (obfuscated) command before approving a link.
The edited (obfuscated) command appears as "obfuscated command" (which makes sense), but it may not correspond to the plaintext command anymore.
Expected behavior
In a case with no obfuscation, I would expect the edited command to replace the "plaintext command" and not appear "obfuscated command".
In a case with obfuscation, I am not sure:
do we want the user to edit the plaintext command, which is then re-obfuscated?
do we want the user to edit the obfuscated command, which may then be entirely decorrelated from the plaintext command?
Screenshots
Here I changed the string in the command (no obfuscation), which marks the new command as "obfuscated" even though it's really not.
Here I set up obfuscation and then messed up the obfuscated command. It still shows up as obfuscated command which makes sense, but it's rubbish. I could also have changed it to echo zxcvbn.
@elegantmoose any insight on this? I might be able to submit a fix as I've spent a while looking around to understand how this happens, but I don't know what the ideal working scenario would be.
Plus, although the first case (no obfuscation) looks like a bug, I'm not sure whether the second case (obfuscation) is one.
The text was updated successfully, but these errors were encountered:
Describe the bug
I was unsure about categorizing this as a bug, but this does feel like an abnormal behavior.
In a manual operation, editing a link's command before approving the link will display the edited command as
obfuscated command
. In other words, Caldera does not differentiate between an obfuscated command and a command that has been edited by the user before approving it. Actually, they seem to use the same variable.This also means that when using any kind of obfuscation, the edition window provides the obfuscated command, and this is what we can edit, even though the result may be that the obfuscated command does not correspond to the plaintext command.
To Reproduce
Steps to reproduce the behavior:
NB: this uses mitre/magma#48 and mitre/magma#49 to make manual approvals work.
First case
Second case
Expected behavior
In a case with no obfuscation, I would expect the edited command to replace the "plaintext command" and not appear "obfuscated command".
In a case with obfuscation, I am not sure:
Screenshots
Here I changed the string in the command (no obfuscation), which marks the new command as "obfuscated" even though it's really not.
Here I set up obfuscation and then messed up the obfuscated command. It still shows up as obfuscated command which makes sense, but it's rubbish. I could also have changed it to
echo zxcvbn
.@elegantmoose any insight on this? I might be able to submit a fix as I've spent a while looking around to understand how this happens, but I don't know what the ideal working scenario would be.
Plus, although the first case (no obfuscation) looks like a bug, I'm not sure whether the second case (obfuscation) is one.
The text was updated successfully, but these errors were encountered: