Fixes #17227 - polkit_dbus_auth_bypass module when run from a command… #17299
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.
This PR fixes #17227. There turned out to be a few issues here, besides the initially reported symptom.
The initial root cause was a syntax error in one of the polkit module's commands: one of the exploitation commands ended with a semicolon. In a meterpreter payload, that's fine; but in a command shell, when the tokenised echo shell behaviour added an extra semicolon (e.g.
some_real_command; ; echo the_token
), you end up with two semicolons next to each other with no command in between. In bash, this is a syntax error. In addition, because our SSH sessions are created PTY-less, this error terminates the bash process, and thus the SSH connection (you see the same behaviour if you SSH using the actualssh
command with the-T
flag, and then type; ;
).The solution to this initial issue is to remove that semicolon - doing so fixes the issue: adds the user, gets the privesc working, and gets a shell. I've also changed the command shell behaviour to avoid adding an extra delimiter if there's already one there.
So that fixes the initial issue. However, when the module continues, it then fails to remove the added user. This is because it launches the new (sudo'd) shell synchronously, which blocks the initial shell, and prevents the next command (delete user) from running. This isn't an issue when running the exploit from a meterpreter shell, I guess because it channelises calls to
cmd_exec
. But in a single-channel SSH shell, the sudo'd process is blocking input to the shell, so the deletion fails. The solution to this is to run the sudo'd shell backgrounded, with-b
. This deletion now works in both a Metasploit shell and a command shell.One other quirk of this module is that, after the exploit succeeds (at least in this environment), the new shell ends up with its current working directory in the deleted user's home directory... which no longer exists. That results in the meterpreter shell failing on almost any command, with a not-entirely-clear error message:
So I added a chdir into the directory that was used for the exploit, so that it's immediately usable. That's for meterp shells only - new command shells still end up in the wrong directory - but they're at least usable.
Now starting with a meterp session (to make sure that still works):