33

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.

6
  • I believe this can be done at the X level easily. Just think about the programs with global shortcuts. Sep 5, 2011 at 19:53
  • 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 Sep 5, 2011 at 20:05
  • 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. Sep 6, 2011 at 1:44
  • 2
  • 4
    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. Nov 18, 2013 at 23:27

9 Answers 9

33
+100

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

17

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

11

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

8
  • 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. Jun 25, 2011 at 22:32
  • 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
    – bbaja42
    Jun 25, 2011 at 23:14
  • 1
    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. Jun 26, 2011 at 6:23
  • @Amazed valid point, but feel free to install lkl and test it on your own machine.
    – bbaja42
    Jun 26, 2011 at 6:30
  • 2
    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()!. Jul 6, 2011 at 2:47
10

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

2
  • See Law #1.
    – Iszi
    Nov 19, 2013 at 15:11
  • "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")...
    – gbr
    Aug 14, 2017 at 17:24
2

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.

1
  • The question says "without root or sudo".  How would an attacker modify a program in /bin without privilege? Apr 22, 2015 at 0:08
0

Yes, it is possible to install software without su or sudo privileges; however, this is typically done though a privilege escalation exploit. That video does a pretty good job of the capabilities of that keylogger, but it leaves out a bit of detail on the keylogger installation. There may be a bit of trickery here, but it's hard to tell from the video alone.

1
  • 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. Apr 22, 2015 at 0:03
0

For testing purpose, I created a TTY keylogger which can dynamically attach to a user's tty and the program doesn't need to be installed by root and can be used by any account. Once attached, it will log inputs that match the pattern given on command line when the program starts.

-2

If the system is not using full disk encryption a malicious user could boot with a live OS and install/configure whatever they want. It would likely require physical access, but being root of their system eliminates them being root of your system as they can mount your drive as root and install whatever exploit(s).

-4

Is is possible with systems like Crunchbang (Debian based distro) just add permissions to the sudoers file by using nano visudo in terminal and add keylogger to autostart like logkeys for Linux for example logkeys --start --output /home/user/.secret/log

Good luck

1
  • 5
    Root or sudo privilege is required in order to edit the sudoers file. Mar 12, 2012 at 14:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .