Unsecured SSH keys a target for cyber-criminals
Unsecured SSH keys a target for cyber-criminals

Hackers have scanned thousands of WordPress websites in an attempt to find unsecured SSH private keys. According to security researchers, around 25,000 systems per day have been scanned to find the keys which could help in compromising website security.

In a blog post, WordFence CEO Mark Maunder, said that there are many ways an SSH private key can end up in a public web directory. Website owners occasionally upload their SSH private key to their website by accident. They may also accidentally “commit” their private key into website source code using a version control system like Git.

“When this happens, all it takes is a determined attacker and a scan to locate your SSH private key and download it. Once downloaded, the attacker can start trying to use it to sign in to other servers you control and potentially gain access to your other websites,” he said.

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, a public and private key are created. The public key is kept on the server you want to sign in to. The private key is saved in a local SSH configuration directory. When starting an SFTP client, it authenticates using key-based authentication.

Maunder said that an attacker can locate websites that belong to your SSH key through a variety of methods, using terms such as “root,” “ssh,” or “id_rsa” in a bifd to locate directories containing private SSH keys.

He added that since earlier this week, there has been a massive spike in scanning activity in the past 48 hours.

“We think this increase of activity may indicate that an attacker is having some success scanning for private keys and has decided to increase their efforts. This may indicate a common bug or operational mistake that is being made by WordPress site owners, by which private keys are being accidentally made public,” he said.

According to a report by Venafi, 61 percent of IT security professionals do not limit or monitor the number of administrators who manage SSH; only 35 percent enforce policies that prohibit SSH users from configuring their authorised keys leaving organisations blind to abuse from malicious insiders.

Maunder said that organisations must ensure that they don't accidentally copy their private SSH key into their web site or web application source code. “If you do this, you may inadvertently upload it to your site and make it publicly accessible, allowing an attacker to steal it,” he said.

“We also recommend you protect your private SSH keys using a pass phrase. This is presented as an option when you initially generate the keys. Password protected SSH private keys are not usable by an attacker unless they can guess the password,” he added.

“If you use SSH or SFTP to manage your site with SSH keys, protecting your private key is critically important to staying secure.”

Ilia Kolochenko, CEO of web security company High-Tech Bridge, told SC Media UK that this is a “very interesting case”.

“A sudden explosion of attacks was reported just after Venafi's research on mismanaged SSH keys. The cyber-security industry need to be cautious about their public research, otherwise it can provide a great wealth of brilliant ideas to the attackers.”

“Keeping an SSH key in a public website directory is blatant negligence, however with the same ease and frequency one can find SQL backups, unrestricted file and database admin interfaces, file upload mechanisms, and many other sensitive data or functionality,” he said.

Pascal Geenens, Radware EMEA security evangelist, told SC Media UK that if public SSH keys are stolen, organisations should remove the public key as fast as possible from all systems. Every public key you forget to remove leaves an open door – so be very precise in tracking which systems the public key was copied to! In public/private key authentication the public key holds no authentication value whatsoever and can be shared and stored in public places. The risk with a public key however is when this key is used as the lock to access a service that can only be unlocked with the corresponding private key. It is easy to imagine people copying public keys in many different systems and not being aware of the risk posed by distributing the public key.