IT security headaches caused by standing privileges & rogue SSH keys

Two more security events occurred, once again caused by having inadequately-secured standing privileges, and unmanaged SSH keys freely roaming around your IT environment. This is exactly why we strongly advocate companies either removing permanent standing privileges (like passwords) or take management of their access credentials (like SSH keys) more seriously.

The two 'still developing' stories you may have heard about:

• Kaijit IoT botnet is coming for your SSH keys – a new strain of malware that spreads via SSH brute-force attacks, specifically targeting weak passwords.
• Unauthorised individual accessed SSH account on GoDaddy – the targeted customer was recommended to ‘audit their hosting accounts’ because of the security breach.

While the effects of either case are still unclear, any claim of ‘no evidence’ regarding any loss or exfiltration of data should be regarded as dubious. The truth is, unless they have a mechanism to monitor encrypted traffic, then no party can confirm nothing was taken.

So what can you, or should you do about this, to prevent such attacks form succeeding?

You have basically three options:

First option: treat your SSH environment (and therefore SSH keys) as you would your password policy, and enforce accordingly.

1. This means enforcing complex or long passwords and applying them to all SSH accounts.
2. Enforcing password rotation at an appropriate interval.
3. Enforcing SSH key rotation on top of your password rotation.
4. And putting controls around who can access these passwords.

Sounds simple, right? You know better than that. There are also perils to this approach.

Enforcing password rotation is fine in theory, though the execution is often challenging. But in the GoDaddy case, clearly this attacker gained privileged access to this account – meaning they had the ability to change any passwords linked to that account. Rotation would not have stopped it.

What is also there to stop this attacker (or the authorized user for that matter) from dropping an SSH key onto the server? Left unchecked, such a key is essentially a permanent ‘secured’ access method that can be exploited at any time. Changing the password in this case does nothing. Worse, the connection is encrypted, so it’s difficult to figure out what that SSH connection is doing.

If skillful employees know how to bypass existing security controls like Privileged Access Management (PAM) solutions – bad actors know how to do it too.

Second option: get your SSH environment under direct control, so you can safely and securely manage any SSH keys floating around your IT environment.

A valid and viable option that many companies should do, yet it is often not even considered. Or if it is considered, it often gets buried by ‘other priorities’. That is at least, until an audit failure or data breach happens. Then the question becomes ‘why didn’t we do this years ago?’. Why indeed.

Sadly, this is not surprising. Securing an SSH key environment is complex and challenging, which is why such efforts rarely ever truly succeed. That is, unless they invest extraordinary effort doing it themselves, or invest in a dedicated SSH key manager to facilitate solving the problem.

In a case of bitter irony – much of the issue is caused by the SSH protocol doing exactly what it is supposed to, and doing it really well. That is, providing bullet-proof encrypted connections between a host and a client. Where the problem arises, is making sure that the right people have access to critical keys, and that access is (or can be) revoked when needed.

This has nothing to do with the SSH protocol however, but it has everything to do with how it is utilized within a given company. Unfortunately, this can lead not only to breaches but to failing an IT audit.  Learn how SSH keys will make you fail your IT audit here.

But there’s also a third option.

Third option: Get rid of standing privileges (and therefore passwords) altogether.

Yes, it is possible, and no we’re not crazy. The concepts of Zero Trust, Ephemeral Certificates, and Just-in-Time Privileged Access Management (JIT-PAM) have been at the forefront of security technology for some time now. We are even getting to the stage where these will become the norm, and the traditional approaches to PAM will fall by the wayside.

Gartner agrees: “The existence of privileged access carries significant risk, and even with PAM tools in place, the residual risk of users with standing privileges remains high. Security and risk management leaders engaged in IAM must implement a zero standing privileges (ZSP) strategy through a just-in-time (JIT) model.” – Gartner’s “Remove Standing Privileges Through a Just-in-Time PAM Approach”. Learn more about why Gartner believes standing privileges in IT are a risk.

The need for a new approach should not be surprising. It is well known that leaving standing privileges (such as passwords) on target accounts is a bad idea. Why? Because those are exactly what gets targeted by automated credential harvesting tools and malware. Why? Because they are almost always the weak link in an otherwise secured access perimeter. There are more cases like the recent Zoom and WHO data breaches prove the need for passwordless IT.

Therefore, the idea of a ‘passwordless’ or ‘credentialess’ PAM approach is appealing. Why hand over permanent credentials to users, employees, and/or 3^rd parties in the first place, if you don’t have to?

The answer is, you don’t have to. There is another way. Learn about the 5 must-have functions for a PAM solution here.

Let’s figure out what the best option is for you together. Contact us here.