Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. OpenSSH>
  3. Dev
Security implications of using ControlMaster
kb at open
Jan 20, 2020, 6:13 AM
Post #1 of 9 (1047 views)
Permalink
Dear Mailing List

We are using a ControlMaster with a short ControlPersist to access the
bastion host which then gives access to customer hosts.

Our Information Security Manager would like to disallow the
ControlMaster. His attack scenario is an admin workstation with a
compromised root account. An attacker can then use the ControlMaster to
trivially get shell access on the bastion host without authentication
when the actual admin user has an open SSH connection.

My argument is that there is too little security gain for the loss of
convenience. If the attacker is root on the admin workstation, he has
other means, like exchanging the SSH binary to silently drop some
payload after connecting to the target or doing something similar by
using the TTY file used by the shell which runs ssh (like "ECHO OFF, do
your stuff, ECHO ON").

What is your opinion?

Kind regards

Konrad

--
Konrad Bucheli
Principal Systems Engineer

O. +41 58 100 10 10
W. open-systems.com

Open Systems

Attached Files:

Re: Security implications of using ControlMaster [ In reply to ]
nico.schottelius at ungleich
Jan 20, 2020, 6:37 AM
Post #2 of 9 (1047 views)
Permalink
Hey Konrad,

if the box is root compromised, anything you do on it is untrusted.

So you cannot use ssh or even type in any password into any of the
existing tool without likely leaking it to the attacker. She could even
have patched the (g)libc to forward input, so even a correct ssh binary
doesn't ensure your data is not compromised.

So disabling ControlMaster does not fix the problem your SM described.

Cheers,

Nico


Konrad Bucheli <kb@open.ch> writes:

> Dear Mailing List
>
> We are using a ControlMaster with a short ControlPersist to access the
> bastion host which then gives access to customer hosts.
>
> Our Information Security Manager would like to disallow the
> ControlMaster. His attack scenario is an admin workstation with a
> compromised root account. An attacker can then use the ControlMaster to
> trivially get shell access on the bastion host without authentication
> when the actual admin user has an open SSH connection.
>
> My argument is that there is too little security gain for the loss of
> convenience. If the attacker is root on the admin workstation, he has
> other means, like exchanging the SSH binary to silently drop some
> payload after connecting to the target or doing something similar by
> using the TTY file used by the shell which runs ssh (like "ECHO OFF, do
> your stuff, ECHO ON").
>
> What is your opinion?
>
> Kind regards
>
> Konrad


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Security implications of using ControlMaster [ In reply to ]
kb at open
Jan 20, 2020, 7:15 AM
Post #3 of 9 (1047 views)
Permalink
On 20.01.20 15:37, Nico Schottelius wrote:
>
> Hey Konrad,
>
> if the box is root compromised, anything you do on it is untrusted.
>
> So you cannot use ssh or even type in any password into any of the
> existing tool without likely leaking it to the attacker. She could even
> have patched the (g)libc to forward input, so even a correct ssh binary
> doesn't ensure your data is not compromised.

Yes, the attacker can change anything on the workstation. But I missed
the detail that the ssh authentication on the bastion host is 2FA
protected, so knowing or replying any password does give you access. You
need to take over or piggy-pack on an existing connection.
I also think that is not that difficult too.

> So disabling ControlMaster does not fix the problem your SM described.
>
> Cheers,
>
> Nico
>
>
> Konrad Bucheli <kb@open.ch> writes:
>
>> Dear Mailing List
>>
>> We are using a ControlMaster with a short ControlPersist to access the
>> bastion host which then gives access to customer hosts.
>>
>> Our Information Security Manager would like to disallow the
>> ControlMaster. His attack scenario is an admin workstation with a
>> compromised root account. An attacker can then use the ControlMaster to
>> trivially get shell access on the bastion host without authentication
>> when the actual admin user has an open SSH connection.
>>
>> My argument is that there is too little security gain for the loss of
>> convenience. If the attacker is root on the admin workstation, he has
>> other means, like exchanging the SSH binary to silently drop some
>> payload after connecting to the target or doing something similar by
>> using the TTY file used by the shell which runs ssh (like "ECHO OFF, do
>> your stuff, ECHO ON").
>>
>> What is your opinion?
>>
>> Kind regards
>>
>> Konrad
>
>
> --
> Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
>

--
Konrad Bucheli
Principal Systems Engineer

O. +41 58 100 10 10
W. open-systems.com

Open Systems

Attached Files:

Re: Security implications of using ControlMaster [ In reply to ]
djm at mindrot
Jan 20, 2020, 4:08 PM
Post #4 of 9 (1044 views)
Permalink
On Mon, 20 Jan 2020, Konrad Bucheli wrote:

> Dear Mailing List
>
> We are using a ControlMaster with a short ControlPersist to access the bastion
> host which then gives access to customer hosts.
>
> Our Information Security Manager would like to disallow the ControlMaster. His
> attack scenario is an admin workstation with a compromised root account. An
> attacker can then use the ControlMaster to trivially get shell access on the
> bastion host without authentication when the actual admin user has an open SSH
> connection.
>
> My argument is that there is too little security gain for the loss of
> convenience. If the attacker is root on the admin workstation, he has other
> means, like exchanging the SSH binary to silently drop some payload after
> connecting to the target or doing something similar by using the TTY file used
> by the shell which runs ssh (like "ECHO OFF, do your stuff, ECHO ON").
>
> What is your opinion?

If the attacker has access to the origin machine then they have already
won. Options for exploitation include stealing local keys or use of the
agent, replacing or $PATH substituting the ssh executable, ptracing a
running ssh process to open additional sessions (metlstorm's sshjack
tool) and probably a bunch more that I'm not sufficiently imaginative to
think of.

So IMO disallowing session multiplexing is at most a speedbump that an
attacker will cross with relative ease. Speedbumps make sense sometimes,
but they must be weighed against their inconvenience.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Security implications of using ControlMaster [ In reply to ]
lists at spuddy
Jan 20, 2020, 4:34 PM
Post #5 of 9 (1044 views)
Permalink
On Tue, Jan 21, 2020 at 11:08:51AM +1100, Damien Miller wrote:
> So IMO disallowing session multiplexing is at most a speedbump that an
> attacker will cross with relative ease. Speedbumps make sense sometimes,

An attacker getting root on the jumphost gets immediate control of
any _current_ persistent connections and new connections. Without
ControlMaster it's a _lot_ harder to take control of current connections,
but pretty easy to subvert new connections.

So there is a benefit... but a small one.

> but they must be weighed against their inconvenience.

This is pretty much true of all security controls :-)

--

rgds
Stephen
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Security implications of using ControlMaster [ In reply to ]
djm at mindrot
Jan 20, 2020, 5:18 PM
Post #6 of 9 (1044 views)
Permalink
On Mon, 20 Jan 2020, Stephen Harris wrote:

> On Tue, Jan 21, 2020 at 11:08:51AM +1100, Damien Miller wrote:
> > So IMO disallowing session multiplexing is at most a speedbump that an
> > attacker will cross with relative ease. Speedbumps make sense sometimes,
>
> An attacker getting root on the jumphost gets immediate control of
> any _current_ persistent connections and new connections. Without
> ControlMaster it's a _lot_ harder to take control of current connections,
> but pretty easy to subvert new connections.

I wouldn't say it's a lot harder to take control of current connections -
writing a ptrace-based tool that hijacked a running ssh client and
injected a one-off implant payload via keystrokes doesn't seem like
much work.

-d

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Security implications of using ControlMaster [ In reply to ]
lists at spuddy
Jan 20, 2020, 5:32 PM
Post #7 of 9 (1044 views)
Permalink
On Tue, Jan 21, 2020 at 12:18:52PM +1100, Damien Miller wrote:
> I wouldn't say it's a lot harder to take control of current connections -
> writing a ptrace-based tool that hijacked a running ssh client and
> injected a one-off implant payload via keystrokes doesn't seem like
> much work.

* Injection of key strokes into an existing channel may be detected
just because "hey, I didn't type foobar" so why is it on my screen.
A new shell on a different channel won't show so obviously.

* That's a lot harder than just getting a whole new shell without writing
any tools; just use the existing ssh command line. Tool-less compromise
is a higher risk vector 'cos it's harder for monitoring tools to detect.

--

rgds
Stephen
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Security implications of using ControlMaster [ In reply to ]
wagener at gmail
Jan 20, 2020, 11:26 PM
Post #8 of 9 (1044 views)
Permalink
Stephen Harris <lists@spuddy.org> schrieb am Di., 21. Jan. 2020, 02:39:

> On Tue, Jan 21, 2020 at 12:18:52PM +1100, Damien Miller wrote:
> > I wouldn't say it's a lot harder to take control of current connections -
> > writing a ptrace-based tool that hijacked a running ssh client and
> > injected a one-off implant payload via keystrokes doesn't seem like
> > much work.
>
> * Injection of key strokes into an existing channel may be detected
> just because "hey, I didn't type foobar" so why is it on my screen.
> A new shell on a different channel won't show so obviously.
>

`~.` is a nice keystroke sequence to inject because it disconnects the
session and you will likely not even see the input on screen.

An unsuspecting victim would assume a network glitch and reconnect,
yielding a new (and controllable by the attacker) session.

Best,
Harald

PS this is veering offtopic, but a simple `Ctrl-C Ctrl-D` might be even
less suspicious. Combine this with `Ctrl-S` and `Ctrl-Q` and unless you
have full input stream logging you will have a lot of opportunities of
messing with existing connections unnoticed.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Security implications of using ControlMaster [ In reply to ]
djm at mindrot
Jan 20, 2020, 11:56 PM
Post #9 of 9 (1044 views)
Permalink
On Tue, 21 Jan 2020, Harald Wagener wrote:

> Stephen Harris <lists@spuddy.org> schrieb am Di., 21. Jan. 2020, 02:39:
>
> > On Tue, Jan 21, 2020 at 12:18:52PM +1100, Damien Miller wrote:
> > > I wouldn't say it's a lot harder to take control of current connections -
> > > writing a ptrace-based tool that hijacked a running ssh client and
> > > injected a one-off implant payload via keystrokes doesn't seem like
> > > much work.
> >
> > * Injection of key strokes into an existing channel may be detected
> > just because "hey, I didn't type foobar" so why is it on my screen.
> > A new shell on a different channel won't show so obviously.
> >
>
> `~.` is a nice keystroke sequence to inject because it disconnects the
> session and you will likely not even see the input on screen.

Remember that the attacker is in control of the ssh process - they can
simply discard returned output from the far end after they perform the
injection.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal