Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 51

Thread: concerned about keyloggers and user account security

  1. #21
    Join Date
    Apr 2011
    Beans
    190

    Re: concerned about keyloggers and user account security

    Quote Originally Posted by secret resistor View Post
    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.

  2. #22
    Join Date
    May 2011
    Beans
    20

    Re: concerned about keyloggers and user account security

    Quote Originally Posted by Larkspur View Post
    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.
    Last edited by secret resistor; May 28th, 2011 at 11:58 PM.

  3. #23
    Join Date
    Apr 2011
    Beans
    52

    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

    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?
    Last edited by gpost3; May 29th, 2011 at 06:02 AM.

  4. #24
    Join Date
    May 2011
    Beans
    20

    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.

  5. #25
    Join Date
    Apr 2006
    Location
    Montana
    Beans
    Hidden!
    Distro
    Kubuntu Development Release

    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
    There are two mistakes one can make along the road to truth...not going all the way, and not starting.
    --Prince Gautama Siddharta

    #ubuntuforums web interface

  6. #26
    Join Date
    Sep 2006
    Beans
    7,419
    Distro
    Lubuntu Development Release

    Re: concerned about keyloggers and user account security

    Quote Originally Posted by bodhi.zazen View Post
    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?

  7. #27
    Join Date
    Sep 2007
    Location
    Oklahoma, USA
    Beans
    2,191
    Distro
    Xubuntu 14.04 Trusty Tahr

    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...
    Last edited by JKyleOKC; May 29th, 2011 at 05:05 PM. Reason: updated observation.
    --
    Jim Kyle in Oklahoma, USA
    Linux Counter #259718
    Howto mark thread: https://wiki.ubuntu.com/UnansweredPo.../SolvedThreads

  8. #28
    Join Date
    May 2011
    Beans
    20

    Re: concerned about keyloggers and user account security

    Quote Originally Posted by JKyleOKC View Post
    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.
    Last edited by secret resistor; May 29th, 2011 at 06:31 PM. Reason: typo

  9. #29
    Join Date
    Sep 2006
    Beans
    7,419
    Distro
    Lubuntu Development Release

    Flash

    Quote Originally Posted by secret resistor View Post
    The only thing the attacker needs is access to a vulnerability.
    That's where Flash comes in ...

  10. #30
    Join Date
    May 2011
    Beans
    20

    Re: Flash

    Quote Originally Posted by Lars Noodén View Post
    That's where Flash comes in ...
    Yes, good point. Our example here has been Firefox but historically Flash has been a much bigger problem. Also, considering that the main thing the bad guys are after is banking information and credit cards, if they compromise your browser they can probably figure this out without a keylogger. If they compromise flash though (or any other software ridden with security holes) then turning it into a keylogger would be the primary concern.

    As for protection: after some more thinking I realized that blocking the library calls does not in fact solve the problem, although it makes exploitation quite a bit more difficult. The compromised application can just use its socket to the X server (or open a new one) to ask for the keystroke events. So, I think the only real way to protect against this would require tight integration with the X server so that applications that do not have focus cannot receive such events.

    From what I have read about AppArmor it seems that it can neither block the library calls nor is it integrated with the XWindows enough to solve the problem. So, I don't see how AppArmor can do anything here besides making it more difficult to make the keylogger permanent (as already discussed). But I would love to be proven wrong on this, so if there are any AppArmor gurus here please correct me.

    SELinux does seem to be integrated with XWindows enough to do the job but that is just based on skimming over the documentation / examples so I'm not sure yet if and how exactly it can be used to address this. I will try it when I have some more time and post the results but if somebody more experienced in SELinux wants to help, please feel free to do that.

Page 3 of 6 FirstFirst 12345 ... LastLast

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •