Re: concerned about keyloggers and user account security
Quote:
Originally Posted by
secret resistor
As I said the xinput binary is only used as a proof of concept, so it is not that relevant. What you need to block is the underlying calls or requests to the X server, otherwise you are not preventing the keylogger from obtaining the information. All your examples seem to be about running new processes (correct me if I'm wrong) which is not required for an exploited application to be recording keystrokes. And if the application is already allowed to make arbitrary HTTP requests (as firefox would be) than there is nothing stopping it from reporting the keystrokes to the attacker.
Yes, I realise that this may seem a bit offtopic but I still think it is relevant to the question of how to protect against a keylogger.
As I understand it, because the aa Firefox profile has this:
Code:
/usr/ r,
/usr/** r,
it can't run XInput. However, if the malware gets out of FF and onto the computer, it's free to do so, because it is unconstrained by Apparmor. The problem for the malware, as I said before, is:
1) How it gets onto the computer in the first place
2) How it launches
Because aa stops it from getting to anywhere it can self-start, it would have to be extra crafty or trick the user into running it. And that last option is the most likely, since it only depends on one vulnerability.
Re: concerned about keyloggers and user account security
Quote:
Originally Posted by
Larkspur
As I understand it, because the aa Firefox profile has this:
Code:
/usr/ r,
/usr/** r,
it can't run XInput. However, if the malware gets out of FF and onto the computer, it's free to do so, because it is unconstrained by Apparmor. The problem for the malware, as I said before, is:
1) How it gets onto the computer in the first place
2) How it launches
Because aa stops it from getting to anywhere it can self-start, it would have to be extra crafty or trick the user into running it. And that last option is the most likely, since it only depends on one vulnerability.
You don't need to run the xinput binary. As I said, any application can make the library call to the XInput extension (just like the xinput tool does) and obtain the keystrokes. And my question was can apparmor protect against that? And if so, what rule is needed?
EDIT: To be more clear, what I mean is if Firefox gets compromised it itself can start retrieving the keystrokes without running any other processes. Then it can report them to a web server somewhere. And the question was how to protect against that.
Re: concerned about keyloggers and user account security
Alright first of all thank you all for this discussion.
Since I dropped this bomb shell , allow me to clean it up a bit. The focus of my thread is strictly software security not physical. Let's assume hardware is safe and protected :smile:
Bodhi, your arguments make the most sense. Either way, I am a linux fan, and especially ubuntu fan and I have my reasons for it. First is my CS degree which introduced me to Linux filesystem and the use of B+ Tree as data structure which by the way I am very impressed by (due to Math not subjective arguments).
But then again, let's continue this discussion a bit in a healthy way and as for secret, please provide code/shell script examples like bodhi is providing to illustrate your point on XInput vulnerability. We do need to be practical so that we can have something more concrete to move on with what you are saying. If your examples can show (Even as a proof of concept) that it can be done in a given time and space, then we can discuss that further. Let's avoid hypothetical extreme arguments as bodhi pointed out using the plane example. Those will get us no where. Give us any type of mini example where the root access is not required to gain control and capture XInput. You may provide shell script, code (C++) or anything that is workable and then we will work together and analyze your code/example. This way, we can also gauge whether your talk has some skills to back it up or not. Sorry if this sounds hard to you but since we are on the internet forum, this is sort of necessary to keep the linux/ubuntu haters down (and no I am not saying that you are one).
P.S: Completely off topic, I wish to volunteer to help code small parts of ubuntu. I can invest 4-5 hours on a weekly basis. How do I volunteer with Canonical or Ubuntu team?
Re: concerned about keyloggers and user account security
Easiest method, using the xinput binary and without the key code to ascii conversion:
1. Run "xinput list" and look for something like "AT keyboard" and note it's id
2. Run "xinput test <id>" where <id> is the the id found in step 1.
3. Watch the events as you type anywhere (including sudo passwords or in apps running as root)
There is a perl script that automates this and converts the keycodes to ascii characters. I can post a link to it but I don't know if I'm allowed to do that on this forum.
I could also write a standalone C program that does the same, so no xinput binary is required but I don't see the point. If you want to know how it works just look at the xinput code.
P.S. I'm not a Linux/Ubuntu hater and I'm sorry if I've implied that in any way. I've been using Linux for over a decade and I do agree that overall it is more secure than Windows, just not when it comes the separation between processes using XWindows, which is the whole issue being discussed here. BTW, this is not really a Linux (as in Linux the kernel) problem but an XWindows one.
Re: concerned about keyloggers and user account security
Well, we would discourage such proof of concept discussions / posting of code here.
If you are interested in security take a look at apparmor and/or selinux ;)
Re: concerned about keyloggers and user account security
Quote:
Originally Posted by
bodhi.zazen
Well, we would discourage such proof of concept discussions / posting of code here.
If you are interested in security take a look at apparmor and/or selinux ;)
Ok. Thanks. I guess it's time to learn AppArmor. Does it use systrace?
Re: concerned about keyloggers and user account security
I just ran the xinput POC and here's my result:
Code:
jk@mehitabel:~$ xinput test 8
key release 36
key press 46
lkey release 46
key press 39
skey release 39
key press 37
key press 54
^C
The "8" was the ID of my keyboard; the 36 was release of the Enter key at the end of the "xinput" command. My typed input was "ls" and there's no obvious correlation to keys 45 and 39, although I suppose if the hypothetical intruder also had my keycode translation table he could figure it out. I'm not certain what the 37 refers to; I hit ctrl-C to interrupt the program so presumably the 37 and 54 are those two keys.
Bottom line: if the intruder has gained access by some other vulnerability, and knows my keycode translation (e.g. if I were using dvorak or some non-standard keyboard), then it's possible. However the risk is, IMO, vanishingly small.
Edit: just noticed that the key correlation is shown in the first character of each "release" line, for the two typed letter keys, so xinput does use the translation table. However it's still a vanishingly small risk IMO...
Re: concerned about keyloggers and user account security
Quote:
Originally Posted by
JKyleOKC
I just ran the xinput POC and here's my result:
Code:
jk@mehitabel:~$ xinput test 8
key release 36
key press 46
lkey release 46
key press 39
skey release 39
key press 37
key press 54
^C
The "8" was the ID of my keyboard; the 36 was release of the Enter key at the end of the "xinput" command. My typed input was "ls" and there's no obvious correlation to keys 45 and 39, although I suppose if the hypothetical intruder also had my keycode translation table he could figure it out. I'm not certain what the 37 refers to; I hit ctrl-C to interrupt the program so presumably the 37 and 54 are those two keys.
Bottom line:
if the intruder has gained access by some other vulnerability,
and knows my keycode translation (e.g. if I were using dvorak or some non-standard keyboard), then it's possible. However the risk is, IMO, vanishingly small.
Edit: just noticed that the key correlation is shown in the first character of each "release" line, for the two typed letter keys, so xinput does use the translation table. However it's still a vanishingly small risk IMO...
What you see at the beginning of each release line is just the local echo of the terminal (since you are typing in the same terminal you are using to start xinput). The attacker would not see this of course but the translation is always the same so it is trivial to figure out from the keycodes. Here is the mapping for the characters you typed:
36 = Enter
46 = l
39 = s
37 = ctrl
54 = c
This is always the same on every qwerty keyboard. For the full mapping you can google for the perl script since I'm not allowed to post it.
Yes, it would be different for dvorak but it should still be the same in every case and it would be trivial to figure out whether it is qwerty or dvorak based on which translation produces valid words.
The only thing the attacker needs is access to a vulnerability, whether the chance of that is "vanishingly small" is a matter of opinion as has become clear in this thread.