-
Notifications
You must be signed in to change notification settings - Fork 195
Anti Detection
- A somewhat more reliable and in-depth method of detecting LD_PRELOAD malware is by using the functions from libdl to check and compare symbols and their addresses in the current process.
- By comparing symbol addresses, we're able to tell if a symbol has been hooked by malware or not.
- detect_preload.c uses dlsym to resolve symbol addresses, and then compares the current symbol address to the address of the same symbol in libc.
- If the addresses do not match, then something is causing another new(er) symbol to be called.
- vlany hides from this kind of detection however by hooking the libdl symbols responsible for detecting LD_PRELOAD malware.
To hide from any possible detection, vlany temporarily uninstalls itself from the system until said process is finished. Since this won't work for normal users, as they can't remove any root-owned files, sensitive applications are broken for non-root users - as you'll see below.
By checking for execution of specific binaries, we can hide from just about any application that we deem necessary.
This also applies to any rootkit detection tools - rkhunter, chkrootkit, etc.
ldd outputs any shared libraries being loaded for a specific binary in userland. This is usually a quick way to catch any LD_PRELOAD malware on a box, but vlany makes it less easy.
root@debian:~# ldd /bin/echo
linux-vdso.so.1 (0x00007ffe66ed8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3705998000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3705d48000)
root@debian:~#
This is the libraries that are expected to be loaded. /bin/echo is a very small binary, so only the minimal, default libraries are required.
tmp@debian:~$ ldd /bin/echo
-bash: /usr/bin/ldd: /bin/bash: bad interpreter: Input/output error
tmp@debian:~$
Since normal users cannot remove any root-owned files, we need to conditionally and carefully prevent execution of some commands - until of course they're run by root. If any user could run these tools, the current process wouldn't have the correct permissions on the system to remove the preload file and rewrite it when done.
root@debian:~# ldd /bin/echo
linux-vdso.so.1 (0x00007ffcf2f80000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd4a2658000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd4a2a08000)
root@debian:~#
As you can see, the output that ldd provides is the exact same to the expected output. That's because execve was being called as root, and we can open, write, read and remove any files we need to. Once the process is finished, the preload file is rewritten and it's like nothing even happened. vlany just isn't installed for this very short period of time.
It's not all positives either. A background process could exploit this feature of vlany, so that it's never installed. Something as simple as while true; do ldd /bin/echo; done
in bash will temporarily break vlany until all the ldd processes are killed.
- By modifying the dynamic linker libraries, we can make it more of a challenge for whoever's looking for us.
- Usually, LD_PRELOAD malware relies on /etc/ld.so.preload to globally load their library into userland.
- vlany's patch_ld.py patches any "/etc/ld.so.preload" strings in the libraries and changes them to a new, random file location string.
- Essentially, we change the location of the global library preload file.
root@debian:~# cat /etc/ld.so.preload
cat: /etc/ld.so.preload: No such file or directory
root@debian:~# echo "/some/lib/path.so" > /etc/ld.so.preload
root@debian:~# cat /etc/ld.so.preload
/some/lib/path.so
root@debian:~# rm /etc/ld.so.preload
root@debian:~#
- As you can see, we can open, read, write, and remove the regular /etc/ld.so.preload file, and it has zero functionality after installing vlany.
- In the case of this installation, the 'actual' preload file is now pointing to '/sbin/.Zappyn7R', and the contents read "/lib/libc.so.mempodippy.85/KsPBjB6zibXU.so.$PLATFORM" - as that is indeed the location of the rootkit libraries.
- Of course, I only know this because I searched for it from the PAM backdoor owner shell.
root@debian:~# cat /sbin/.
./ ../
root@debian:~# cat /sbin/.Zappyn7R
cat: /sbin/.Zappyn7R: No such file or directory
root@debian:~# rm /sbin/.Zappyn7R
rm: cannot remove ‘/sbin/.Zappyn7R’: No such file or directory
root@debian:~#
- Back on a regular root account, we can see that the new preload file is also hidden from userland. Only those with access to an owner shell can see this file.