1

In the TryHackMe's machine, there are some NFS shares that no_root_squash is enabled which allows attacker to create malicious SUID binary on the share with root privileges.

I mounted share successfully, then created a binary file with following command:

sudo msfvenom -p linux/x86/exec CMD="/bin/bash -p" -f elf -o mountPoint/shell

Then changed its permissions as following, so it has SUID on:

sudo chmod 4755 shell

When I type ls -l everything seems alright.

enter image description here

But whenever I run this binary on target, it just gives me a regular shell. This is how file looks like on target:

enter image description here

More info about file I created and target:

enter image description here

What's the issue? What am I doing wrong?

BooRuleDie
  • 11
  • 2

1 Answers1

1

TL;DR - Execute the shell with the -p option e.g. /tmp/shell -p

Running programs with setuid is inherently insecure and when the shell executes the current UID is checked vs. the SUID and if they don't match the shell ignores the SUID and runs as the UID. Adding the -p tells the shell not to reset the UID to the current one.

If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, no startup files are read, shell functions are not inherited from the environment, the SHELLOPTS, BASHOPTS, CDPATH, and GLOBIGNORE variables, if they appear in the environment, are ignored, and the effective user id is set to the real user id. If the -p option is supplied at invocation, the startup behavior is the same, but the effective user id is not reset.

References
Bash Man Page
setuid has no effect in bash

kenlukas
  • 835
  • 6
  • 18