Instances of cybercrime and machine identity attacks are rising at an alarming rate. More and more cases of cryptographic key attacks, especially with the exploitation of SSH/TLS keys, are being reported lately. Facefish, KOBALOS, and Hildegard are just a few recent high-profile attacks, and North Korea cyber-attacks are ramping up and even inspiring other rogue groups. Taking proactive steps to protect your keys is the only way to stay safe!
SSH (Secure Shell) is a secure way to connect to servers and communicate with them. You can use it to get a terminal on a remote server and enter commands. There are two common ways to sign in to a server when using SSH or SFTP. You can use a username and password, or you can use “key-based” authentication.
When using key-based authentication, you create a public and private key. You place the public key on the server you want to sign in to. You keep the private key saved in a local SSH configuration directory. When you fire up your SFTP client, it authenticates using key-based authentication. If your private SSH key gets compromised, hackers can use it to sign into any server where you have set up key-based authentication.
Cryptographic solutions are used to encrypt data transmission over wireless or wired protocols. Unfortunately, these techniques are proving to be vulnerable to malicious cyberattacks, via which data can be stolen or manipulated. A cryptographic attack is a method for circumventing the security of a cryptographic system by finding a weakness in a code, cipher, cryptographic protocol, or key management scheme.
Also known as Cryptanalysis, this technique is used to breach cryptographic security systems and gain access to sensitive data, even if the cryptographic key is unknown. In addition to the mathematical analysis of cryptographic algorithms, cryptanalysis includes the study of side-channel attacks that do not target weaknesses in the cryptographic algorithms themselves but instead exploit weaknesses in their implementation.
As a cryptographic network protocol, SSH is most often used for secure remote logins to remote computer systems. Successful theft of a private key gives the hacker access to any server or system where that private key is used for authentication. This risk is not just limited to WordPress, but also Linux and Unix systems and embedded devices that also rely heavily on SSH for secure logins and connections.
SSH private keys are being targeted by hackers who have stepped up their scanning of thousands of servers hosting WordPress websites. Terms such as “root,” “ssh,” or “id_rsa” are being searched in hopes of finding web directories containing private SSH keys, most likely mistakenly stored on public directories. Often, admins lose track of SSH keys and host both the public and private keys online.
The most protection you can provide your private SSH keys is to enable a password. This option is initially presented at the time keys are generated, but a shocking percentage of users opt out because they don’t want to type in a password every time they want to authenticate to a remote server. It may seem cumbersome, but that layer of protection is worth the extra effort. Password protected SSH private keys can’t be used by attackers unless they can guess the password. Here are a few more proactive steps you can take to stay safe as the instances of cybercrime around SSH keys continue to grow:
1. Cryptographic keys should have a one specific purpose
Whether you are using a key for encryption, authentication, digital signature, or any other application, do not be tempted to reusing keys for multiple purposes. This shortcut not only provides inadequate levels of security, but it makes potential compromises even more damaging as more than one system will be in danger.
Key-encryption-keys (KEKs), or as key-wrapping-keys, must be as strong or stronger than the cryptographic keys they are wrapping. They should also only be used to protect a specified cryptographic key, as giving them the additional purpose of encrypting data or communications is similar dangerous. Besides, end-to-end encryption is sufficient to secure online communications.
2. Use hardware security modules (HSMs)
Hardware-backed security like HSMs are highly effective at cryptographic key protection, and can be relied on for key encryption, key decryption, key generation, and more. Plus, an HSM reduces the likelihood of hackers accessing data and the keys needed to decrypt it, as the actual key storage is removed from the software’s program logic. Additional hardware-based solutions such as trusted platform modules (TPM) and trusted execution environments (TEE) also provide isolated, protected environments to safely execute cryptographic functions.
3. Embrace automation for SSH key management
Unlike digital certificates that eventually expire, SSH have no expiration date and passwords are seldom changed. (Although that will change with the advent of SSH certificates.) It is far too easy for even mid-size organizations to lose track of how many SSH keys are active and where they are located when the process is done manually. A key management strategy that is rooted in automation can ensure that policies are focused on the key lifecycle, key storage and backup, and authorized access.
Full visibility and control are necessary to steer clear of danger. Venafi’s SSH Protect solution will help you locate all your SSH keys and identify which systems they are being used on. In the process, you’re likely to discover thousands of orphaned keys that you didn’t realize existed. Going forward, SSH Protect allows you to sidestep these challenges by automating the entire SSH key lifecycle from issuance to decommissioning across your entire organization.
With enterprise-wide visibility into SSH key inventories also identifies vulnerabilities from inside threats, cybercriminals, and negligent misuse—making these threats a thing of the past in your organization. Stay safe!
NOTE: This blog has been updated. It was originally posted by Sharon Solomon on November 5, 2018.