Linux Privilege Escalation - Part Four

5) Shared Object Library Hijacking/Injection
6) Exploits
​

Shared Object library hijacking/injection

From the title you can probably deduce what this is about. This method involves:
1) finding a binary/file/service which has SUID bit set and owned by root. 
2) Checking to find if the file has is vulnerable to hijacking 
3) Replacing the library with a malicious one
​4) profit

Finding a SUID file to exploit is simple. See below:
​

Now we have our list of vulnerable SUID binaries, time to pick one to exploit. For demo purposes i'm choosing the last one. 
Now we need to check whether the file is actually vulnerable. Luckily we can do this with strace. 
Strace is a linux util which helps with tracing system calls. For us, we can find open calls to files which are missing or replaceable. See below: 

We can see the SUID binary is vulnerable as it to open a library(./libcalc.so). However it is possible for us to overwrite this library as its located in a writable folder. Next we create our malware (which just executes /bin/sh). 

Next, compile your malicious code and replace the innocent library with your malicious one. Make sure to name your malicious library exactly the same as the innocent one we replace. Run the SUID binary and hopefully it will load your code and you'll get a root shell

Linux Exploits

Check which the of binaries with SUID is vulnerable to exploits. Try to compare against a exploit database such as exploit-db. Once you've found one, give it a go. Below i'm exploiting a vulnerable exim service with a well known exploit. Code below.

Root Shell :) 

A simple and easy kernel exploit is the famous dirtyc0w exploit[CVE-2016-5195]. I wont go into the intricacies with the code. Running the exploit shows this:  

Root Shell :)