Insecure SUDO configurations

System roots often allow certain commands to be executed by non-root users in a controlled manner. This non-root user might be local human users or a user with whose privilege a remote application runs. But this controlled allowance might result in unintended privileges for the non-root user, if improper configurations are done.

Attack scenarios:

1. Unsafe options in sudo-able commands

SSH:
A program is running as a non-root Linux user which allows users to execute ssh command as root, as configured in sudoers file. The command string coming from the users are properly sanitized by the application to filter out command injection characters like ;,&,| etc. The command name, first word in the string, is also matched to be 'ssh'. What if some user enters the command -

sudo ssh -F /etc/shadow 127.0.0.1

As the file is not a ssh configuration file, the command will output each line of /etc/shadow file in a verbose error message. This will allow the attacker to read any file in the system.

ARP:

Similarly, sudo arp -v -f /path/file will allow the user to read any system file.

TELNET:

sudo telnet -n /path/file will allow to delete the contents of any system file.

TCPDUMP:

sudo tcpdump -i em0 -G 1 -z /tmp/lala.sh -w dump will execute the script /tmp/lala.sh as root.
ref: https://seclists.org/tcpdump/2010/q3/68

FIND:

sudo find /file/path -exec /bin/bash will provide a root-bash to the non-root user. Using NOEXEC in sudoers will help preventing this.

SERVICE:

sudo service ../../bin/bash can be used to gain root bash

Fix: Use wrapper shells to invoke the desired commands, instead of directly exposing the system commands to non-root users and do necessary sanitization in the wrapper script. Any option that takes a file path or executable path in a sudo-able command should be sanitized.

Using NOEXEC. This will prevent the sudo-able scripts/commands to execute other scripts by its own, like the examples above for TCPDUMP and FIND.

If you are doing application layer filtering of command (sudo-able) options, don't look for the exact command options like - "-f", "-n", "-F' etc. These checks can be easily bypasses by combining options or using "\" - e.g. "-vf" or "-\f" will bypass. Use proper regex or use a wrapper shell code to identify them using "getopts" command (or similar).

2. non-root users having write permissions to sudo-able script or directory :

If /path/script.sh is sudo-able and non-root users have write permission to that file, then its a call for trouble. Non-root users can modify the script to put arbitrary commands and then execute as root.

Allowing /home/user in sudoers and non-root users having write access to the directory will allow non-root users to create arbitrary scripts in the /home/user directory and execute them as root.

Fix: sudo-able scripts/directories shouldn't be writable by non-root users. Never use wildcards as entries in sudoers, only allow specific commands what is necessary.

3. Improper input sanitization for a sudo-able script

A sudo-able custom script takes as input - a. path to other script that it should execute, b. system commands/command options etc. and doesn't sanitize the inputs properly. Or it might contain a OS command injection vulnerability. Any vulnerability in this script might allow an attacker to execute arbitrary scripts/commands as root.

Fix: Sanitize all inputs to a sudo-able script properly.