Widespread re-use of SSH Host Keys in Ethereum Mining Rig Operating Systems

Written 2020-04-10

Tags:Cryptocurrency Ethereum Crypto SSH 

How this started

A friend came to me last fall wondering how their newly set up mining rig kept getting rooted. This happened over a few different mining OSs. Eventually we found an old firewall rule allowing inbound SSH access, and the mining rig had lost the DHCP lottery and SSH was exposed. Rather than close the hole immediately we decided to do some logging. We set up a new, fresh install and waited. Mostly, we got the usual SSH scanners hitting the box, but rarely our attacker would log in with the right default password on the first try. That's strange - default passwords change per mining OS, so how would they know what OS was running?

I myself have a GPU rig, for machine learning and other purposes. But while it's idle to me, it mines. Strangely, I noticed that the SSH host-keys on my box predated the software installation, which made me curious who generated them.

With these two bits of knowledge, I discovered a widespread key-reusage bug, worked with the mining OS groups, and filed several CVEs.

What exactly are SSH host keys?

SSH host keys provide a mechanism so that a server can be fingerprinted and identified to a client as a trusted entity, worthy of being fed a password through a login attempt. In other words:


The SSH key should be unique per host, both to prevent a bad actor compromising one machine being able to impersonate another, and to prevent a bad actor from enumerating identifiable hosts by looking for known public keys.

The Problem

Several Linux-based Ethereum mining platforms constructed host-keys prior to disk image generation. This means that a large number of systems share the SSH host keys. In addition to being able to impersonate servers, we can search shodan.io or use an SSH host-public-key scanner to identify hosts accessible on the public IPv4 space. It also means that it is fairly easy to construct a dictionary mapping public key to default credentials for some mining OSs.

The Extraction Process

For each mining image, the disk image was downloaded, and testdisk was run to extract the SSH keys. Testdisk had trouble with a few images, so the remaining ones were booting in a VM. SSH keys were then searched on shodan.io to confirm the presence of IPv4 exposes hosts.


It seems attackers have weaponized SSH host keys, both as a means of identifying hosts, and identifying default exploits like unchanged default usernames and passwords. Additionally, most appliances or IoT devices should not be exposed on IPv4/6 for ingress from the general internet. This sentiment was echoed by some mining OS vendors who did not recognize shared host keys as an issue until presented with results showing their miners were easily identifiable online. Finally, a secure automatic update path is a must - without this miners will remain exposed until manually patched, likely with many miners unaware they are exposed.

Affected Platforms and Keys and Host Counts

PlatformSSH Host Key(Search Shodan For This)Shodan.io Host Count(when found)

Responsible Disclosure

An effort was made to contact the authors of each identified OS, and publication was delayed four months in an effort to allow vendors to patch their distributions:
Platform CVE Initial Report Outcome
MinerStat CVE-2019-19750 Sept 8, 2019 Fixed issue promptly.
nvOC CVE-2019-19752 Dec 1, 2019 Devs on bitcoin talk said it would be fixed in next release.
EasyMine CVE-2019-19751 Sept 23, 2019 Fixed Dec 5, 2019
SimpleMiningOSCVE-2019-19753 Sept 8, 2019 Declined to fix, pinged again, said they would consider.
HiveOS CVE-2019-19754 Sept 9, 2019 Said thank you for submitting, they would consider it. Never heard back.
EthOS CVE-2019-19755 Dec 1, 2019 Stated in IRC they would ask developers to fix it
MinerBabe CVE-2020-5200 Dec 3, 2019 Said they would fix it, but did not say anything about fixing the SSH login key shipped in the image.