InfoSec LAB

Meta_Sudo_Privileges_thomas

Created: 3 min read

thomas

Checking for sudo privileges of the thomas user after making lateral movement

thomas@meta:~$ sudo -l
matching defaults entries for thomas on meta:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, env_keep+=XDG_CONFIG_HOME
 
user thomas may run the following commands on meta:
    (root) nopasswd: /usr/bin/neofetch \"\"

The thomas user is able to execute the /usr/bin/neofetch \"\" command as the root user without getting prompted for password

there are two interesting things here:

  • The \"\" part in the command, /usr/bin/neofetch \"\", represents an empty argument passed to the neofetch command. The two double quotes "" are used to escape any special meaning that might be associated with the absence of an argument. It tells the command to interpret the empty argument as a valid argument rather than interpreting it as a syntax error or as a missing argument.

  • Another interesting part is the sudo option;env_keep+=XDG_CONFIG_HOME

    • env_keep+=XDG_CONFIG_HOME is a directive used in the sudoers file that specifies an environment variable called XDG_CONFIG_HOME to be preserved when a user runs a command with sudo.

    • The env_keep directive is used to specify environment variables that should be kept or preserved when a user executes a command with sudo. By default, sudo removes most of the environment variables, and only a few variables are kept, such as HOME, LOGNAME, PATH, and TERM.

    • In this case, env_keep+=XDG_CONFIG_HOME instructs sudo to preserve the XDG_CONFIG_HOME environment variable when a user executes a command with sudo. This environment variable specifies the location of the user’s configuration files, and preserving it can be useful in situations where the user needs access to their configuration files when running a command with sudo.

Neofetch

According to GTFObins, neofetch itself can easily abused for privilege escalation if configured to run by sudo as the root user

Considering the sudo option provided above, I would not need to provide the --config argument to get code execution in this case I can just define my own by creating a config file for neofetch

Config

thomas@meta:~$ ll
total 36K
4.0k drwxr-xr-x 5 thomas thomas 4.0k apr 26 18:43 .
4.0k drwx------ 3 thomas thomas 4.0k apr 26 18:43 .gnupg
4.0k drwx------ 2 thomas thomas 4.0k apr 26 18:16 .ssh
4.0k -rw-r----- 1 root   thomas   33 apr 26 10:00 user.txt
4.0K drwxr-xr-x 3 thomas thomas 4.0K Aug 30  2021 .config
   0 lrwxrwxrwx 1 root   root      9 Aug 29  2021 .bash_history -> /dev/null
4.0K -rw-r--r-- 1 thomas thomas  220 Aug 29  2021 .bash_logout
4.0K -rw-r--r-- 1 thomas thomas 3.5K Aug 29  2021 .bashrc
4.0K -rw-r--r-- 1 thomas thomas  807 Aug 29  2021 .profile
4.0K drwxr-xr-x 3 root   root   4.0K Aug 29  2021 ..
thomas@meta:~$ cd .config ; ll
total 12K
4.0k drwxr-xr-x 5 thomas thomas 4.0k apr 26 18:43 ..
4.0K drwxr-xr-x 2 thomas thomas 4.0K Dec 20  2021 neofetch
4.0K drwxr-xr-x 3 thomas thomas 4.0K Aug 30  2021 .
thomas@meta:~/.config$ cd neofetch/ ; ll
total 24K
4.0K drwxr-xr-x 2 thomas thomas 4.0K Dec 20  2021 .
 16K -rw-r--r-- 1 thomas thomas  15K Aug 30  2021 config.conf
4.0K drwxr-xr-x 3 thomas thomas 4.0K Aug 30  2021 ..

The config file is located at /home/thomas/.config/neofetch/config.conf As this file looked rather familiar, I remembered PSPY detecting it as part of the root cronjob The file was being restored from a file in the home directory of the root user. This strongly indicates that this is the privilege escalation vector.

Moving on to the Privilege Escalation phase

Interactive Graph View

Backlinks