Anyone with VM with Hosthatch running with Debian image provided by Hosthatch should check their VM now. Good probability is that your VM may have been compromised via user
debianuser, which is now running
cnrig, which appears to be related to CryptoNight. Hosthatch VMs in multiple locations has been observed to have been compromised this way.
From the provider via email:
We have detected a security vulnerability in our Debian 10 template and our records indicate that you have installed a VM with this template. If you have since then reinstalled your VM to any template other than Debian 10, or used an ISO to reinstall your VM, you can ignore this email.
How could this happen?
We use SolusVM as our backend virtualization platform, it is a leading provider operated by Plesk. We are using their official templates. Unfortunately this particular template had an issue which resulted in this security vulnerability. They are aware of the situation.
How was it fixed?
We have patched the template with help from SolusVM and they also helped us to confirm that no other templates are affected.
I also found this Chinese blog post from October 2020, where someone’s GreenCloudVPS VPS was compromised through what I assume is the same
debianuser account, also running some other crypto thing (
xmrig): https://aoyouer.com/posts/server-hacked-record.html, so this has been in the wild for at least four months (probably longer), and likely affects many other providers too
Please check your servers for a
debianuser user. If so, you’re probably best off wiping the whole thing and restoring from backups.
You should be fine if password authentication is disabled, as in that case you can only access SSH if you have the private key. I’d still recommend deleting the debianuser user if it’s present on your system.
If you still use password authentication for SSH, I’d strongly recommend:
- Generate an SSH key. You may already have one if you use a service like GitHub that uses SSH keys for authentication. If you don’t have one already, an Ed25519 key is good. Upgrade Your SSH Key to Ed25519. If you’re a DevOps engineer or a web… | by Risan Bagja Pradana | risan | Medium
- Ensure the key is in
/etc/ssh/sshd_configand restart SSH (
service ssh restart)
- Double-check that you can still get in (open a new session and test it out) before you exit your active SSH session