During a system penetration test, a security engineer successfully gained access to a shell on a Linux host as a standard user and wants to elevate the privilege levels.
Which of the following is a valid Linux post-exploitation method to use to accomplish this goal?
A valid Linux post-exploitation method to elevate privileges from a standard user shell is to spawn a shell using sudo and an escape string such as sudo vim -c '!sh'. This method exploits the elevated privileges granted by the sudo command which, if the sudoers configuration permits it, allows the user to execute commands with superuser privileges. By running vim under sudo and using an escape string, the user can open a shell with root privileges, thus achieving privilege escalation.
/etc/passwd doesn't mean anything on modern linux systems. You would need to read /etc/shadow to get hashes if you wanna tray to crack them (and you have to be root for that). The best thing is A as this directly leads to spawning a root shell.
Would a standard user be able to use any sudo commands? The passwd file doesn't store the hashes but it lets you know the different user accounts. There might be some non-root accounts with some increased privileges that might have easy passwords, which you could find in the passwd file
Depends heavily on how well configured your sudoers file is. Short answer is "Yes" on some Linux systems standard users can launch programs such as Vim with Sudo.
The answer is C. the account being used does not have super user access so they cant use sudo, as an attacker the best move would be to find out what usernames are available and maybe try to elevate my permissions using one of those user accounts found in the etcppasswd file
A https://gtfobins.github.io/gtfobins/vim/
As the account is a standard user, they will not have the rights to edit configuration files (sudoers), so the best option is to access the passwd file (you do not need any privileges to do this).
I think I'll change my answer to A
passwd file should be locked down to only root
A. Spawn a shell using sudo and an escape string such as sudo vim -c '!sh' is a valid Linux post-exploitation method to elevate privilege levels. This method takes advantage of the sudo command, which allows users to execute commands with elevated privileges, and the escape string "!sh" invokes a shell with root privileges.
A can be possible if the Linux system is vulnerable, getting shell using Vim via Sudo If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access. sudo vim -c ':!/bin/sh' reference: https://gtfobins.github.io/gtfobins/vim/
Best thing to do is read /etc/passwd file
/etc/passwd is a plain text-based database that contains information for all user accounts on the system. It is owned by root and has 644 permissions . The file can only be modified by root or users with sudo privileges and readable by all system users. via https://linuxize.com/post/etc-passwd-file/ Seems readable by all users.
The user can't read the /etc/passswd file without elevated privileges. A
The command sudo vim -c '!sh' is a technique used to escalate privileges on a Linux system by exploiting the capabilities of the vim text editor.
The likelihood of a passwd being plaintext isn't very likely. This is not a database and service path is not local. Going with A, attempt to gain root Source: Verifying each answer against Chat GPT, my experience, other test banks, a written book, and weighing in the discussion from all users to create a 100% accurate guide for myself before I take the exam. (It isn't easy because of the time needed, but it is doing my diligence)
The escape string "sudo vim -c !sh'" is a commonly used method to spawn a shell as a root user in Linux. This command opens the vim text editor as a root user and executes the "sh" command to spawn a new shell with root privileges. Reading the /etc/passwd file to extract the usernames (Option C) is a reconnaissance technique that helps identify user accounts on the system but does not provide a way to elevate privileges.
Initiate unquoted service path exploits could also work here, no?