Hijacking SSH : How Secure is Secure Shell? | Lucideus Research

In this article we shall be introducing to you the secure shell configurations and how they have a direct impact on security of the mission critical assets within an organisation. SSH is the most common channel of communication with Networking devices and Linux based Servers, therefore is a grave concern. We have split SSH exploitation, into two categories for an easy understanding:

1. Exploitation attacks for direct compromise
Such attacks are direct attacks on the SSH service or its misconfiguration from an unauthenticated remote attacker to gain complete/partial privileges of the environment. Example of such attacks are as follows:

a) SSH Version related vulnerabilities
“A design flaw in the SSH-1 protocol allows a malicious server to establish two concurrent sessions with the same session ID, allowing a man-in-the-middle attack”

“There is a very simple, yet potentially damaging, vulnerability in the SSH version 1 daemon related to the brute forcing of passwords in accounts.”

b) Username/Password Brute Force Attacks due to configuration flaws
Root login enabled
PermitEmptyPasswords enabled
PermitUserEnvironment enabled

c) Weak Ciphers and Mac Algorithms
A simple SSL-Scan shall reveal support of highly weak ciphers which offer no encryption in today’s quantum computing world

2. Post exploitation attacks to pivot within the network
Such attacks are even more fascinating and less talked about but actively exploited. Some misconfigurations enable noiseless scenarios for post exploitation in an linux/unix based environment. This helps a malicious adversary to pivot within the network, with the help of misconfigured SSH service.  Example of such attacks are as follows:

a) IgnoreRhosts configuration absent
“SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts”

b) SSH Hijacking through Agent Forwarding
“If an attacker compromises Host A he can not only use your forwarded agent when you’re connected to impersonate another session but he is actually able to eavesdrop on your ongoing session.”

So far, we believe we have your attention on the variability in Secure Shell based attacks and you shall be able to gauge the attack surface for a SSH service, we shall move ahead to discuss more about one of the example in detail. We shall be talking about SSH Hijacking. Let us introduce to you Agent Forwarding Concept in following paragraphs.

Agent Forwarding in SSH

SSH Agent runs in the background and keeps your key(used for authentication in SSH) loaded in to the memory. Thus, SSH Agent enables you to seamlessly interact with a server without requiring your passphrase every time you need to use the key. In simple straightforward language, SSH Agent forwarding is sort of like asking a friend to enter their password so that you can use their computer.

How is it currently applicable in Enterprise?

SSH without passwords makes life with Linux/Unix operating systems much easier. A good example would be If your network requires chained ssh sessions (to access a restricted network), agent forwarding becomes extremely helpful. With agent forwarding it's possible for anyone to connect from their laptop to their development server and from there run an svn checkout from yet another server, all without passwords, while keeping their private key safe on their own local workstation. Usually this is implemented with the use of 
  • Control Master
  • Agent Authentication
What is ControlMaster?
SSH Control Master is a feature which allows multiplexed connections. Performance wise this is great since you only have to authenticate to the target system on the first SSH session and then, depending on the SSH daemon configuration you can open multiple new SSH sessions through the already established connection. This can be tuned on the server side with the following two directives

MaxSessions
Specifies the maximum number of open sessions permitted per network connection. The default is 10.
MaxStartups
Specifies the maximum number of concurrent unauthenticated connections to the SSH daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection. The default is 10. 

What may happen if I do not configure anything?
Control Master is enabled by default. if you don’t configure the above mentioned configurations, then regardless of how strong authentication method you are employing for your users, an attacker only has to get code execution to one of your user’s endpoints and wait for that user to SSH somewhere. The attacker can look for the open connections by inspecting the directory specified by ControlPath directive on the client’s side or just using common tools like netstat. Then, if the attacker attempts to open an SSH session to a host that it is already in the Control Master, it will require no authentication or establishing a new connection as it is re-using the existing one.

What can I do to protect myself and my organisation?
By setting MaxSessions to 1 you can disable Control Master/session multiplexing and each new session will require a complete new connection that includes the authentication step. 

Agent Authentication
To reduce friction and make the experience more smooth many organizations employ the use of SSH-agent which is a service that allows authentication via a local socket file. When you connect to a remote system you can choose if you want your ssh-agent to be available there too using the ForwardAgent directive. By forwarding the agent you can move around systems without having to copy keys everywhere or re-authenticating manually. 

What may happen if I am using agent Authentication?
If an attacker has root access on any of the systems from which you have forwarded your agent, he can re-use that socket file to open new SSH sessions with your information. 
Simply put, anyone with root privilege on the the intermediate server can make free use of your ssh-agent to authenticate them to other servers. A simple demonstration shows how trivially this can be done.

Let us assume laptop A is running ssh-agent, which communicates with the ssh client programs via a socket. The path to this socket is stored in the SSH_AUTH_SOCK environment variable:

The ssh-add program lets us view and interact with keys in the agent:

I have "ForwardAgent yes" in the ~/.ssh/config on my laptop. So ssh is going to create a tunnel connecting the local socket to a local socket on the remote server:


Even though my keys are not installed on "serverB", the ssh client programs are still able to access the agent running on my local machine:

So... who can we mess with?
Let us target the user rahul. To find his agent connection, We need to find the child process of one of his ssh sessions:
There are several ways for root to view the environment of a running process. On Linux, the data is available in /proc/<pid>/environ. Since it's stored in NULL-terminated strings, I'll use tr to convert the NULLs to newlines:
We now have everything we need to know in order to hijack rahul's ssh-agent:
If we happen to have a specific target in mind, we should now be able to connect directly. Otherwise, just watching the process list or grepping through rahul's history file should present plenty of targets of opportunity. In this case, we know rahul has all sorts of super secret files stored on the server named "boston":


What can I do to protect myself and my organisation?

If you are using OpenSSH, you can mitigate this threat by using the AllowAgentForwarding directive to ensure that only the hosts that need it will have it, rather than the entire environment.

Don't let your ssh-agent store your keys indefinitely. On OS X, configure your Keychain to lock after inactivity or when your screen locks. On other Unix-y platforms, pass the -t  option to ssh-agent so its keys will be removed after  seconds.

Don't enable agent forwarding when connecting to untrustworthy hosts. Fortunately, the ~/.ssh/config syntax makes this fairly simple:

Host trustworthy-host
ForwardAgent yes

Host *

ForwardAgent no


Best Practice
Description
Ensure SSH Protocol is set to 2
The SSH protocol encrypts everything it sends and receives. SSH 2 is latest protocol and is patched for known vulnerabilities.
Ensure SSH LogLevel is set to INFO
It gives the verbosity level that is used when logging messages from sshd.
Ensure SSH X11 forwarding is disabled
X11 forwarding using SSH is different from your regular, non-secure way of running X Window.
Ensure SSH MaxAuthTries is set to 4 or less
Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged.
Ensure SSH IgnoreRhosts is enabled
SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. SSH can emulate the behavior of the obsolete rsh command in allowing users to enable insecure access to their accounts via ".rhosts" files.
Ensure SSH HostbasedAuthentication is disabled
SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. SSH's cryptographic host-based authentication is more secure than ".rhosts" authentication, since hosts are cryptographically authenticated. However, it is not recommended that hosts unilaterally trust one another, even within an organization.
Ensure SSH root login is disabled
Because any hacker can try to brute force your password and gain access to your system. So, it is better to have another account that you regularly use and then switch to root user by using ‘su –‘ command when necessary.

Best Practice
Description
Ensure SSH Protocol is set to 2
The SSH protocol encrypts everything it sends and receives. SSH 2 is latest protocol and is patched for known vulnerabilities.
Ensure SSH LogLevel is set to INFO
It gives the verbosity level that is used when logging messages from sshd.
Ensure SSH X11 forwarding is disabled
X11 forwarding using SSH is different from your regular, non-secure way of running X Window.
Ensure SSH MaxAuthTries is set to 4 or less
Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged.
Ensure SSH IgnoreRhosts is enabled
SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. SSH can emulate the behavior of the obsolete rsh command in allowing users to enable insecure access to their accounts via ".rhosts" files.
Ensure SSH HostbasedAuthentication is disabled
SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. SSH's cryptographic host-based authentication is more secure than ".rhosts" authentication, since hosts are cryptographically authenticated. However, it is not recommended that hosts unilaterally trust one another, even within an organization.
Ensure SSH root login is disabled
Because any hacker can try to brute force your password and gain access to your system. So, it is better to have another account that you regularly use and then switch to root user by using ‘su –‘ command when necessary.
Ensure SSH PermitEmptyPasswords is disabled
Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere. Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords.
Ensure SSH PermitUserEnvironment is disabled
SSH environment options potentially allow users to bypass access restriction in some configurations.
Ensure only approved ciphers are used
Enabled Ciphers, MACs and KexAlgorithms are the ones that are offered using connection as you point out.
Ensure only approved MAC algorithms are used
Enabled Ciphers, MACs and KexAlgorithms are the ones that are offered using connection as you point out.
Ensure SSH Idle Timeout Interval is configured
Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another. SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out.
Ensure SSH LoginGraceTime is set to one minute or less
It is the time after which the server disconnects if the user has not successfully logged in.
Ensure SSH access is limited
Ensure SSH access is limited. If an administrator is uncomfortable allowing users to login as root for these or other reasons, the root password should be kept secret, and access to runlevel one or single user mode should be disallowed through boot loader password protection.
Ensure IPTables are configured for SSH Brute force prevention.
Example configuration is as below

  • iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
  • iptables -A INPUT -p tcp -m tcp --dport 22 -m recent --rcheck --seconds 30 --hitcount 4 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset
  • iptables -A INPUT -p tcp -m tcp --dport 22 -m recent --rcheck --seconds 30 --hitcount 3 --rttl --name SSH --rsource -j LOG --log-prefix "SSH brute force"
  • iptables -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 30 --hitcount 3 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset
  • iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
Ensure Agent forwarding is whitelisted.
As highlighted in above example, it is suggested to whitelist trusted hosts only
  • Host trustworthy-host
     ForwardAgent yes
  • Host *
     ForwardAgent no
Ensure MaxSessions are set to 1
By setting MaxSessions to 1 you can disable ControlMaster/session multiplexing and each new session will require a complete new connection that includes the authentication step.
References/Further Reading: “SSH Agent Forwarding considered harmful”, https://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-considered-harmful/ “SSH Agent Hijacking”, https://www.clockwork.com/news/2012/09/28/602/ssh_agent_hijacking “SSH-1 allows client authentication to be forwarded by a malicious server to another server” https://www.kb.cert.org/vuls/id/684820

Post a Comment

0 Comments