New Attacker Scanning for SSH Private Keys on Websites

Wordfence is seeing a significant spike in SSH private key scanning activity. We are releasing this advisory to ensure that our customers and the broader WordPress community are aware of this new activity and of the risk of making private SSH keys public, and to explain how to avoid this problem.

Quick SSH Review

SSH 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. More commonly in the WordPress world, SSH is used for SFTP, or secure FTP.

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. Then when you fire up your SFTP client, it authenticates using key-based authentication.

When SSH Private Keys Become Public

If your private SSH key ever gets out, anyone can use it to sign in to a server where you have set up key-based authentication. It is very important to keep your private key safe.

There are a variety of 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.

An attacker can locate websites that belong to your SSH key through a variety of methods.

They may run the command “ssh-keygen -lf <your private key file>”.

This outputs a fingerprint for your SSH key that looks something like this:

2048 17:16:40:f9:23:1f:a0:ed:07:b7:d6:51:8f:19:31:27 yourname@example.com (RSA)

This fingerprint uniquely identifies your private key and contains your email address, or a unique identifier, which can help an attacker determine who a key belongs to and which servers to target. For example, if they discover the key belongs to me, they may try to target my personal blog or other systems they know belong to me.

A Spike in SSH Private Key Scans in the Past 48 Hours

In the past 24 hours, we have seen a new attacker start mass-scanning websites for private SSH keys. Here is a sample showing some of the requests these scans are generating:

As you can see, the attacker is trying a variety of paths to access private SSH keys, including /root/.

The following graph shows the rapid growth we are seeing in this scanning activity:

The graph shows 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.

How to Ensure Your SSH Keys Are Safe

Your SSH keys are usually kept in a private directory on your workstation. On Apple workstations, the keys are kept in the following directory:

/Users/<yourname>/.ssh/<key-filename>

On Windows workstations, the location where SSH keys are stored depends on which software you are using, so check your vendor documentation.

To set up SSH authentication, you will need to copy your public SSH key to a directory on the server you want to sign in to. This key usually ends in a .pub extension. NEVER copy the private key to the remote server you want to sign in to. This misunderstanding may result in many private keys landing in publicly accessible web directories.

Your private key is usually a file that does not end in .pub. The private key has no extension. This file must remain private. If it gets out, an attacker can use it to sign in to services that you use.

Make sure that you don’t accidentally copy your private SSH key into your 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.

Password Protecting SSH Keys

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.

Many users opt not to protect their SSH keys with a password, because typing the password every time they want to authenticate to a remote server is an inconvenience, which is why stolen SSH keys can often be used by an attacker.

Scan Your Site to Check for Readable Private SSH Keys

In the past few hours, we added the capability to Gravityscan to scan websites for publicly accessible SSH keys. Simply head over to www.gravityscan.com and run a scan on your site to check if you have any publicly accessible keys. If you do, Gravityscan will let you know. We may be adding similar capability to the Wordfence plugin in the near future.

Running a secure WordPress website requires a layered approach to security. On this blog we regularly discuss the various approaches you can use to keep your site and your customers secure. Understanding how to securely sign in and how to protect your credentials is one of the important components in a layered approach to securing your website. If you use SSH or SFTP to manage your site with SSH keys, protecting your private key is critically important to staying secure.

As always, I will be around to reply to your comments and questions.

~Mark Maunder.

Did you enjoy this post? Share it!

Comments

21 Comments
  • Setting a password on your private key is also a great way to keep it safe. Even if an attacker still gets the key they need the password to use it.

    • Thanks Dan. Agreed. As I hit publish, one of our analysts pinged me and pointed this out. For some reason I neglected to mention that in the post. I added an updated section.

      Mark.

  • This is a very good security update. Thanks for sharing the details on how to prevent this type of attack.

  • Thanks for the update i rectified the vulnerability through gravity scan.

    • You're welcome. Glad to hear Gravity alerted you to a problem which you resolved.

  • You may also consider limiting SSH connections to your own IP address.

    • Hi Randal,

      Just so that others understand, you're suggesting limiting who can connect to the SSH port on a server and limiting that to your own IP address.

      What we're discussing here is private SSH keys accidentally becoming public. If that private key is being used on a server and that server only allows connections from the key owner's IP address, then yes, that would help mitigate this.

      But I would say it's not an ideal solution. Home IP's are dynamic. They change occasionally and when that happens, you'll find you are locked out of your server. You can probably access it via a remote console or other system to update the firewall rule, but you need to remember to do that and it's hard to predict when a home IP address will change.

      So not an ideal solution IMHO.

      Mark.

      • Having a floating IP is no problem, it is just a question of updating the IP address when it changes. There is nothing to it.

  • Thankfully I keep all my private keys safely in a text document in my /public_html directory.

    • You should make it a html file, then you can bootstrap it and make it pretty when you want to view them in a browser!

      • Right here are two of my favourite comments on the internet right now!

        :)

        Thank you.

  • Do you know if this is a general attack on any website?

    From the look of it, they are just targeting anything rather than it being WordPress specific.

    • I'd guess a general attack. That's what I would do.

  • I'm finding it difficult to understand what to do. I did the Gravityscan and my site passed. But as far as the rest, I don't even know where to begin. Maybe it doesn't apply - I have one site, no workstation (but what is a workstation?) and use a host. Does this apply to the people who have their site hosted? Do I look in the c-panel? Thanks for any info and, as always, for helping us be more aware.

  • This is awesome. Thanks for this wonderful piece. You've always properly guided me. WordFence is my#1 Security Adviser

  • Thanks for the heads up, you guys are really doing much to ensure our websites and servers are secured.

  • Love to head over to GravityScan. But as soon as I hit the site chrome let's it load for about two seconds then redirects to the aw snap message. Something went wrong loading. It's been doing that for the last week and on other sites too. Not all just the odd one.

    W Vista Chrome 49.0.2623.112

    I wondered if you are blocking older browsers or have I picked up something?

    • Hi Gordon. Your browser is about 13 versions behind the current version of Chrome. Newer versions contain a lot of bug fixes, including stability - and more importantly, security. I suggest you upgrade as a matter of urgency.

      https://en.wikipedia.org/wiki/Google_Chrome_version_history

      Mark.

  • Thanks Mark. I know it's old but all my work files are on this machine.

    The thing is I can go to just about every other website without problem but Gravity Scan and Patreon. Also an online app works up to a point and then redirects. I know a lot of places block the older versions of windows or they don't resolve properly but I had to ask if you were blocking Chrome.

    I obviously have picked something up somewhere and the virus scanner isn't showing it. Probably time to migrate over to my new computer (gathering dust)

    Thanks for the help. Love Wordfence by the way it's saves me a ton of work nowadays.

    • Hey Gordon,

      If you need to browse with your Vista computer, I think you could use Firefox more safely (you'll get on the Extended Support Release update channel: see https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista).

      Anyhow, very timely and useful info in this article, as always!