So far in the Linux Privilege Escalation series, you have seen the basics and in the previous post, I have discussed shared libraries, which was a big turn. Till now all you have learnt is there from a decade but from this post onwards I will discuss modern techniques. So let's begin with the restricted shell feature
What is Restricted Shell?
To provide security in the shell environment, the Unix foundation has introduced the concept of a restricted shell which is interactive enough to support tab completion and a prompt to accept the commands but limits the functionality from the normal shell. Basically, there are three restricted shells – rsh, rbash and rksh. In this post, I will be covering rbash but the same information can be used for the other two
You can spawn the restricted shell from a normal bash or shell command by adding the -r parameter
sh -r # restricted sh shell, or rsh
bash -r # restricted bash shell, or rbash
This type of shell is mostly found in shared web hosting or some datacenters to provide malicious hackers away from performing remove code execution and then taking over the whole system
I won't add the redundant information on what features of normal bash are not supported in the restricted bash (rbash). You can find them here. However, there is a limitation of the restricted shell, if there is any program that allows users to run the system commands rbash will not be able to check that user input and it could lead to the breakout from the restricted environment
Escaping out of Restricted Shell
In this section, I will discuss the Restricted Shell lab from AttackDefense and you will see how the limitation I discussed previously could lead to the breakout.
I found that the common commands like id and whoami are not working also there is rbash written in the error message, which means that I am in a restricted environment.
One should perform all types of enumeration techniques in their arsenal to find a loophole to execute a shell command from the program other than rbash itself.
So I tried setting environment variable PATH but failed as it is sensitive action in case of restricted bash and which makes sense as updating the PATH to /etc/environment would allow anyone to call the normal /bin/sh or /bin/bash shell
I found that all the programs currently supported are found in the /home/student/.bin directory. Also, I see there vi binary, which is a text editor like vim but with a different set of commands
I tried executing the /bin/bash command from vi and it failed. This looks odd as, vi execute the command by passing to the shell provided in shell option
Later I looked that the /home/student/.exrc file exists which is the configuration for vi and there shell is set to /bin/false. That is why it is throwing error when spawning shell from vi
I am familiar with vim, not vi. So I tried to overwrite the file using
> redirection, but it failed as rbash has limited the use. In the bin directory, I also saw tee command which mean pipe operator (
|) might be supported. I tried piping the output of echo -e to .exrc using tee
Now after running the /bin/bash from vi, I have breaked out of the restricted environment to the normal bash shell. This time I am able to set the PATH environment variable and execute id and whoami commands
Next step is to find for misconfigured suid binaries. I found that wget and sudo is installed. If you want hands on discussion on how suid misconfiguration could lead to privilege escalation, I would recommend you my these two posts – Demystifying SUID and SGID bits and Exploiting SUID Binaries to Get Root User Shell
When you run wget with suid, it saves the file to protected location. In this I will use /etc/sudoers and add
student ALL=NOPASSWD: ALL
Since I can't use file:// scheme with wget, I am using python to server a light weight and on-the-go http file server.
After updating the file, I can now run all command as the root user using sudo. For getting hands on sudo, I would recommend you my two posts – Understand Sudo in Linux and Exploiting Sudo Misconfiguration to Get Root Shell