Linux terminal keylogger in userspace

http://average-coder.blogspot.com.ar/2012/02/linux-terminal-keylogger.html

by vz0 • 14 years ago

93 31 14 years ago

average-coder.blogspot.com.ar

bcoates• 14 years ago

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

iopuy2• 14 years ago

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

lordlicorice• 14 years ago

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.

est• 14 years ago

the twist: echo is also hijacked...

AYBABTME• 14 years ago

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

Spidler2• 14 years ago

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

pea-tear• 14 years ago

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

zx2c44• 14 years ago

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.

gizmo6862• 14 years ago

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.

zx2c44• 14 years ago

There were lots of notices. You couldn't have missed it.

jacquesm• 14 years ago

> remove the connection thinger

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

zx2c44• 14 years ago

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

charliesome• 14 years ago

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

subway• 14 years ago

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.

gst• 14 years ago

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.

vy8vWJlco• 14 years ago

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

csense• 14 years ago

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.

SoftwareMaven• 14 years ago

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?

exDM69• 14 years ago

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.

Spidler2• 14 years ago

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)

wtracy• 14 years ago

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.

przemoc• 14 years ago

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.

martinced• 14 years ago

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.

teeja• 14 years ago

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

Linux terminal keylogger in userspace

Related Stories