7 ms·
So first question came to mind: how do it inject code to processes? You need something for that: working exploit, CAP_SYS_PTRACE capability, you name it. Googli
by lelf 13y ago
So first question came to mind: how do it inject code to processes? You need something for that: working exploit, CAP_SYS_PTRACE capability, you name it. Googling reveals just bunch of stupid articles that don't mention what you need to “install” that trojan.
According to http://www.techrepublic.com/blog/linux-and-open-source/hand-of-thief-malware-could-be-dangerous-if-you-install-it/ http://www.techrepublic.com/blog/linux-and-open-source/hand-...
The good news is that Hand of Thief must have the root
(or sudo) password in order to install.
So how would it be? “Yow, just add this line to sources.list and run apt-get cool-hd-wallpapers-2013”?
Hello there. I'm the unix virus. Please sudo run me.
- chrissnell 13y agoThink about how much software is blindly cloned from Github and executed by the unaware without so much as a look at the source. That's only one vector.
- jvreeland 13y agoYeah but none of the software I blindly download from any source gets run as root.
- ZoF 13y agoI would argue that you're one of few in that case.... Many people download software(oftentimes from shiesty sources) and run as root... There are countless walk-throughs and tutorials that have 'sudo' in them.
- arjie 13y agoCan't guarantee that, can you? Say you run it as non-root and it sits there waiting for 'sudo * \n' and captures whatever you type after. Your non-root software could then execute itself with sudo using the password that it's captured.
- superuser2 13y agoDon't you need root to read keystrokes not being sent to you?
- laluser 13y agoI think what he is trying to say is that it could just emulate the terminal and read whatever is coming to it after it's executed. "Listening" for when the user types in sudo...
- claudius 13y agoThe easier way would likely be to add a "sudo" script somewhere in $PATH, ideally before /usr/bin – incidentally, this gets much easier on a development machine where people have a ruby path, a perl path, a python path and their own $HOME/bin.
- ori_b 13y agoNot under X11. See `xev -id $WINDOW_ID` for a demonstration. There's the XACE (X11 Access Control Extension) that tries to make it harder to snoop, but I don't believe that it's enabled by default in most distributions.
- jebblue 13y agoI tried this, I started gedit then xwininfo to get the window id then xev -id and then started typing in gedit. I saw event information but didn't see what characters were being typed so what's the point you're trying to make?
- FreeFull 13y agoI do see what characters are getting typed when I do the same thing. For example: KeyPress event, serial 28, synthetic NO, window 0x2000003, root 0x2b7, subw 0x0, time 322414662, (225,283), root:(1057,269), state 0x0, keycode 26 (keysym 0x65, e), same_screen YES, XLookupString gives 1 bytes: (65) "e" XmbLookupString gives 1 bytes: (65) "e" XFilterEvent returns: False
- dmytrish 13y agoThat's good, but http://xkcd.com/1200/ http://xkcd.com/1200/ is very relevant here. Writing a keylogger for X Window is just a few lines of shell script, assuming `xinput` is installed. X Window system just was not designed for running complex graphical environments, I suppose, and security inside it is quite weak (it does not protect root sessions in xterm in any way although xterm was one of the first X programs). Yes, `gksu`/`kdesudo` alleviate the situation (protecting passwords from being grabbed), but that's not a solution. E.g. it's easy to write a script that detects user's inactivity for some period and if a root session is here in the same X session, it just sends there any text. That's why I avoid sudo'ing in graphical environment and I always set 'targetpw' in /etc/sudoers to enable separate root account on Debian/Ubuntu.