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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4822 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200120/e6cc295c/attachment.p7s>
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 at 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
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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4822 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200120/61e1fcca/attachment.p7s>
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
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