Linux keylogger without root or sudo! Is it real?

Question

Somebody on Youtube claims to have a keylogger on Ubuntu that was neither executed nor installed as root. The link below shows a demo of it working.

http://www.youtube.com/watch?v=Y1fZAZTwyPQ

Despite their claims to the contrary, this person could have installed it as root before demonstrating for the video. Is there any other semi-credible evidence that this is really possible without root for installation or execution?

UPDATE: The software referenced in the June 24 answer wouldn't install without sudo/root. I've added a bounty to whoever gives a link to a working Linux keylogger software that can be installed and run with regular user privileges.

Solution 1

Yes, it is real. If you have been exploited (via an open source supply chain attack, browser vulnerability, email attachment etc.) and an attacker can run code with your user privileges, they can register a program via GNOME or KDE autostart facilities which run programs on login.

Any program can get the scan codes of all pressed keys in the X Window System. This is easily demonstrated with the xinput command:

$ xinput list
# identify the ID of your keyboard device
$ xinput test <that id>

If nothing shows up, change the id to another one in the list.

See this post on GUI isolation for details, by a core contributor to Qubes OS, the only OS designed from the ground up to mitigate this risk (and many others).

Solution 2

The concept in that video is 100% real and the code is very simple.

Identify your keyboard id with: xinput --list

Log keystrokes with: xinput --test $id

Match numbers to keys with: xmodmap -pke

Solution 3

Yes it is possible.
You can try it on your own machine with similar software lkl .

Solution 4

I haven't watched the video, so I'm responding to the impression I got about what it claims from the SU thread rather than the video you cite.

If an attacker can run code on your machine as your user, then they can log your key presses.

Well, duh. All the applications you're running have access to your key presses. If you're typing stuff in your web browser, your web browser has access to your key presses.

Ah, you say, but what about logging key presses in another application? As long as the other application is running on the same X server, they can still be logged. X11 doesn't attempt to isolate applications — that's not its job. X11 allows programs to define global shortcuts, which is useful for input methods, to define macros, etc.

If the attacker can run code as your user, he can also read and modify your files, and cause all kinds of other harm.

This is not a threat. It's part of the normal expectations of a working system. If you allow an attacker to run code on your machine, your machine isn't safe anymore. It's like if you open your front door and allow an axe murderer in: if you then get cleaved in two, it's not because your front door is insecure.

The keylogger can only log keys pressed by the infected user. (At least as long as the infected user doesn't type the sudo password.)

Solution 5

It is 100% possible. For ttys/ptys (text mode), the easiest way is to add a shim to /bin/{ba,da,a}sh (e.g., a second .code segment, R-X) and change the entry point (much as an ELF virus would). Barring access to that in this case, one can modify ~/.profile or ~/.bashrc (etc.) to, as a very simple hypothetical model:

exec ~/.malicious_programme

which may load dynamic shared object code to hide the malicious programme in question (example: allow .profile read and modification, but hide the line. And/or hide the programme.)

One may then use the UNIX98 pty(7) system or even simply pipe(2) to record all input in a forked shell, assuming the fd is not marked FD_CLOEXEC, and even change user input to the shell.

In X11, although kdm/gdm/xdm run as setuid root (or the equivalent in capabilities [see setcap(8)] or whatever security model you're using if non-default), things become more complicated, obviously. If one can elevate privileges? iopl(2) or ioperm(2) makes life quite easy with direct access to 0x60 / 0x64 keyboard ports on x86. Since we're assuming you can't, we must look for an alternative route. I know of several, but I am not entirely sure you want a dissertation on how it's possible and the interfaces involved.

Suffice to say, ring 3, non-superuser trojans are quite possible on *nix, in spite of process isolation, as a result of various issues (particularly with X) that has added features for user-mode daemons to provide, e.g., text-to-speech support for all apps w/o compromising the system's security. I already outlined one that works analogously to ttysnoops (which is long past its expiry date), and it does not require root. I have sample code for this case (which would include inside terminals in X), but I have not as-yet published it. If you want more information, please feel free to contact me.

View more solutions

Comments

[Denis Nikolaenko]

To prevent X window system keyloggers, you need to implement SELinux for X. To my knowledge, no wide spread Linux distribution does that out of the box. nsa.gov/research/_files/selinux/papers/x11/t1.shtml

[Mike Rowave]

Do you know of any actual working examples? Without seeing it work first hand, I remain skeptical. And without knowing that it's really possible for a keylogger to get installed without sudo/root privileges, it's not worth it to deal with the complexity of setting up AppArmor or SELinux to defend against it.

[Denis Nikolaenko]

theinvisiblethings.blogspot.com/2011/04/…

[Xenoactive]

I see that no one has submitted a working proof of concept yet. On a properly configured Linux system where device permissions are properly set, the methods to install a keylogger will require either authorized privilege escalation via su/sudo or unauthorized privilege escalation via a vulnerability.

[Gilles 'SO- stop being evil']

Please summarize the important points of the video in your answer. It could be deleted, or the server could become unavailable. (Yes, as I'm posting, Youtube is down.) It's also rather rude to require that visitors watch a video to figure out what your question is about.

[Mike Rowave]

It's scary if it's real. I'm going to set up a virtual machine in which to test it. But then the next puzzle is how to immediately detect it if it somehow installs itself through a browser exploit or something like that, or at least proactively block it from transmitting anything to the Internet if it runs.

[bbaja42]

I have little knowledge in the area, but wiki.ubuntu.com/SELinux might help. Feel free to update the original question with your findings. :D

[Andrew Lambert]

Hard to say hoax, real, or less-than-it-seems from a video alone. I can already think of places to start if I wanted to make a video supposing to demonstrate a huge vulnerability (suid tricks, sudo timeouts, adulterated system tools, etc. ad nauseum.) By no means is Linux invulnerable to attack, to claim otherwise is foolish. But one can't draw conclusions based on Youtube videos.

[bbaja42]

@Amazed valid point, but feel free to install lkl and test it on your own machine.

[Mike Rowave]

From what I've read about SELinux and AppArmor, either could be configured to prevent a keylogger from transmitting to the Internet. However, they are sooooo low-level and granular, requiring you to create and edit dozens of configuration files, dozens of lines each. You can't just tell it "programs A, B, C can connect to the Internet, nothing else can't" like with Windows firewalls. I don't have the time or patience to learn the operating architecture of SELinux/AppArmor and the syntax of their files. Much easier to use an old PC and set it up as a proxy with authentication.

[bbaja42]

@Amazed, video didn't not show which program was used, so I don't know if the lkl was used. But the general idea of the video is correct, and can be verfied with the use of lkl

[Mike Rowave]

It didn't work. Running make install produced the error cannot create regular file '/usr/local/bin/lkl': Permission denied. Running sudo make install didn't give the error, but then trying to actually run lkl gave another error Have to be root to perform a iopl()!.

[Mike Rowave]

Root or sudo privilege is required in order to edit the sudoers file.

[Iszi]

See Law #1.

[G-Man Says 'Reinstate Monica']

You're twisting words.  It may be possible to install software into a system directory without running su or sudo, but a privilege escalation exploit would give the attacker root privilege — a.k.a. "superuser" or "su" privilege.

[G-Man Says 'Reinstate Monica']

The question says "without root or sudo".  How would an attacker modify a program in /bin without privilege?

[gbr]

"Not allowing an attacker to run code on your machine" is a great security model... I guess Windows becomes perfectly secure when it's used by a a Linux user then (who for sure wouldn't "allow an attacker to run code")...