Vulnerability in SolusVM Debian 10 template - "debianuser" backdoor/default user

1

From a thread on the green forum:

@redgreenblue said:
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/, 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:

  1. 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 | Code | Medium
  2. Ensure the key is in ~/.ssh/authorized_keys
  3. Disable PasswordAuthentication in /etc/ssh/sshd_config and restart SSH (service ssh restart)
  4. Double-check that you can still get in (open a new session and test it out) before you exit your active SSH session
1 Like
2

I assume this does not apply if you have password auth disabled?

3

Yeah you should be fine if password auth is disabled, but I’d still recommend checking for the debianuser and deleting it if it’s there. I’ll edit the post to mention that.

1 Like
4

I can confirm it for Virmach too.

1 Like
5

I wonder how long it going to take for most providers to replace the template with a version without the vulnerability, I got feeling some providers won’t bother.

6

If its idle anyway, let these people cryptomine.

7

One way to know your money isn’t going to waste right? :joy:

1 Like