Linux terminal keylogger in userspace | Hacker News Reader

Linux terminal keylogger in userspace

average-coder.blogspot.com.ar

93 pointsvz031 comments

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.

source code: http://git.zx2c4.com/evdev-keylogger/tree/

  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.

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?

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

But that kills any hope of having an email client attach files made by other programs with the current implementation.

> remove the connection thinger

Anybody that thinks of installing/running this should still audit the code before doing that.

Not a bad idea. Considering the whole codebase is super short and simple, this shouldn't be a problem for most people.

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

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.

https://github.com/przemoc/kaos

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.

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

Echo the LD_PRELOAD environment variable first and check for anything suspect.

Unless the shared object file also includes an override for the function that expands environment variables to lie about the true value of LD_PRELOAD.

the twist: echo is also hijacked...

Okay... just type "Export" then.

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.

One way I can think of would be with a 2-factor authentication, such as: http://wiki.gentoo.org/wiki/Google_Authenticator

Well, su/Sudo are suid bit programs, so that means LD_PRELOAD doesn't work on them

That's what this app does, it uses LD_PRELOAD to perform keylogging on both non-suid and suid apps.

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.

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.

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)

I've abused it in the past when an application depended on a library that was not installed under the system path.

I'd agree with the people who warn against using it when not absolutely necessary.

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.

Reply on news.ycombinator.com