th3xace / sudo_killer

A tool designed to exploit a privilege escalation vulnerability in the sudo program on Unix-like systems. It takes advantage of a specific misconfiguration or flaw in sudo to gain elevated privileges on the system, essentially allowing a regular user to execute commands as the root user.

⭐ Star us on GitHub — to show your support!

💡 Best Viewed in Dark Mode :)

• Intro
• Usage
• Docker
• Checks
• Scenarios
• Video (demo)
• CVEs
• SK-Tools
• Stargazers
• Contribution
• Support
• Credits
• Disclaimers
• License

Introduction

SUDO_KILLER is a tool geared towards cyber security practitioners (pentesters, security auditors, system admins, CTF players and Infosec students ), facilitating privilege escalation within Linux environments. It focuses on vulnerabilities tied to SUDO usage, including misconfigurations in sudo rules, version-based weaknesses (CVEs and vulnerabilities), and risky binary deployments (GTFOBINS). These weak points can be exploited to gain ROOT-level privileges or impersonate users.

SUDO_KILLER provides a catalog of potential commands and local exploits for manual privilege elevation. Importantly, it refrains from automated exploitation, requiring users to carry out the exploitation process themselves as per its intended usage.

Checks

Below is a list of checks that are perform by SUDO_KILLER

• Misconfigurations
• Dangerous Binaries (GTFOBINS)
• Vulnerable versions of sudo - CVEs
• Sudo vulnerability and misconfiguration related to 3rd party apps
• Dangerous Environment Variables
• Credential Harvesting
• Writable directories where scripts reside
• Binaries that might be replaced
• Identify missing scripts

Warning

The check list above is NOT exhaustive.

Usage

To get started with SUDO_KILLER, you can either git clone or download the zip. If you want to practice and/or test it, there is a vulnerable testing enviroment (docker) see the video on it which provides an overview on how to setup the docker and run SUDO_KILLER. Several scenarios can be setup in the docker environment and can be used for testing different misconfigurations or flaws. Alternatively, you can run it on the system to be audited to check for misconfigurations and/or flaws related to sudo.

./SUDO_KILLERv<version>.sh -c -a -e -r report.txt -p /tmp

Optional arguments:
-c : includes CVE checks
-a : includes CVEs related to third party apps/devices
-i : import (offline mode) from extract.sh
-e : include export of sudo rules / sudoers file
-r : report name (save the output)
-p : path where to save export and report
-s : supply user password for sudo checks (If sudo rules is not accessible without current user's password)
-h : help

Note

It is worth noting that when using the -c argument, two types of check are provided one for which the CVE identified is solely based on the current sudo version being used and another where the requirements are also checked. Very often, a sudo version might be vulnerable but some pre-requisites might be needed for a successful exploitation.

Note

Providing password: If you need to input a password to run sudo -l then the script will not work if you don't provide a password with the argument -s.

Docker (Vulnerable testing environment)

A range of Docker containers is made available to offer a deliberately vulnerable environment for testing and hands-on experimentation with SUDO_KILLER as well as with the vulnerabilities.

service docker start 
docker pull th3xace/sudo_killer_demo3
docker run --rm -it th3xace/sudo_killer_demo3

(This docker is only to test the CVE-2019-18634 (pwfeedback))
service docker start 
docker pull th3xace/sudo_killer_demo2
docker run --user 1000 --rm -it th3xace/sudo_killer_demo2

Why is it possible to run "sudo -l" without a password?

By default, if the NOPASSWD tag is applied to any of the entries for a user on a host, you will be able to run "sudo -l" without a password. This behavior may be overridden via the verifypw and listpw options.

However, these rules only affect the current user, so if user impersonation is possible (using su) sudo -l should be launched from this user as well.

Sometimes the file /etc/sudoers can be read even if sudo -l is not accessible without password.

Scenarios

To switch scenario (To prevent conflicts between the different scenarios) on the docker (demo3):

switchScenario <scenario_number>

Available scenarios: 0 to 10
All Scenarios 0 : Conflict might occur!
Scenario 1: [2,3] CVE - Rules
Scenario 2: [4] Excessive permissions
Scenario 2: [5] Excessive permissions (Authentication required)
Scenario 3: [6] User Impersonation
Scenario 4: [7] Common Misconfiguration (Change owner)
Scenario 4: [8,11] Common Misconfiguration (Wildcard)
Scenario 5: [13] Missing scripts from sudo rules
Scenario 6: [17] Dangerous Environment Variables
Scenario 7: [18] Dangerous binaries (gtfobins)
Scenario 8: [19] Recursive Impersonation test
Scenario 9: [20] Environment Path Hijacking
Scenario 10: [21] App Specific sudo vuln/misconfig
Scenario 11: [5] Excessive permissions (Authentication required)
Scenario 12: [16] Backdooring sudo (Credentials Capture)

Videos - Demo

The playlist can be found here: https://www.youtube.com/watch?v=Q8iO9mYrfv8&list=PLQPKPAuCA40FMpMKWZLxQydLe7rPL5bml

Important

Quick videos on how to properly do the testing on the provided docker.

(click to expand) Usage : How to setup and use the provided testing environment (docker)

 

Warning

The video list below is not exhaustive, to have access to all the videos, please check the playlist link.

Several videos are provided below with different scenarios of exploitation.

 

 

 

 

 

 

CVEs

(click to expand) CVEs related to SUDO that SUDO_KILLER detects (including pre-requisites):

 

 

 

(click to expand) Recent CVEs of 3rd party apps/devices related to sudo that SUDO_KILLER detects (including pre-requisites):

 

SK-Tools

Version 3 of SUDO_KILLER now includes a list of tools that can be used to achieve several tasks. The scripts are located at SUDO_KILLERv3/SUDO_KILLER/SK-Tools/

• $\color{#f0a015}\large{\textsf{SK-ImperBruteForce-NoPwd.sh:}}$ Perform an impersonation bruteforce using users from /etc/passwd, starting from user with uid 1000.
• $\color{#f0a015}\large{\textsf{SK-credHarvest2.sh:}}$ Perform a credential capture by creating a fake sudo via alias then re-direct to real sudo.
• $\color{#f0a015}\large{\textsf{SK-app-check.sh:}}$ Perform check of sudo vulnerabilities related to a specifc third-party app or device or programming lang [still in progress].
• $\color{#f0a015}\large{\textsf{SK-ttyInject.sh:}}$ Abusing TTY pushback so that if the user root su - on a controlled user we make him run an arbitrary command.
• $\color{#f0a015}\large{\textsf{SK-recursive-impersonate.sh:}}$ Perform identification of recursive impersonation with a default depth of 3.
• $\color{#f0a015}\large{\textsf{SK-alias-report.sh:}}$ Perform search on alias with different criteria.
• $\color{#f0a015}\large{\textsf{SK-csuid-with-sudo.sh:}}$ Perform identification of custom suid binary then check whether sudo command is run without full path.
• $\color{#f0a015}\large{\textsf{SK-su-BruteForce.sh:}}$ Perform password bruteforce or password spray for a specific user via sudo.
• $\color{#f0a015}\large{\textsf{SK-search-sudoers.sh:}}$ Perform an identification of possible sudoers backup files on the current host.

(click to expand) Usage : SK-Tools

 

 

 

 

Capturing Credentials via sudo redirect (SK-credHarvest2.sh)

The script SK-credHarvest2.sh from SK-Tools allow to perform a credential capture by creating a fake sudo via alias then re-direct to real sudo. Actually works only for bash (not working/implemented for ZSH or else for now)configured linux.

The displayed message when asking for credential when using sudo differs from the version being used. It is possible to choose between two options (differ based on OS version). Example of the displayed message (new and old)

Tip

(new) [sudo] password for user:
(old) Password:

For All Users (auser): When you have root privilege or excessive rights on users' home and you want an easy way to gather credentials:

./SK-credHarvest2.sh auser <new|old> ; source /home/*/.bashrc

For the currrent user (cuser):

./SK-credHarvest2.sh cuser <new|old> ; source /home/<currentuser>/.bashrc

Caution

TO STOP the credential harvesting: run the same script again with same argument

output: the log /tmp/sk-crds.log will contains the credentials

Alias' Audit (SK-alias-report.sh)

You will either need root privilege, access to a backup of sudoers or read access to /etc/sudoers.

Usage: ./SK-alias-sudoers.sh -p <sudoers_path> -k <keyword> [-u] [-r] [-m] [-c] | [-a]
  where -u: user | -r: runas | -m: host | -c: command | -a: all

Bruteforce/Password Spray via su (SK-su-BruteForce.sh)

Using su to bruteforce password and password spray with concurrency, timeout and sleep.

Usage: ./SK-su-BruteForce.sh [-h|--help] [-m|--module MODULE] [-u|--user USER|-uf|--userfile USERFILE] [-p|--password PASSWORD|-pf|--pwdfile PASSFILE] [-c|--concurrent CONCURRENT] [-s|--sleep SLEEP] [-t|--timeouts TIMEOUTS]

Module: Password Bruteforce : pwdbf
Example: ./SK-su-BruteForce.sh -m "pwdbf" -u user -pf password.txt -c 5 -s 0.005 -t 0.9

Module: Password Spray : pwdspr
Example: ./SK-su-BruteForce.sh -m pwdspr -uf users.txt -p password -c 5 -s 0.005 -t 0.9 

Module: User:Password Bruteforce : usrpwdbf
Example: ./SK-su-BruteForce.sh -m usrpwdbf -uf users-pwd.txt  -c 5 -s 0.005 -t 0.9 

Search for backup of the file sudoers (SK-search-sudoers.sh)

Find possible sudoers backup files in /mnt/ /opt/ /etc/ /etc/ /home/ /app*/ and any additional one parse as argument

Usage: ./SK-search-sudoers.sh /tmp/

Update dangerous bins - GTFOBINS (SK_dbins_update.sh)

To update the dangerous bins, go to dbins/update and run ./SK_dbins_update.sh. Make sure you have internet connection.

Usage: ./SK_dbins_update.sh

Binary Relative Path (SK-relative-path.sh)

Looking for binaries with relative path that be abused! if there is no secure_path set.

sudo -l
<..snip..>
(root) SETENV: NOPASSWD: /opt/support/purge.sh
<..snip..>

Usage: ./SK-relative-path.sh /opt/support/purge.sh

Contributing

SUDO_KILLER is an open-source project and highly appreciate any contributions. Whether you are helping us fix bugs, proposing new features, improving our documentation or spreading the word - we would love to have you as a contributor. Please reach me on twitter or Linkedin if you have any suggestions, feedback or want to contribute, you can also create a Pull Request. I am looking for contribution on the sudo CVEs related to 3rd party (I have a list of about 175) and any help would be appreciated.

• Bug Report: If you see an error message or run into an issue while using SUDO_KILLER, please create a bug report.

• Feature Request: If you have an idea or you're missing a capability that would make development easier and more robust, please submit a feature request.

Stargazers over time

Thank you all for your support!

Support

Credits

I crafted the script independently, leveraging online resources from GitHub and other sources in the wild. Acknowledgments are also due to the creators of exploits associated with CVEs. You can trace their details and references in the exploit itself, as well as in the accompanying notes when the tool is executed. Notable recognition extends to Vincent Puydoyeux, whose inspiration spurred the development of this tool, and Koutto, for invaluable assistance in handling Docker intricacies and enhancing the tool's functionality. Additionally, a heartfelt thank you goes out to Emilio Pinna (norbemi) and Andrea Cardaci (cyrus_and) for their invaluable contributions to GTFO Bins, which significantly influenced this project's development.

Disclaimer

This script is for Educational purpose ONLY. Do not use it without permission of the owner of the system you are running it. The usual disclaimer applies, especially the fact that me (TH3xACE) is not liable for any damages caused by direct or indirect use of the information or functionality provided by this project. The author (TH3xACE) or any Internet provider bears NO responsibility for content or misuse of these programs or any derivatives thereof. By using these programs you accept the fact that any damage (dataloss, system crash, system compromise, etc.) caused by the use of the script is not the author responsibility.

License

SUDO_KILLER is licensed under the MIT license, proper credits is expected whenever used. Please consider to donate for any commercial use.

sudo_killer's Issues

Error -> Checking for disclosed vulnerabilities related to version used (CVE)

It's me again :)

It might be better to add a check for "cve_vuln", as well as slightly tweak the calculation of "cvepath" (line 273 and 275).

if [ "$cve_vuln" ]; then   #add
  while read -r line; do
    #cvepath=`ls -al exploits/ | grep "$line" | cut -d " " -f 12`
    cvepath=`ls -al exploits/ | grep "$line" |tr -s " " |cut -d " " -f 9` #mod
  ...
done <<< "$cve_vuln"
fi  #add

Otherwise, the path to cve is not displayed and the incorrect result is displayed if "cve_vuln" is empty.

Repository too heavy

I tried to download the repository to carry out some tests but I realized that it is really heavy, is there a way to make downloading and using the software more efficient?
Also an idea of future development.

Checking sudo without password

I suppose the line 331 should be started with "sudonopassuser=" not "sudonopassuser=="

P.S.
Why are you using the GREP at the end? Maybe one is enough?

Bug

Describe the bug

I was testing my system for sudo security and found a false positive when testing for the CVE-2019-14287

To Reproduce

1. open bash
2. git clone https://github.com/TH3xACE/SUDO_KILLER.git
3. ./SUDO_KILLERv2.0.3.sh -c -i -r $(echo report_$(date +%H:%M:%S_%m-%d-%Y)) -p ./
   3.1 report shows CVE-2019-14287 and CVE-2019-18634
4. ./cve_updatev2.sh
5. ./SUDO_KILLERv2.0.3.sh -c -e -r $(echo report_$(date +%H:%M:%S_%m-%d-%Y)) -p ./
   5.1 reports shows CVE-2019-14287 and CVE-2019-18634

6.0 Test CVE-2019-14287 - Make sure no sudo session is open
6.1 sudo -k #kill or timeout sudo session
6.2 sudo whoami
6.2.1 [sudo] password for paul:

7.0 sudo -u#-1 echo -e "I became $(whoami)"
6.1 > sudo: unknown user: #-1
> sudo: unable to initialize policy plugin

8.0 sudo -u#$((0xffffffff)) echo -e "I became $(whoami)"
8.1 > sudo: unknown user: #4294967295
> sudo: unable to initialize policy plugin

Expected behavior
============== Checking for Common Misconfiguration ====================
================== Checking for File owner hijacking =======================
============= Checking for File permission hijacking =====================
all lines further empty because I am special 🥇

Screenshots
Let me know if you need these.

Desktop (please complete the following information):
APP: bash 5.0.3
APP: sudo version 1.8.27

OS: Dsuebian GNU/Linux 10 (buster) x86_64
Kernel: 4.19.0-10-amd64

Additional context
May be set -x to debug bash and back with set +x

CVE-2019-18634
The sudoers pwrfeedback flag is off by default and should not be reporting this issue too.
Test instructions: https://www.sudo.ws/alerts/pwfeedback.html

Automation Improvement (Checking for Missing scripts from sudoers)

I suppose that the line 484-486 should look like that:

touch /tmp/script_list #for compatibility with future checks
if [ "$sudonopassuser" ] || [ "$sudoauth" ]; then
  if [ "$sudonopassuser" ]; then
    echo "" |sudo -S -l -k | grep "NOPASSWD" | sed 's/(root) //g' | sed 's/NOPASSWD: //g' | sed 's/,/\n/g'  | sed -e 's/  *$//' | awk '$1=$1' | cut -d " " -f 1 | grep .sh  >> /tmp/script_list
  fi
  if [ "$sudoauth" ]; then
    echo $userpassword |sudo -S -l -k | grep "NOPASSWD" | sed 's/(root) //g' | sed 's/NOPASSWD: //g' | sed 's/,/\n/g'  | sed -e 's/  *$//' | awk '$1=$1' | cut -d " " -f 1 | grep .sh  >> /tmp/script_list
  fi
  echo -e "${BOLD}${GREEN}[+] The script/s found in sudoers can be found at: /tmp/script_list ${RESET}"
fi

This will allow user to not manually enter the password again, as well as increase the speed of the script.

Line 484-486 (Original)

sudo -S -l -k | grep "NOPASSWD" | sed 's/(root) //g' | sed 's/NOPASSWD: //g' | sed 's/,/\n/g'  | sed -e 's/  *$//' | awk '$1=$1' | cut -d " " -f 1 | grep .sh  > /tmp/script_list
echo -e "${BOLD}${GREEN}[+] The script/s found in sudoers can be found at: /tmp/script_list  ${RESET}"

Little double quote issue

Describe the bug
There is a problem with if condition in SUDO_KILLERv1.3.2.sh.

To Reproduce
Steps to reproduce the behavior:
../SUDO_KILLERv1.3.2.sh -c -r report.txt -e /tmp/

Problem
============ Checking for disclosed vulnerabilities related to version used (CVE) ==================

[+] Sudo version vulnerable to the following CVEs:
./SUDO_KILLERv1.3.2.sh: line 266: [: too many arguments

To solve
I added double quote to a variable.

It was like that:
if [ $cvepath ]; then ...

I changed it like this:
if [ "$cvepath" ]; then ...

It is not a big issue actually and issue is very simple but I still wanted to write it and it's solution. Thank you for this awesome project :)

Missing scripts checking out arguments

Describe the bug
The missing scripts function parses the whole command as one file. If the command is /usr/bin/cat somefile the program will check for the existence of /usr/bin/catsomefile

To Reproduce
Steps to reproduce the behavior:

1. Insert the following command in a sudoer rule : /usr/bin/cat somefile

Expected behavior
A clear and concise description of what you expected to happen.
I think it would be appropriate to only check if the binary exists except if the binary is an interpreter. in which case the presence of the file should be checked

Side note
I want to say that you've done some really great work, thank you ! :)

Checking for disclosed vulnerabilities related to version used (CVE)

When "cve_vuln" is empty (line 271) the next check returns an incorrect result.

Sudo version: 1.8.17p1

#./SUDO_KILLERv1.3.9.sh -c
...snip...
============ Checking for disclosed vulnerabilities related to version used (CVE) ==================  

[+] Sudo version vulnerable to the following CVEs:

[+] Please find the following exploit for  in the exploits' directory:
[*] Exploit /exploits/
.
..
absolute_path-sudoedit.txt
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09

05:09
05:09
05:09
05:09
05:09
05:09
05:09

CVE-2005-1831.txt
CVE-2006-0151.perl
CVE-2006-0151.python
05:09
CVE-2012-0809.txt
CVE-2012-0864-0809.c
CVE-2014-0106.txt
05:09
CVE-2017-1000367-1.c
CVE-2017-1000367-2.c
CVE-2017-1000367.c
CVE-2019-14287.txt
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09

05:09
05:09
05:09
05:09
05:09

05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09

05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
pwfeedback.txt
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09

05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
05:09
vim.txt
05:09
05:09
05:09

05:09
05:09
05:09
05:09
05:09

P.S. I thought sudo 1.8.17p1 should be vulnerable to CVE-2019-14287

.gitmodules missing?

$ git clone https://github.com/TH3xACE/SUDO_KILLER
...
$ cd SUDO_KILLER
$ git submodule update --init --recursive
fatal: No url found for submodule path 'exploits/CVE-2021-3156/exploit1/CVE-2021-3156' in .gitmodules

If you look at the commit logs for db2ef96, looks like you added CVE-2021-3156 as a submodule at some point and then either forgot to commit .gitmodules or broke with that approach in an inconsistent state.

Not sure what the best resolution is, but currently it breaks any attempt to include SUDO_KILLER as a child submodule inside other projects.

Checking for Missing scripts from sudoers

I think that the line 469 should look as follow:

if [ "$sudonopassuser" ]; then
echo '' |sudo -S -l -k | sed 's/(root) //g' | sed 's/NOPASSWD: //g' | sed 's/,/\n/g' | sed -e 's/ *$//' | awk '$1=$1' | cut -d " " -f 1 | grep .sh > /tmp/script_list
echo -e "${BOLD}${GREEN}[+] The script/s found in sudoers can be found at: /tmp/script_list ${RESET}"
fi

I'm always frustrated when the phone version changes and chrome acts weird when maps keep something hidden

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.