UPDATE: my conclusions were wrong, please see below: https://www.wilderssecurity.com/thre...enign-uses-of-ld_preload.370957/#post-2433705 Preparation: 1. Fire up Backbox Linux and Metasploit in a VM 2. Set up the XPI social engineering attack Control: 1. Point a normal Firefox session at the Metasploit server 2. Click 'Accept', let the meterpreter session start 3. Run a bunch of information gathering modules. Expected result: they all run to completion and gather lots of information. Actual result: ditto. Experiment: 1. Put this in a C source file, say 'binblock.c' Code: #include <unistd.h> #include <sys/types.h> #include <signal.h> #include <sys/ptrace.h> extern int execve(const char *filename, char * const argv[], char * const envp[]) { return 0; } extern int kill(pid_t pid, int sig) { return 0; } extern long int ptrace(enum __ptrace_request request, ...) { return 0; } and compile it with 'gcc -fpic -shared -o binblock.so binblock.c' or suchlike. 2. Start Firefox with 'LD_PRELOAD=/path/to/binblock.so /usr/lib/firefox/firefox' 3. Point it at the Metasploit server, click 'Accept', etc. 4. Run the information gathering modules again. Expected result: most stuff works, maybe some fails. Actual result: all information gathering attempts fail, bar none. This includes VM detection, enumerating device info, grabbing user readable config files, using CUPS access to grab a copy of /etc/shadow, grabbing SSH keys... Everything short of direct kernel exploits (which I only skipped because none were available). ... VERY TENTATIVE conclusion: automated info gathering attacks against Linux desktops don't work so well when exploitable POSIX API functions are cut off at the knees, even if the cutting off is done strictly from userspace via LD_PRELOAD hacks. This seems to apply especially to blocking ptrace, assuming comparisons of execve() to Windows' NtCreateProcess() are at all useful. A further note: despite blocking ptrace and execve, Youtube videos still played in Firefox. This is good, but also suggests to me that a trojan compiled as a shared object library might be able to bypass the hack. Even so - plugins continued to work, while every info gathering attempt either failed immediately or hung indefinitely. I must continue to stress that fooling around with LD_PRELOAD like this is the definition of a crude hack. But by results, this crude hack worked quite well at blocking payloads. ... And now the cool part: AppArmor lets you block execve and ptrace, and from the kernel rather than from userspace. AppArmor also ships on most distros by default. So I would suggest that users forego kludgy LD_PRELOAD hacks, and instead set up AppArmor profiles to block execve and ptrace on network facing applications such as Firefox, chat clients, etc. Even the most minimal profile, with no restrictions on filesystem access, might be enough to block automated information harvesting attempts. Hope everyone finds this interesting...
Thanks GJ. This is quite a bit out of my league, but I think I get the gist of it. My Firefox Apparmor profile has: capability sys_ptrace, ...so if I deny this it won't break anything? BTW, I rarely use Firefox, using Chromium instead, and it has an entry: /proc/sys/kernel/yama/ptrace_scope r, ...this, I believe, is important as it then enable the Yama LSM enforcing sandbox.
@wat0114: Chromium's sandbox already denies almost everything via seccomp. For the Firefox profile, yeah, you should be able to deny ptrace without breaking anything.
Update, @wat0114: actually CAP_SYS_PTRACE seems to be for ptracing arbitrary processes, including those of other users. Firefox should never ever run with such a capability, it's basically equivalent to root. I'll investigate the AppArmor side of things further, not sure why on Earth you'd have CAP_SYS_PTRAcE allowed in a Firefox profile... Edit: and, all, a further update - the Yama LSM provides a better way of blocking ptrace. https://www.kernel.org/doc/Documentation/security/Yama.txt
It was just one of those things that came up while I was building the Apparmor profile for Firefox using sudo aa-logprof, and of course with my very limited Linux knowledge, I had no idea what it was, so I just allowed it read rights when it came up during the profiling. i will delete the entry which will effectively default deny it and see what happens. If nothing breaks, I'm good to go Thanks again!
No prob, hope I'm not way off on this... :/ Meanwhile my advice for Linux users is that, if you do not need to debug programs as a limited user (i.e. almost all end-users), you should turn off ptrace for limited users: Code: # echo 'kernel.yama.ptrace_scope = 2' >> /etc/sysctl.conf # sysctl -p Note that ptrace scope restriction is already partially enabled on Ubuntu 14.04 (the default value is 1, which prevents most attempts at ptracing non-child processes).
On my openSUSE desktop here... The first command took for me but the second command returns: Code: kernel.sysrq = 0 net.ipv4.ip_forward = 0 net.ipv4.tcp_syncookies = 1 net.ipv6.conf.all.forwarding = 0 sysctl: cannot stat /proc/sys/kernel/yama/ptrace_scope: No such file or directory EDIT on my Ubuntu-based Linux "Lite" setup, it seems to work: Code: net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv6.conf.all.accept_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv6.conf.all.accept_source_route = 0 kernel.yama.ptrace_scope = 2
Okay @wat0114 and everyone else - sorry, I was completely wrong about ptrace. I should have tested the two stub functions indepdently! In fact, Metasploit seems to make little or no use of ptrace; on Linux, blocking execve() alone is enough to stop almost its entire arsenal of information gathering. This can again be done quite easily with AppArmor, by denying exec privileges on most or all of the filesystem. Furthermore AppArmor lets you make exceptions for things like Google Hangouts plugin if needed... So, again: use AppArmor! What's funny about this, is that the same approach on Windows - blocking execution syscalls - is almost useless against Metasploit. I have no idea where the difference comes from.
No worries, GJ, thanks for your efforts in this area. Should I set ptrace_scope back to the default of 1 or will it be ok to keep at 2?
@wat0114, it shouldn't matter either way unless you are debugging userspace programs on a regular basis.
More FWIW: blocking fork() and vfork() also seems to put the kibosh on most Metasploit attacks; but I'm not trusting that, since it should be possible to just use exec* to replace the target app. Also multithreaded apps still work with those calls blocked, so I think there are other methods of spawning child processes, that an attacker might be able to use. I'm starting to think most of the canned Metasploit attacks are woefully primitive. (Well, no kidding?)
Also, another reason not to do this with an injected library: http://www.stratigery.com/userlandexec.html Yes, it's possible to spawn a new process without relying on the kernel. Not sure if AppArmor will block that, but I guarantee you a preloaded library won't.
