Privilege Escalation
Hack Responsibly.
Always ensure you have explicit permission to access any computer system before using any of the techniques contained in these documents. You accept full responsibility for your actions by applying any knowledge gained here.
TODO: Add contents links at the top of each page, and references section at the bottom...Add code examples and perhaps screenshots for each example
Tools
linpeas.sh
linpeas.sh
Execute from github
Execute from attacker's machine
Execute from attacker's machine (Without curl)
Output to file
AV bypass
Using open-ssl encryption
Using a base64-encoded payload
/etc/passwd
Add Account & Password to /etc/passwd
Generate password with
openssl passwd -1 -salt $username $password
Add to
/etc/passwd
file which is in the format:$UserName:$generated_password:$UID:$GUID:$comment:$home_dir:$default_shell
(assumes you have write privilege to this file!).
Can be used for persistence.
Create SHA512 password hash for import into passwd file:
Create SHA1 password hash:
GTFOBins
GTFOBins is a curated list of Unix binaries that can be exploited by an attacker to bypass local security restrictions. The project collects legitimate functions of Unix binaries that can be abused to break out restricted shells, escalate or maintain elevated privileges, transfer files, spawn bind and reverse shells, and facilitate the other post-exploitation tasks.
After finding binaries with SUID or other possible root permissions, you can search this site for privilege escalation methods.
You can also find a similar project for Windows at LOLBAS.
Examples:
Privilege Escalation to Root with find
:
Execute any command while in less
:
Escalate to root shell if your user can sudo
any of these text editors:
Sudo
The sudo
command allows non-root users to run commands that would normally require super user privileges. Its configuration file is /etc/sudoers
and lists user's permissions while using sudo
.
NOPASSWD
A sudo
configuration that allows a user to execute specified commands with another user privileges without knowing the password.
In this example the user zweilos
can run vim
as root
. Any files can now be read or written to, for example adding an SSH key into the /root/.ssh
directory. vim
can also be used to gain a root shell or run programs with !<command>
.
LD_PRELOAD
LD_PRELOAD is an optional environmental variable containing one or more paths to shared libraries, or shared objects, that the loader will load before any other shared library, including the C runtime library (libc.so). This is called preloading a library.
Check if
LD_PRELOAD
is explicitly defined in the/etc/sudoers
file:
2. Compile the following shared object using the C code below with gcc -fPIC -shared -o shell.so shell.c -nostartfiles
3. Execute any binary along with the LD_PRELOAD shared object to spawn a shell : sudo LD_PRELOAD=</path/to/malicious/shell.so> <program>
LD_LIBRARY_PATH
LD_LIBRARY_PATH provides a list of directories where shared libraries are searched for first.
Run ldd
against the any program that you can execute as sudo
to see which shared libraries are used by the program:
ldd /usr/sbin/apache2
Create a shared object with the same name as one of the listed libraries (ex. libcrypt.so.1
) using the code located at /home/user/tools/sudo/library_path.c
:
Then compile the program with gcc
.
Run program using sudo
, while settings the LD_LIBRARY_PATH
environment variable to /tmp
(where we output the compiled shared object):
sudo_inject
Using https://github.com/nongiach/sudo_inject:
You can find presentation slides about this tool at: https://github.com/nongiach/sudo_inject/blob/master/slides_breizh_2019.pdf
sudo version < 1.8.28 (CVE-2019-14287)
An issue in sudo
(version 1.8.28 and earlier), which occurs when an entry is inserted into the sudoers file with permissions = (ALL, !root):
This entry normally would mean that user zweilos
is allowed to run chmod
as any user except the root user, however, an error in these versions of sudo
allows an attacker to run the specified programs in the /etc/sodoers
file as root by telling sudo
to act as user ID number -1
(or its unsigned number 4294967295
),which is then interpreted as user ID 0
or root
.
Using scripting languages
If you have privilege to run PERL as other user
If you have privilege to run PYTHON as other user
If you have privilege to run RUBY as other user
If you have privilege to run JAVA as other user
doas (OpenBSD)
There are some alternatives to sudo
such as doas
for OpenBSD. You can check its configuration in /etc/doas.conf
. This configuration has a different syntax than /etc/sudoers
.
SSH
SSH Predictable PRNG (Authorized_Keys) Key Recovery Process
This module describes how to attempt to use an obtained authorized_keys
file on a host system to login to a remote host by using a SSH-DSS string.
Steps
Get the
authorized_keys
file from the victim's system. An example of this file would look like:
2. Since this is an ssh-dss
key, we need to add that to our local copy of /etc/ssh/ssh_config
and /etc/ssh/sshd_config
:
3. Get g0tmi1k's debian-ssh repository and unpack the keys:
4. Grab the first 20 or 30 bytes from the key file shown above starting with "AAAA..."
and search the unpacked keys with grep
:
5. If successful, this will return a public key file (68b329da9893e34099c7d8ad5cb9c940-17934.pub). To use this as a private key file to connect to the victim, drop the '.pub' extension and do:
After this you should be able to connect without requiring a password. If stuck, the details from -vvv
(verbose mode) should provide enough details as to why.
SUID Permissions
SUID (or setuid) stands for "Set user ID upon execution". If a file with this permission is ran, the user's ID will effectively be set to the file owner's (for that program only). For example, if a file with SUID permissions is owned by root
, during the execution of that program the user ID will be changed to root
even if it was executed from the unprivileged user bob
. The SUID bit is represented by an s
in the file permissions.
Find SUID binaries
Create a SUID binary
File Capabilities
What are Linux capabilities?
BLUF: Capabilities break up root privileges in smaller units, so root access is no longer needed. Most of the binaries that have SUID permissions can be changed to use capabilities instead, which in turn increases security.
TODO: rewrite this for clarity and brevity
Normally the root user (or any ID with UID of 0) gets a special treatment when running processes. The kernel and applications are usually programmed to skip the restriction of some activities when seeing this user ID. In other words, this user is allowed to do (almost) anything. Linux capabilities provide a subset of the available root privileges to a process. This effectively breaks up root privileges into smaller and distinctive units. Each of these units can then be independently be granted to processes. This way the full set of privileges is reduced and decreasing the risks of exploitation.
Why capabilities? To better understand how Linux capabilities work, let’s have a look first at the problem it tries to solve. Let’s assume we are running a process as a normal user. This means we are non-privileged. We can only access data that owned by us, our group, or which is marked for access by all users. At some point in time, our process needs a little bit more permissions to fulfill its duties, like opening a network socket. The problem is that normal users can not open a socket, as this requires root permissions.
Option 1: Giving everyone root permissions One of the solutions is to allow some permissions (by default) to all users. There is a serious flaw in this approach. Allowing this kind of permissions, for all users, would open up the system for a flood of system abuse. The reason is that every small opportunity is being used for good, but also for bad. Giving away too many privileges by default will result in unauthorized changes of data, backdoors and circumventing access controls, just to name a few.
Option 2: Using a fine-grained set of privileges For example, a web server normally runs at port 80. To start listening on one of the lower ports (<1024), you need root permissions. This web server daemon needs to be able to listen to port 80. However, it does not need access to kernel modules as that would be a serious threat to the integrity of the system!. Instead of giving this daemon all root permissions, we can set a capability on the related binary, like CAP_NET_BIND_SERVICE. With this specific capability, it can open up port 80. Much better!
Replacing setuid with capabilities Assigning the setuid bit to binaries is a common way to give programs root permissions. Linux capabilities is a great alternative to reduce the usage of setuid.
List capabilities of files
Editing file capabilities
Privilege escalation using file capabilities
The capability =ep
means the binary has all capabilities.
The following capabilities can also be used in order to upgrade your current privileges:
Read any file: cap_dac_read_search
SUID: cap_setuid+ep
Example of privilege escalation with cap_setuid+ep
Misc
list user's sudo permissions: sudo -l
wildcard injection: [NEED MORE HERE]
References
If you like this content and would like to see more, please consider buying me a coffee!
Last updated