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

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

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 :)

4) CronJobs
    4.1) CronJobs - File Permissions
    4.2) CronJobs - Path Environment Variables
    4.3) CronJobs - Wildcards

The involves looking for instances in which a cronjob touches a writable root file we can overwrite. Taking a look at /etc/cronjob/ we can see which files have a cron schedule.

Notice how overwrite.sh has root permissions. We can then inject malicious code into overwrite.sh  which will get executed with root permissions. Check you can overwrite it:

Overwrite the file with malicious code (reverse shell) of yours. Mine is shown below:

Set up a listener and wait for the cronjob to run the file which we've just placed malicious code into. Root access achieved below

Here we are going to hijack the PATH variable of the overwrite.sh. Look at the image below and notice how the overwrite.sh file does not have an exact path. This means we could hijack it:

Create a file called overwrite.sh in the home directory. Place malicious code into our overwrite.sh. Mine is a simple reverse shell from earlier

Create the listener with Netcat and wait for root shell.

We can also abuse wildcards to try and get root. Lets look at the file /usr/local/bin/compress.sh which also has root privileges

Notice how it uses a tar command with a wildcard? this is something we can exploit. If we can create a file with the same names as arguments which are passed to the tar command we can get it to execute malicious code.
Create two files using the following command:

Have a listener set up to receive the connection. Once the cronjob runs, it will run compress.sh which will run the tar command, which executes our malicious shell.sh with root privileges. 

2) Shell Escape Sequences
3) Sudo  Environment Variable Hijacking

whatever you want to call it, this involves using native binaries and their functions to achieve root privileges. First step is finding out which binaries run as root:

Then compare this list with GTFOBins. See if you can use them to get root as shown below:

Another example using apache2 to read /etc/shadow

sudo can inherit environment variables, you can check for these by doing sudo -l as shown above. Keep an eye out for env_keep*

• LD_PRELOAD is inherited from the users environment. It can preload shared object libraries before the program runs 
• LD_LIBRARY_PATH provides a list of directories to search for shared object libraries.

The goal to is "hijack" these enviroment variables with a malicious shared object library. First we must create a Shared Object Library called preload.so.

This is the original C code below:

We can now run a program which was listed when we did "sudo -l" (in this case its iftop) and load the malicious shared object library via LD_PRELOAD:

We will now do something very similar but with LD_LIBRARY_PATH. This involves creating a malicious shared library with the same name as an incumbent library and hijacking LD_LIBRARY_PATH. We'll be attacking the apache2 binary. First find out which libraries are loaded by apache2:

Now create a malicious shared object library name with the same name as an already existing library

The original C code of library_path.c

Next, provide the path containing the malicious library while executing the sudo binary:

Today we'll be talking about Linux Privilege Escalation, the process of elevating your privileges on a linux system. Everything is done via a CTF and TryHackMe. i'll be adding to this until its complete.
1) Weak file Permissions
   1.1) Readable /etc/shadow
   1.2) Writable /etc/shadow
   1.3) Writable /etc/passwd

Not a huge amount here. Quick scan of the system should allow attackers to find openings of a Service Exploit
ExploitDB usually has a nice array of exploits which can be used.

The shadow file contains user passwords hashes and is usually readable only by root. However, if it can read by an attacker, there is possibility for an escalation. Below shows a world readable /etc/shadow file.

Reading the file shows the following:

Quick rundown courtesy of /etc/shadow courtesy of  cyberciti.biz (Below if from their website):

" Basically, the /etc/shadow file stores secure user account information. All fields are separated by a colon (:) symbol. It contains one entry per line for each user listed in /etc/passwd file. Generally, shadow file entry looks as follows (click to enlarge image):
/etc/shadow file format (click to enlarge)

As with the /etc/passwd, each field in the shadow file is also separated with “:” colon characters as follows:

1. Username : A valid account name, which exist on the system.
2. Password : Your encrypted password is in hash format. The password should be minimum 15-20 characters long including special characters, digits, lower case alphabetic and more. Usually password format is set to $id$salt$hashed, The $id is the algorithm used On GNU/Linux as follows:
   1. $1$ is MD5
   2. $2a$ is Blowfish
   3. $2y$ is Blowfish
   4. $5$ is SHA-256
   5. $6$ is SHA-512
3. Last password change (lastchanged) : The date of the last password change, expressed as the number of days since Jan 1, 1970 (Unix time). The value 0 has a special meaning, which is that the user should change her password the next time she will log in the system. An empty field means that password aging features are disabled.
4. Minimum : The minimum number of days required between password changes i.e. the number of days left before the user is allowed to change her password again. An empty field and value 0 mean that there are no minimum password age.
5. Maximum : The maximum number of days the password is valid, after that user is forced to change her password again.
6. Warn : The number of days before password is to expire that user is warned that his/her password must be changed
7. Inactive : The number of days after password expires that account is disabled.
8. Expire : The date of expiration of the account, expressed as the number of days since Jan 1, 1970.

"

Onto cracking the hash via hashcat:

Finally the hash is cracked :)

Log into root

Idea behind this one is simple. If the etc/shadow file is writable, perhaps we can write ourselves into the file? Below shows the file is world writable:

Create a new password via:

place the new hash into the etc/shadow file,

Much like the one above, if the etc/passwd file is writable, you can place your own user in or edit a current one. Again the file in question is world writable:

Create new password hash for passwd file.

Save the file and switch to he root user