As you can remember ( and as a must to remember for each good administrator) it is not a good idea to work as a root user on Linux. In a perfect world you should use it only to configure a server, to install or to update software, by and large, only for purely administrative purposes. The problem is that we live in the real world that is, actually, quite far away from a perfect one. So, the situation is quite common and, generally, because of negligence, wherefore, the Linux users had no choice but to figure out how does their software works. However, if you know how does the system work and understand its safety mechanisms then you will never work as a root user. Anyway, today we are going to review the ways of raising authorities up from the unprivileged user to a root one, unlike the situation with Windows where we were considering the ways of running with administrative privileges. So, let’s start.

Exploits

By and large, we can divide all the methods regarding obtaining the superuser’s privileges on Linux in two categories. First, consider the usage of exploits. Unlike Windows, with its automatic update mechanism, Penguin’s users had to watch and update manually all the patches. Due to this fact, the chance to face a not fully patched Linux machine is quite high. Well, what the advantages of this method should we emphasise? Initially, most exploits use the vulnerabilities in the kernel which allow us to get the highest privileges. It is not really difficult to find out the appropriate exploit and I am sure you know couple good resources. Moreover, to use an exploit, occasionally, you do not have to know all the cobwebs of the vulnerability, you need simply to compile and launch it ( it might work without any adjustments). Generally, the operation algorithm looks like this:
1. To determine the kernel and distribution versions
2. To get the list of available tools for the exploit integration
3. To put the exploit on the target machine
4. To compile ( if necessary) and launch
5. To enjoy the root

So, now should we consider each step in more details.

Identification

According to the plan, first of all we need to understand what do we have, what distribution and kernel version do we use. The kernel version we can get by means of the well-known command uname -a or its alternatives. To get the information about the distribution in use, we need to check the *-release file that we can find in the etc directories ( depending on distributive it could have different names, like: lsb-release in Ubuntu, redhat-release in Red Hat / CentOS and so on ):

cat /etc/*-release

Well, knowing the distributive and kernel versions we can move to the next step and try to find an appropriate ‘picklock’.

Search for exploits

As soon as we got all the necessary information we can start to search for an appropriate exploit. The first thought that comes to our minds is to go to exploit-db.com, nonetheless, there are another ways: 1337day, SecuriTeam, ExploitSearch, Metasploit, securityreason, seclists. Down the road, we always have Google that, eventually, know the most of all about exploits for sure.
Well, running ahead of the story, i tell you: sometimes for some reasons a ‘picklock’ could not work and it should be adjusted to certain conditions or your personal needs. In this case, it will be great to get more information about it, that you can find, for example, in here:

www.cvedetails.com
packetstormsecurity.org/files/cve/[CVE]
cve.mitre.org/cgi-bin/cvename.cgi?name=[CVE]
www.vulnview.com/cve-details.php?cvename=[CVE]

Well, let’s suppose, that you have found the appropriate exploit, that grants you the ‘enter-pass’ to the root’s world. All we need to do now is to send it to the target machine.

 

Home delivery

So, there are quite great amount of ways to get the exploit to its place, like, from the well-known cURL/wget, Netcat, FTP, SCP/SFTP, SMB, to the usage of the DNS TXT records. To figure out which tools do we have, we need to proceed this:

find / -name wget
find / -name nc
find / -name netcat
find / -name tftp*
find / -name ftp

Let’s suppose that we found Netcat. To sent a file by means of Netcat we need to launch further command on the host side:

nc -l -p 1234 > out.file

In other words we check 1234 port. In terms of sending side, we proceed further command:

nc -w 3 [destination] 1234 < out.file

In case if the delivery is executing from nix- to nix-system, so there we have standard utilities, and we can accelerate the process using compression. Then the command are going to look like this:

nc -l -p 1234 | uncompress -c | tar xvfp - // for receiving
tar cfp - /some/dir | compress -c | nc -w 3 [destination] 1234 // for sending

On the whole, the other methods are even easier, that is why, we will not review the usage of wget, FTP and the rest well-known methods.

Hide and seek

Well, we have figured out how to deliver an exploit, but how not to betray yourself during the process? Have no doubts, if somebody discover the exploit, your loophole will be closed down shortly. That is why you should place, compile and launch it from some imperceptible place. For example, the files beginning with dot in the Linux directories are buried ones. So, it would be logical to use them to cover up your activities. Likewise, you can place there the exploit code /tmp/.nothingthere/exploit.c. However, in this case you should check whether the ‘tmp’ is set up without ‘noexec’ option, so, you would be able to launch the exploit from there ( to check it use the mount command).

Exploit adjustment and launch

As soon as we have delivered and place the exploit, it should be adjusted. As a rule, exploits are usually written on C, or using another scripting languages, like, Python/Perl/PHP. Our regular reader know that it is not a good decision to leave a compiler on your server, so usually it is ‘filed out’. In case if you get the gcc: command not found after the question about compiler version gcc -v bash, that you are ‘ lucky’ and have to go around, which means that you need to search exploit on the Python, Perl or compile it on the other virtual machine with the similar software and kernel version. After you need to move the executive file on the target host ( however, we can not be 100% sure that the exploit would not take a fall and would not crash the system, so be careful here). However, practically, the interpreter for one of the languages listed above is supposed to exist in the system, as well. So, you should not give up right along, instead, it is better to try all the methods available:

find / -name perl
find / -name python
find / -name gcc*
find / -name cc

Exploit countercheck

It is quite difficult to come up with some innovatory ‘ recipes’ in here. Everything is already well-known. First, we just need to install patches on time. Second – restrict the amount of places that could be used to launch the file execution ( like, the ‘tmp’ folder should be deprived of such opportunity). Moreover, you should implement some protecting solution , for example grsecurity.

Authorities, files, paths and configurations

The second category that is supposed to be emphasised in terms of authorities raise, represents by the methods that are not connected to exploit usage, but are based on the search of the files with incorrectly installed authorities. Just like in Windows, we have ins and outs here as well, however, basically it is the same process considering data collection and analysis. Usually, at the very beginning we try to search files available for reading and writing.

find / -perm 2 ! -type l -ls

As a matter of fact there could be plenty of such files and among them we can find something really interesting: configuration data, sites and applications sources, scripts launched by init or cron. Technically, the situation when a file is open for reading and writing is quite common. The problems appears when users, admins, scripts start to make ‘chicken’ changes in terms of permissions. That is why when you change permissions try to avoid the usage of the chmod 777. And in order to some important files not to become available for everybody, run periodic audit from time to time.

Setuid + setgid

According to documentation, Setuid and Setgid are the access privileges targets allowing to launch the executable files with rights of an owner or the group of executable files ( usually it is root). Such executable files launched with boosted privileges can get access to more privileged information. For example, in case of installing setuid on the ls command, you will get the opportunity to look through the directory contents where initially you had no rights to access, furthermore,in case of vim you can configure files .

Consequently, if there are such vulnerabilities, like buffer overflow or command injection in the applications with installed setuid/ setgid indicators then a hacker can execute an arbitrary code with raised privileges. That is why the next step is to search for executable files with such indicators.

sudo find / -xdev (-perm 4000) -type f -print0 -exec ls -s {} \;

Basically, we can do that without sudo, it is necessary only in order to check the directories that you have no access to.

Usually, there are three ways to use such executable files later. First is to try to boost privileges with due consideration of software and hardware supplied by the application. Second way is to find a public exploit and make an individual fussing in order to detect bugs. Third is the command injection. Well, there is no one-stop solution, it all depends on the situation.

SUDO

The SUDO command (substitute user and do), allows users to delegate privileges resources proceeding activity logging. In other words users can execute command under root ( or other users) using their own passwords instead of root’s one. The rules considering the decision making about granting an access, we can find in /etc/sudoers file. You can also search this information in the official manual and in Wikipedia. I should only say that this file have to be properly checked as well, because quite often certain application make some changes in it during installation and not for the better to be honest, as a result users get the opportunity to boost their privileges (article on the Offensive security, explaining such situation).

Path

Just like on Windows we can raise our privileges by means of the incorrectly set up paths. Usually it happens to the path environmental variables (use printenv to look at it). Had a look? Then tell me now: What if the environmental variable ‘PATH’ would begin with . (.:/bin:/usr/sbin ….)? Usually the users who do not want to type two more symbols do it, in other words want they to activate the command like this $ program instead of $ ./program. By adding ‘.’ in ‘PATH’ we get an opportunity to execute scripts and files from the work directory. We can do it like this:

PATH=.:${PATH}
 export PATH

And now let’s imagine further situation, we have two users: Jo ( hacker) and Bob. Jo is aware that Bob has sudo-privileges to change users passwords, including the root one. Moreover, Bob is lazy and he put ‘.’ in ‘PATH’. Wise Jo writes the program that will be changing the root password, call it ‘ls’ and put in the folder where Bob like to peer in. So, now when Bob go to the folder and decide to check the content of the file, the program will be executed and the password will be changed. So the lesson is that we should always check the environmental variables for the presents of dinger and draw further conclusions.

1. Never use ‘.’ in ‘PATH’ variable
2. If there is the ‘.’ then place the further line in .bashrc or .profile:

   PATH=echo $PATH | sed -e 's/::/:/g; s/:.:/:/g; s/:.$//; s/^://'

   Tools

In order to automise the process of searching the weak points we can use further tools:

1. LinEnum — is a bath- script that can do all the nasty job for you making all the adjustments described here cheat sheet’e. By and large, it has about 65 different checking operations, ranging from getting an information about the kernel version to searching potentially interesting SUID/GUID files. Besides, you can send a lock world to script that it would search in the all configurations and log-files. You can launch the checking like this: ./LinEnum.sh -k keyword -r report -e /tmp/ -t. After the scanning is complete you will get a detail report where the most interesting points will be highlighted with the yellow colour.
   

   Basic options LinEnum

2. LinuxPrivChecker – Python- script will be of use to search potential variants on boosting privileges. Generally, it does all the same stuff, like, checking privileges, getting information about the system , nonetheless, the coolest part is that after the checking is complete it will list the exploits that could be used in order to raise privileges. Such a nice fellow :)!
   

   LinuxPrivChecker Contain a huge number of exploits that regularly are updating from Exploit Database

   

3. unix-privesc-check – This script allows to search ways to boost priviliges not only on Linux, but also on Solaris, HPUX, FreeBSD. It search the configuration mistakes that would allowed an unprivileged user to go up.
   

   unix-privesc-check Offer only two options to choose

   

4. g0tmi1k’s Blog — And here is the blog where you can find a very good explanation regarding the work of those three tools. So, I highly recommend you to have a look on the article and get yourself familiar with them.

Afterword

Now you can see that there is nothing highly sophisticated regarding privileges boost in the world of Linux as well. The secret is simple: in order to get what you want you need to to know what and where to search. Well, you know where to look, aware about the utilities to use, so you can conquer not only the win-system, but the nix-system as well. Go for it!