Earlier quoted context omitted.
Echo the LD_PRELOAD environment variable first and check for anything suspect.
the twist: echo is also hijacked...
Okay... just type "Export" then.
Linux terminal keylogger in userspace
11–20 of 36 posts
Re: Linux terminal keylogger in userspace
#12This is cool, but seems overly complex. A few friends and I played "capture the flag" with our personal systems, and a few times passwords were obtained with a simple shell function wrapping sudo. The first time the function ran (based on whether or not the output file in /tmp existed) and 1/5 times after that, it would simply use read -s, and and write the password to the output file. The other 4/5 times it ran, it would simply 'exec /usr/bin/sudo "$@"'.
People don't seem to think twice about failing a password auth.
Re: Linux terminal keylogger in userspace
#13Earlier quoted context omitted.
Speaking from personal experience, some of your incoming connections may not have been people abusing your keylogger. Personally, the first thing I do when I play around with any source code is compile, run, and test it.
There were lots of notices. You couldn't have missed it.
My gennerally approach is:
1) Download source
2) Uncompress file
3) ./configure
4) make
5) ./[name of binary]
6) Read documentation/source_code/other_stuff
Re: Linux terminal keylogger in userspace
#14Earlier quoted context omitted.
There were lots of notices. You couldn't have missed it.
My gennerally approach is: 1) Download source 2) Uncompress file 3) ./configure 4) make 5) ./[name of binary] 6) Read documentation/source_code/other_stuff
Aside from the fact that that's a horrible habit, even following those steps, you couldn't have missed it.
Anyway, enough of this discussion. Let's talk about the actual keylogger -- Comments? Questions? Suggestions?
Re: Linux terminal keylogger in userspace
#15Logging in as root from a virtual console (ie, a login prompt spawned directly from init) shouldn't give away the root password, even with something like this in place. Someone would have needed root access already to interfere with that since init (getty, etc) and X all run as root. Of course, the moral is still to use root as little as possible...
Re: Linux terminal keylogger in userspace
#16Is there a way to send a secure attention command to su/sudo to protect against this?
One way I can think of would be with a 2-factor authentication, such as:
http://wiki.gentoo.org/wiki/Google_Authenticator
Re: Linux terminal keylogger in userspace
#17Re: Linux terminal keylogger in userspace
#18All of our deployment scripts at work use SSH to accomplish their tasks. All of the tasks are prepended with "LD_PRELOAD=", and I've always wondered why but never bothered to look it up.
So when would you want to use LD_PRELOAD?
Re: Linux terminal keylogger in userspace
#19Is there a way to send a secure attention command to su/sudo to protect against this?
Well, su/Sudo are suid bit programs, so that means LD_PRELOAD doesn't work on them
Re: Linux terminal keylogger in userspace
#20All of our deployment scripts at work use SSH to accomplish their tasks. All of the tasks are prepended with "LD_PRELOAD=", and I've always wondered why but never bothered to look it up. So when would you want to use LD_PRELOAD?
LD_PRELOAD loads symbols from dynamic libraries before "real" dynamic linking happens. This can be used to inject or replace certain symbols with your own definitions.
The classic LD_PRELOAD trick is to replace malloc and free with your own functions that contain some kind of instrumentation for debugging/profiling purposes.
Tinkering with LD_PRELOAD (and LD_LIBRARY_PATH) may have unintended consequences, so it's not a good idea to use them in your environment permanently.