# Dynamic Linker Hijacking

Adversaries may execute their won malicious payloads by hijacking environment variables the dynamic linker uses to load shared libraries. During the execution preparation phase of a program, the dynamic linker loads specified absolute paths of shared libraries from environment variables and files, such as LD\_PRELOAD on Linux or DYLD\_INSERT\_LIBRARIES on macOS. Libraries specified in environment variables are loaded first, taking precedence over system libraries with the same function name. These variables are often used by developers to debug binaries without needing to recompile, de-conflict mapped symbols, and implement custom functions without changing the original library

On Linux, adversaries may set LD\_PRELOAD to point to malicious libraries that match the name of legitimate libraries which are requested by a victim program, causing the operating system to load the adversary's malicious code upon execution of the victim program. LD\_PRELOAD can be set via the environment variable or /etc/ld.so.preload file.

In this example I've built a small static library that when loaded it just prints out "Hello World" you must be careful with these libraries to not consume resources as this will crash the application or make the OS unusable depending on what you've hijacked.

```
#define _GNU_SOURCE
#include <stdio.h>
 
__attribute__((constructor)) void run_hello(void) {
    printf("Hello World\n");
}
```

We proceed to compile this `gcc -shared -fPIC -o /tmp/hello.so hello.c` and we can test the preload with the following

<figure><img src="https://315180959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MRh03Vwd4nuiUi3Oje7%2Fuploads%2FedP9yuBEUGkBqfh7nCUi%2Fimage.png?alt=media&#x26;token=a1392e65-3a7b-4fe6-897a-731f0736086c" alt=""><figcaption></figcaption></figure>

But we can also set the environment variable to utilize this library

<figure><img src="https://315180959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MRh03Vwd4nuiUi3Oje7%2Fuploads%2Fn3NYICVlFz6sfS48QNeD%2Fimage.png?alt=media&#x26;token=04a98769-6d21-4475-944e-f5911e1ab5c4" alt=""><figcaption></figcaption></figure>

You will notice that almost every binary that utilizes shared libraries will load our malicious one

<figure><img src="https://315180959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MRh03Vwd4nuiUi3Oje7%2Fuploads%2FzVGICGEAoo4sVowzrka1%2Fimage.png?alt=media&#x26;token=6e63d1df-228e-424f-a6c9-5dcb1ba2b782" alt=""><figcaption></figcaption></figure>

Now we can use the ld.so.preload file but this is a system shared object and will need root access, using this file is straightforward we create our so file then move it to the /etc/ld.so.preload location and when any application is running it will always use this one first.

<figure><img src="https://315180959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MRh03Vwd4nuiUi3Oje7%2Fuploads%2FMWfWM0qXuFKtplTQGiZo%2Fimage.png?alt=media&#x26;token=e57e023c-8d91-4ea4-be08-3029210015f8" alt=""><figcaption></figcaption></figure>

I've encountered errors since the library can't be preloaded, but this is what will happen with a correct functioning one, every application will try to load it with root level access.

<figure><img src="https://315180959-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MRh03Vwd4nuiUi3Oje7%2Fuploads%2FP0dHqqktFflQiDJ9izgn%2Fimage.png?alt=media&#x26;token=0ac0bf67-40fa-4db4-a81c-b63cc910c549" alt=""><figcaption></figcaption></figure>

Reference:

<https://www.getambassador.io/blog/code-injection-on-linux-and-macos>

<https://www.baeldung.com/linux/ld_preload-trick-what-is>
