Show HN: keysniffer – Linux kernel module to log pressed keys in debugfs | Hacker News Reader

Show HN: keysniffer – Linux kernel module to log pressed keys in debugfs

github.com

40 pointsapjana15 comments

> The module name has been crafted to blend-in with other kernel modules.

> keysniffer is intended to track your own devices and NOT to trespass on others.

This sounds inconsistent...

I agree. Maybe he's implying something about linux being multi-user.

Hi, I am the OP and the author of the module. I had been in a situation where I wanted to track if my system was being used without my knowledge. I had my reasons. The person whom I suspected had reasonable hold on Linux. So I though it would be best to camouflage the module. `kisni` was influenced by `aesni_intel`.

If you only need a logger for X11, but want it to be layout-agnostic, I wrote one of those: https://github.com/anko/xkbcat It doesn't even need sudo, perhaps because X11 was written by hippies. :)

You can counter this by creating a hook to scramble keys as they are typed. There are countless antiloggers out there and they're the first thing I install on any fresh distro. Why this antilogging technique is not the default in most so called 'hardened' systems is beyond me. Really low hanging fruit like the ability to log keys should be looked after first and not addressed at some future date when you realize 20+ years of keystrokes were siphoned off your machine.

Aren't anti-antiloggers equally easy to write? Countering an example keylogger is easy, but countering a production-ready keylogger, assuming that keylogger actually gets to load itself as a kernel module, doesn't seem like low-hanging fruit.

What's the threat model you have where evil kernel modules are installed on your machine, yet they don't do things like siphon off your files, read passwords out of the memory of running processes, add entries to /root/.ssh/authorized_keys if and only if the current process's name is "sshd", etc.?

In terms of a threat model, it includes any machine which acts as a hypervisor and as the old saying goes: If you don't trust the hypervisor, how can you trust any machine running in that hypervisor?

Antilogging is but one tiny component of defense in depth and worth investigating if you're doing anything interesting with a computer. 'Doing something interesting' although is not to be misconstrued as 'doing something bad'. It just means how can any meaningful work get done if low hanging fruit like keystrokes can (and are) being siphoned off?

It helps to see how machines are actually being compromised like this...I've seen it on my machine and sometimes entire office building are being siphoned like this. I typically report this, but I would much rather get to the root as to how it's possible in the first place :(

Huh, that doesn't match my intuitions at all (at least on UNIX-based OSes), so I'm pretty surprised and want to re-adjust my expectations. You're saying that you regularly see compromised machines that are running kernel-mode keyloggers, but only keyloggers? What has the attack vector been, and do you know where they keys are being logged to?

What do you mean by that? If you scramble the keys as they enter the input system then you can't write anything. If you want the user to be able to use use the keyboard then you can also read what's getting sent to userspace.

Typically we don't want the userspace to be compromised at all. An antilogger works by effectively substituting letters as they are typed. So when I type 'A', it is read as A in the kernel, but backspaced, replaced by a random letter, and then the real `A` appears on screen by means of hijacking the input form.

For the pedants:

Some more advanced antiloggers are minus ring-0 and physically remap the keys so that `A` doesn't mean A at all. Infact if I typed this, a load of garbage would be displayed on the screen. The only reason we see valid output is because of a software abstraction layer translating the 'garbage' back to it original symbolic meaning. This is how we thwart such a kernel logger as described in this thread.

cat /dev/input ?

would that yield the same? (i am not able to try it at the moment)

Not really - in part because /dev/input is a directory, and in part because I _believe_ reading from /dev/input consumes the event, which would be less than ideal for a silent keylogger. ;)

(/dev/input/XXXX also gives more structured output than just raw key events IIRC.)

You can actually read keypresses from /dev/input/eventN to make a keylogger, I wrote a simple one in lua.

I sit corrected, thank you.

Reply on news.ycombinator.com