Linux terminal keylogger in userspace

This 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 "$@"'.<p>People don't seem to think twice about failing a password auth.

Here's a solid way to log actual keys from the keyboard (rather than just terminal input) using evdev. It's not good for, say, logging keys of a headless server, but it is good for logging keystrokes from a computer with a monitor and keyboard.<p>source code: <a href="http://git.zx2c4.com/evdev-keylogger/tree/" rel="nofollow">http://git.zx2c4.com/evdev-keylogger/tree/</a><p><pre><code> zx2c4@Thinkpad ~ $ git clone http://git.zx2c4.com/evdev-keylogger/ Cloning into 'evdev-keylogger'... zx2c4@Thinkpad ~ $ cd evdev-keylogger/ zx2c4@Thinkpad ~/evdev-keylogger $ make cc -O3 -march=native -fomit-frame-pointer -pipe logger.c keymap.c keymap.h evdev.c evdev.h process.c process.h -o logger zx2c4@Thinkpad ~/evdev-keylogger $ ./logger -h Evdev Keylogger by zx2c4 Usage: ./logger [OPTION]... -d, --daemonize run as a background daemon -f, --foreground run in the foreground (default) -u, --force-us-keymap instead of auto-detection, force usage of built-in US keymap -e DEVICE, --event-device=DEVICE use event device DEVICE (default=auto-detect) -l FILE, --log-file=FILE write key log to FILE (default=stdout) -p FILE, --pid-file=FILE write the pid of the process to FILE -n NAME, --process-name=NAME change process name in ps and top to NAME -h, --help display this message </code></pre> It has the ability to daemonize, log to a file, and mask itself in the process table. Far from what a real kernel rootkit logger could do, but instead it's clean and reliable.<p>I used to actually have this in my git repository with a little thing in there that would connect back to my server when run, and then I had a README and notices all over in the source code and makefile and everywhere that you should remove this part of the code before compiling, under all circumstances. Anybody reasonable would have seen the notices and removed the code. The idea was that this way I'd know how many script kiddies were abusing it, and if maybe it was a bad idea to keep it up there. Well, in fact I did get a lot of connections, and it was kind of horrible to see. Then I forgot about it, until seeing this post. So I figured, either I take it down, because script kiddies, not people who are merely curious to see how a key logger works, are using it, or I keep it up there. In the end, I decided to stop being a dick, remove the connection thinger, and now the HN crowd will hopefully find something interesting to learn in it. A failed experiment at dealing with the script kiddie situation, oh well. At least, now, my code is untainted.<p>Anyway feel free to email me or leave a comment here if you find any bugs or have patches, or whatever. The code should be pretty basic to understand.

Trapping fork/execve is probably overkill here. Since the user will often just type su or sudo, all that 'malware' needs to do is modify PATH

Logging 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...

Isn't is curious when OS's don't keep track of non-system software ... when it's installed, what process installed it, whether that process was under local control, any other info to indentify the source ... and to list that information on demand any time any user wants it?<p>What's up with that? It's as though we're happy that we can be infiltrated at any time. It's not like people don't put weeks and months into "me-too" websites ... but there's never been any major motion in the direction of making the existence of surreptitious mods available at a key-click?<p>Such apps may exist, but I've never run across one for any platform explicitly designed to help anyone root out what's been installed without their knowledge. It CAN'T be that hard. Link it up to an open online knowledge-base that will nix false flags ...

My old and somewhat related PoC project for screen casts, but still working. Just checked (debian wheezy with stock kernel 3.2.0-4-amd64). It requires building and loading simple kernel module, though.<p>Apparently nowadays debugfs is owner-only rw, so you have to change it or start it as root.<p><a href="https://github.com/przemoc/kaos" rel="nofollow">https://github.com/przemoc/kaos</a><p>Look for the top-right corner to see the effect while you're typing or clicking something.<p>P.S. Funny thing is that I don't know why I wrote &#62;&#62;Kprobe dependency can be easily removed by writing own input handler and it will be done in future&#60;&#60; back then, because when I evaluated this statement year or so ago, it didn't look that easy, and there would be more code in the end, I suppose.

Is there a way to send a secure attention command to su/sudo to protect against this?

All 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.<p>So when would you want to use LD_PRELOAD?

If I recall correctly Magic SYSRQ offered the ability to kill all running processes using a shortcut impossible to bypass (along with other shortcuts, like one for killing the X server 'no question asked' and no possibility whatsoever by X to dodge the kill -9).<p>So basically you had to go first to a virtual console (in text mode) and then issue the Magic SYSRQ shortcut.<p>That would kill all processes running on that console and you'd be sure to have a stock prompt without any kind of software keylogger.<p>I don't know if Magic SYSRQ still exists or not for 64-bit Linuxes, it's been a while I haven't used it.