[Xrdp-devel] rate limit keyboard input

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Xrdp-devel] rate limit keyboard input

Steve Gula

My security people are concerned about a particular attack vector and we haven't found anything on Google to help. I'm hoping someone here can -

The concern is if someone is remoting into a machine we have 'locked down' (stripped out a lot of packages/etc) and then they copy/paste or use a keyboard emulator to retype an entire application into the remote machine. For instance:

Local machine:
Take executable binary and convert to hexadecimal for easy copy/paste
Install software that emulates keyboard and will retype entire contents of the local machines clipboard (because we disabled copy/paste in xrdp)
connect to remove machine and create a file in remote home directory
Let software/keyboard emulator start retyping the entire executable


We think doing a keystroke logger on the remote end and pumping the logs somewhere could help monitor part of it. But we'd really like to rate-limit the incoming keystrokes because if the attacker aims too high (re: large exploit file size) then we can at least delay the inevitable and hope we notice in time. Particularly on the system in place where keystrokes would be very minimal (essentially a kiosk driven largely by mouse clicks).

Any thoughts or input would be appreciated.


------------------------------------------------------------------------------

_______________________________________________
xrdp-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xrdp-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xrdp-devel] rate limit keyboard input

jsorg71
Hi Steve,

> The concern is if someone is remoting into a machine we have 'locked down'
> (stripped out a lot of packages/etc) and then they copy/paste or use a
> keyboard emulator to retype an entire application into the remote machine.
> For instance:
>
> Local machine:
> Take executable binary and convert to hexadecimal for easy copy/paste
> Install software that emulates keyboard and will retype entire contents of
> the local machines clipboard (because we disabled copy/paste in xrdp)
> connect to remove machine and create a file in remote home directory
> Let software/keyboard emulator start retyping the entire executable
>
>
> We think doing a keystroke logger on the remote end and pumping the logs
> somewhere could help monitor part of it. But we'd really like to rate-limit
> the incoming keystrokes because if the attacker aims too high (re: large
> exploit file size) then we can at least delay the inevitable and hope we
> notice in time. Particularly on the system in place where keystrokes would
> be very minimal (essentially a kiosk driven largely by mouse clicks).
>
> Any thoughts or input would be appreciated.

That is an interesting concern.
One solution is to use grsec or selinux to control the executables
that the user can execute.
Another options could be to set all writable directories non executable.

Logging keystrokes and limiting them seems problematic.

Jay

------------------------------------------------------------------------------
_______________________________________________
xrdp-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xrdp-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xrdp-devel] rate limit keyboard input

Jonathan Buzzard
In reply to this post by Steve Gula
On 26/08/15 14:59, Steve Gula wrote:

> My security people are concerned about a particular attack vector and we
> haven't found anything on Google to help. I'm hoping someone here can -
>
> The concern is if someone is remoting into a machine we have 'locked
> down' (stripped out a lot of packages/etc) and then they copy/paste or
> use a keyboard emulator to retype an entire application into the remote
> machine. For instance:
>
> Local machine:
> Take executable binary and convert to hexadecimal for easy copy/paste
> Install software that emulates keyboard and will retype entire contents
> of the local machines clipboard (because we disabled copy/paste in xrdp)
> connect to remove machine and create a file in remote home directory
> Let software/keyboard emulator start retyping the entire executable
>

The convert to hexadecimal step is unnecessary, you just pipe STDIN to a
file and go nuts on the keyboard. Pretty standard thing to do in hacking
if you can get a remote shell and want to get an executable onto the system.

> We think doing a keystroke logger on the remote end and pumping the logs
> somewhere could help monitor part of it. But we'd really like to
> rate-limit the incoming keystrokes because if the attacker aims too high
> (re: large exploit file size) then we can at least delay the inevitable
> and hope we notice in time. Particularly on the system in place where
> keystrokes would be very minimal (essentially a kiosk driven largely by
> mouse clicks).
>
> Any thoughts or input would be appreciated.
>

As Jay said the proper way to defend against this is Selinux, and mark
all the directories that they can write to, as none executable. Then it
does not matter what they can write to the file system. If you don't
trust your users don't let them execute anything in the first place.

A skilled hacker will be using hand crafted binaries written in
assembler that are tiny compared to something written in C and compiled
and may well slip under the radar of your monitoring anyway.


JAB.

--
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
Fife, United Kingdom.

------------------------------------------------------------------------------
_______________________________________________
xrdp-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xrdp-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Xrdp-devel] rate limit keyboard input

Steve Gula
I appreciate all of the feedback. As it stands we limit the end user to 1 app that's already launched and they're not supposed to be able to do anything else. Naturally, we're going to security in depth and want to make sure we're preventing damage at nearly all levels. Don't want to be the next Target hack were you lose everything because an HVAC company got compromised. :-)  In some ways we've avoided SELinux because it seems like there aren't any experts out there or great documentation on it. Feel like we find more questions than answers in our googling. But we'll look into that.

Thanks again to everyone.

________________________________________
From: Jonathan Buzzard <[hidden email]>
Sent: Wednesday, August 26, 2015 7:44 PM
To: [hidden email]
Subject: Re: [Xrdp-devel] rate limit keyboard input

On 26/08/15 14:59, Steve Gula wrote:

> My security people are concerned about a particular attack vector and we
> haven't found anything on Google to help. I'm hoping someone here can -
>
> The concern is if someone is remoting into a machine we have 'locked
> down' (stripped out a lot of packages/etc) and then they copy/paste or
> use a keyboard emulator to retype an entire application into the remote
> machine. For instance:
>
> Local machine:
> Take executable binary and convert to hexadecimal for easy copy/paste
> Install software that emulates keyboard and will retype entire contents
> of the local machines clipboard (because we disabled copy/paste in xrdp)
> connect to remove machine and create a file in remote home directory
> Let software/keyboard emulator start retyping the entire executable
>

The convert to hexadecimal step is unnecessary, you just pipe STDIN to a
file and go nuts on the keyboard. Pretty standard thing to do in hacking
if you can get a remote shell and want to get an executable onto the system.

> We think doing a keystroke logger on the remote end and pumping the logs
> somewhere could help monitor part of it. But we'd really like to
> rate-limit the incoming keystrokes because if the attacker aims too high
> (re: large exploit file size) then we can at least delay the inevitable
> and hope we notice in time. Particularly on the system in place where
> keystrokes would be very minimal (essentially a kiosk driven largely by
> mouse clicks).
>
> Any thoughts or input would be appreciated.
>

As Jay said the proper way to defend against this is Selinux, and mark
all the directories that they can write to, as none executable. Then it
does not matter what they can write to the file system. If you don't
trust your users don't let them execute anything in the first place.

A skilled hacker will be using hand crafted binaries written in
assembler that are tiny compared to something written in C and compiled
and may well slip under the radar of your monitoring anyway.


JAB.

--
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
Fife, United Kingdom.

------------------------------------------------------------------------------
_______________________________________________
xrdp-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xrdp-devel

------------------------------------------------------------------------------
_______________________________________________
xrdp-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/xrdp-devel