

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

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

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

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

~~~
gizmo686
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

~~~
zx2c4
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?

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

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

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

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

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

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

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

------
SoftwareMaven
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?

~~~
Spidler
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)

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

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

~~~
est
the twist: echo is also hijacked...

~~~
iopuy
Okay... just type "Export" then.

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

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

