Keylogging on Linux as a limited user

Servers don't usually run X and keylogging a server doesn't make too much sense.

 

Servers generally don't run X11... Because they generally don't need to, and, uh, because of stuff like what this thread is about.

 

I've never yet seen clear examples of how this can be accomplished. How does a browser exploit install one of these? It's always blogged about how it could be exploited but no step-by-step examples of how, exactly, it can be done. No wonder I'm always sceptical of these doomsday claims.

 

Wat, in terms of 'installing' a separate keylogger it would have to write files to the disk and entries to the registry (to get persistence). It would then execute at startup.

Of course it doesn't have to install. It can hide in the exploited processes virtual address space - we've talked about this before on the ssj forum so I don't think I need to reiterate how that works. You can do all of this keylogging stuff straight from the browser.

 

Registry? In Linux? Write files to disk? Why? You need a memory violation that leads to the execution of arbitrary commands.

What does it mean hide in the virtual address space? Where would it hide exactly? It's not like you it's a room where you hide stuff. In the worst case, you overwrite the base address of a register to point somewhere else. This of course requires a lot, which gets us back to science fiction.

You cannot do all that keylogging straight from the browser, and that's a ******** statement as generalized as pretty much every thread recently. And stop talking about things you do not understand.

Mrk

 

Still the user base logic doesn't apply here, a browser specific attack would target a browser regardless of the OS.

 

Yes, sorry, I was thinking in 'Windows' - the two separate topics that include the issue. With Windows you'd need to write to the registry to get persistence, to get the file to run at startup.

As for writing a file to the disk: if you want to install a file to the system (assuming this means get a program on the system) you have to write it to the disk - how else would it be possible? That's what installing is. There's no other way to get persistence without writing to the disk.

Obviously.

When I say hiding I mean remaining within the process. An attacker compromises a process, they live within that process.

Base address of a register? You overwrite a pointer or return address or some other useful area. Hardly science fiction - this happens quite often, even in the wild. Welcome to every buffer overflow attack against Flash and the like, or are we denying those exist now?

Yes, you can. Just as you can keylog straight from a terminal. This has been demonstrated before with xinput - it's obvious to everyone else, what exactly is keeping you in the dark here? What makes the browser magic and separate?

Please keep posting about things you don't understand though, it is endlessly entertaining. Or go on about how you work in IT therefor have the tools to understand this stuff better than the others lol I really don't have anything against you but don't be a dick, you're ****'s not that hot.

 

Another person added to the ignore list.
Mrk

 

I'd think someone in their... what?... 40s? (lol) would be a bit more mature. No real loss. I welcome that change.

Regardless, users can decide for themselves. I think history has proven that vulnerabilities do exist and are exploited no matter how many times you (for whatever reason) state otherwise. Claiming that any mention of vulnerabilities is "security theater" or "science fiction" is pretty silly.

 

Pure speculation that its limited user base.
I could claim its because of the entire Linux eco system, openness to the source code, bug tracking and community, the common package management systems and secure repositories.

 

Straight from a browser, without getting the user to run an exploit?
Either you are talking science fiction (relying on a hypothetical browser exploit) or its not as obvious as you claim, either way you are incorrect/inaccurate.

Obviously memory protection offered by most modern operating systems.

 

Yes in general, but we are talking specifically in the context of this topic.

Until you show us these browser based keylogging exploits then he is correct in that you are being fictional.

 

There are vulnerabilities, to not expect them is a delusion but the Open source system ensures that they are discovered early and patched faster than any so called closed source can ever match.

 

@Nick,

Hypothetical browser exploit? Pick one of the million already found, plenty of them give an attacker shell. And I'm absolutely not saying an attacker can do it without exploiting the browser, of course they need to. What I said is that the attacker can do this from a compromised browser process (or any other process with access to X). How are browser vulnerabilities science fiction exactly? The implication there is that they're not real... when they most definitely are.

Why is this unique to a browser? And since when have these made exploitation impossible? Yes, you can make exploitation more difficult but browser vulnerabilities still exist and they're still exploitable.

No - the attack is fictional and I've never ever said or implied otherwise. The vulnerability is absolutely not fictional.

Again, I'm not saying you will be keylogged and I'm not saying Linux keyloggers using this are out there. The only thing I'm saying is that the vulnerability exists and attackers can make use of it. That is all this topic has ever been about, Gullible Jones asked what was possible for an attacker to do.

The fact is that it is possible for a compromised process such as the browser to log keystrokes and denying this is flat out wrong. You can say exploiting a browser is difficult, you can say it won't happen, you can say whatever, but to say that this isn't true that a compromised process can keylog using X is to lie.

 

I hear this a lot, but I've yet to see any evidence to back it up.

(If anything I'd expect certain types of bugs to be found faster in closed projects, since the vendors actually have the resources to do regression testing, and other extensive testing.)

 

I think in terms of how easy it is to find bugs comparatively between closed and open projects it's a project by project basis. Some projects will be vetted and some won't be, open source doesn't magically mean people start looking it just means that they can start looking.

Look at TrueCrypt - it's open source but AFAIK there hasn't been a formal security audit. But then look at Chrome, it has so many security submissions by people who don't work at Google.

 

There is plenty of evidence from the mere fact that Linux and not any other operating system is in use for mission critical apps where security is the key to survival and functioning of the entire project. Closed projects not only don't have the means to find out their issues, but by their very nature are limited in resources and sphere, no amount of money can buy the open field period.

 

Other operating systems are used for mission critical applications (including Windows, in some cases). Linux is popular but it's not the only one.

How don't they have the means to discover their issues? Like I said, they do extensive testing. And yes, they are theoretically more limited, but in practice many of them are larger than their FOSS competitors - or can bring more resources to bear on a given amount of code.

 

Its popular in 95% and the rest are UNIX derivatives being phased out. Windows is not used in any of the supercomps. So Linux is just not popular, its THE system for supercomps and a hacker stands to gain way more that what he or she will if they were to hack a Joe Q. Public's Windows comp.

Extensive test in limited sphere and parameter is the bane of any research or development, closed source defines that.

 

Its up to you to backup up your claim or there is no evidence of fact (when there is no fact its fiction) - specifically browser exploits that gain shell access.

Correct.

I've never implied that. I am wanting information on which ones give shell access like you claim or else your entire effort of communication in this thread amounts to nothing but FUD.

I think we were talking at cross wires here, I was thinking browser, without an exploit, sorry.

OK.

Agreed, the difficulty, the small target (compared to Windows), the usually fast response to patching serious bugs from the Linux community is probably why its rare occurrence.

 

It seems silly to have to backup the claim that some browser exploits give shell. There are plenty for Firefox in Metasploit, I'm not going to track them down when we all know they exist.

Mrkvonic implies. What you're asking for is proof that something we all know exists does exist.

http://www.metasploit.com/modules/exploit/multi/browser/mozilla_navigatorjava
msf exploit(mozilla_navigatorjava) > set PAYLOAD generic/shell_reverse_tcp

There's a really quick google. Some of them require Java but the point is that you can set payloads for reverse_tcp_shell.

I thought it was clear I was talking about compromised processes.

I could have said it in other areas and been more explicit but I am only talking about the case where an attacker already has control of the process.

In a topic talking about local attacks I think the assumption should be the attacker already has remote access. There's no point talking about a local kernel privilege escalation exploit and needing to first address how the attacker got on the system, it's almost entirely irrelevant.

If we were actually doing some kind of risk assessment and trying to see a "whole picture" here that might be different, but we aren't, a very specific question was asked by GJ and that's what should be addressed.

 

Hungry Man, Thanks

 

An update: I am happy to say that I was completely wrong! Xephyr does provide some protection against keyloggers, but the isolation only works in one direction.

An example of what will not work:

Code:

$ echo $DISPLAY
:0.0
$ Xephyr :1
$ xinput test [number assigned to hardware keyboard]
blah blah blah keystrokes
...

Since the Xephyr server runs on top of the normal X server as a client window, keystrokes directed to it will be loggable in the main X session. Needless to say I am kicking myself for not understanding this the first time around...

However, this works:

Code:

$ Xephyr :1
$ export DISPLAY=:1
$ xinput test [number of any keyboard]
(crickets)

With the DISPLAY variable set to whatever number Xephyr is using, the hardware keyboard is not accessible. Keyloggers will not be able to log things going on in the main X session, or in other Xephyr sessions.

However, this is absolutely trivial to work around if you just run Xephyr as your user; or if you use a chroot sandbox as your user, and copy over the .Xauthority file (or provide access to your X session some other way). All an intruder would have to do is find out what the real X session's display number is, and set DISPLAY to that. For Xephyr to protect you, you have to make the main X session inaccessible from the application you're running in Xephyr.

Thus, a few options for foiling X keyloggers in Internet-facing programs:

1. Use a chroot sandbox with no .Xauthority token, or other means of connecting to your main display.

2. Use a separate user, as outlined here: https://www.wilderssecurity.com/showthread.php?t=333410

3. Use some kind of MAC system (Tomoyo? AppArmor?) to block the program's access to your main display. I'm not sure how hard that would be...

Main issues are the aforementioned ones with 'sandbox -X' - no copy/paste, no window resize, etc. Not sure if there's a way around that. Arkose Sandbox claims to provide GUI isolation with Xpra, and that at least allows window resizing; but I have no idea if the isolation really works as per Xephyr, and cannot test it right now.

So basically we're back to the old problem of "real" security being doable but inconvenient...

 

Okay, I would like to know if anyone has managed to do the following on Linux:

1. Logging keystrokes to a file. (Should not be hard, but xinput can't seem to do it.)

2. Logging keystrokes from another virtual terminal. (xinput can't do this.)

3. Logging keystrokes in the X session, without creating a visible window for the keylogger. (Invisible windows are fine though. ) I wasn't able to get this working because output redirection isn't working on xinput.