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

TheDP

This is currently an active topic on the OGF.

HostHatch has already sent out comms regarding this.

Your urgent action is required - please read this in full.

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.

If you have multiple VMs, you can check the OS used for your VMs at manage.hosthatch.com. We ask you to reinstall your VM to any template available ASAP, the Debian 10 template has been patched and updated and is safe to use again.

If no action is taken we might have to restrict access to your VM from our end until fixed.

Please contact us at [email protected] if you require any assistance to identify or reinstall VMs.
Due to security purposes we cannot disclose further details about the security vulnerability at this point.

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.

How will this be prevented in the future?
The current templates have been audited, and for new future templates we will use the official cloud images provided by the different Linux distributions themselves, known as "cloud images". This hasn't been possible in the past due to restrictions in the platform, but we have been working on a new backend for some time, which will support this in time for future Linux distributions and their images.

For customers that require full control of exactly how their VM is installed, we recommend using an ISO to install it manually.

We are truly sorry for the inconvenience and we will continue to monitor this and reach out again if necessary.

Best Regards,
HostHatch LLC

So if you've acquired your templates from Solus, please investigate in your respective environments.

Neoon

So far we got: Racknerd, Virmach, HostHatch and GreenCloudVPS.

mikho

@AnthonySmith

Neoon

@mikho said:
@AnthonySmith

I did not found it on InceptionHosting or AlphaVPS.

mikho

@Neoon said:

@mikho said:
@AnthonySmith

I did not found it on InceptionHosting or AlphaVPS.

Only mentioned Ant since he created one, wouldn’t surprise me if Solus then used that copy.

life

I can confirm these 4 vendors are impacted for sure
GREENCLOUDVPS
VIRMACH
VPSSLIM
HOSTHATCH
I have vps with them and i saw debianuser . I removed that user rather then reinstalling the system

InceptionHosting

@Neoon said:

@mikho said:
@AnthonySmith

I did not found it on InceptionHosting or AlphaVPS.

Yeah I did not like the solus tdn template because it uses ext3 I only made some of the single partition templates.

youandri

@life said:
I can confirm these 4 vendors are impacted for sure
GREENCLOUDVPS
VIRMACH
VPSSLIM
HOSTHATCH
I have vps with them and i saw debianuser . I removed that user rather then reinstalling the system

Thanks for update.
Hope there are list provider who affected.

cybertech

Centos stream ftw

Falzo

tagging @gleert here as well. while naranjatech uses virtualizor I found an ubuntu user on a vm after installing 18.04 from templates. does not have to be the same same but one would probably argue, that this user should not be there anyway...
luckily no debianuser on another box with deb10 though.

seems that every provider should check what their templates are doing, if they just used publicly provided ones.

kuduku

@hosterlabs is affected . Found debianuser

Freek

A complete reinstall of the VM is the only option? Wow, okay... I'm not using Debian 10 anyway, but still.

kuduku

cut -d: -f1 /etc/passwd | grep 'debianuser'
userdel debianuser
rm -r /home/debianuser

Will this work
or
complete reinstall ?

funny part in another VPS i found username 'debian' and not 'debianuser' . Deleted that also as I did not make it

hosterlabs

@kuduku said:
@hosterlabs is affected . Found debianuser

Thanks for letting us know. I guess the most upsetting part is that I had to get notified via a Forum and no e-mail from solusvm.
Anyways, not that IPv6 servers are really that easy to compromise via brute force attacks. How long would it take to scan a /64 ?
a /96 is the same amount of IPv4's out there. Any user of ours get's at least one /80 so 281,474,976,710,656 IP's, 2^12 times larger than all IPv4's.

IPv4's are another thing. Our IP Ranges are constantly scanned and attacked. I guess all datacenter ASN's.... The most we have gotten are some fake hacked people hosting phishing sites. Trying to convince us that their site was hacked and they are not hosting phishing sites on purpose.

Best Regards!

Falzo

@Freek said:
A complete reinstall of the VM is the only option?

I wouldn't say so. if the VMs weren't breached at all using that user it should be sufficient to simply remove it.

found nothing that points towards additional fiddling with keys or else. reinstall usually is just the safe bet and most likely the best option for the average 'pls link a howto' vps owner...

TheDP

Remember, it doesn't seem to be too bad in a glance, considering it's just an account without any sudo/root access, but if you think about the sudo bug last week then you'll know it can get serious

sahjanivishal

@kuduku said:
@hosterlabs is affected . Found debianuser

I also have a @hosterlabs IPv6-only VPS with Debian 10, couldn't find the 'debianuser'. It maybe because I had to get the OS installed from the backend and it might have been installed with an ISO.

cochon

@Falzo said:

@Freek said:
A complete reinstall of the VM is the only option?

I wouldn't say so. if the VMs weren't breached at all using that user it should be sufficient to simply remove it.

Anyone know if there's a telltale or pattern to the commonly experienced crypto breach, or even the general nature. I have a couple of Hosthatch VPS's but the very first thing I did after gaining access was rename the debianuser account and harden ssh (PasswordAuthentication no).

Ganonk

@sahjanivishal said:

I also have a @hosterlabs IPv6-only VPS with Debian 10, couldn't find the 'debianuser'. It maybe because I had to get the OS installed from the backend and it might have been installed with an ISO.

yess good. installed OS from backend ISO.

Neoon

@life said:
I can confirm these 4 vendors are impacted for sure
GREENCLOUDVPS
VIRMACH
VPSSLIM
HOSTHATCH
I have vps with them and i saw debianuser . I removed that user rather then reinstalling the system

I think its safe to assume if you got password auth disabled, you are on the safe side.
Or/And even a firewall configured, it should be fine just killing the user.

cochon

@Neoon said:
I think its safe to assume if you got password auth disabled, you are on the safe side.

I run a couple of HostHatch VPS's and renamed the offending account on first install (I needed another username on UID 1000).

I move SSH to another port (PasswordAuthentication no) but happen to run SFTP on port 22 (ProFTPD with virtual users not SSH/sftpd) so appear externally to have SSH with password authentication enabled.

The ProFTPD logs show all the usual suspects, but only 2 attempts for debianuser during most of Jan. so the exploit appears not to have been probed heavily on their network that I'm on.

Falzo

@cochon said:

@Neoon said:
I think its safe to assume if you got password auth disabled, you are on the safe side.

I run a couple of HostHatch VPS's and renamed the offending account on first install (I needed another username on UID 1000).

I move SSH to another port (PasswordAuthentication no) but happen to run SFTP on port 22 (ProFTPD with virtual users not SSH/sftpd) so appear externally to have SSH with password authentication enabled.

The ProFTPD logs show all the usual suspects, but only 2 attempts for debianuser during most of Jan. so the exploit appears not to have been probed heavily on their network that I'm on.

can confirm, similar situation here, allowing only whitelisted user via ssh config and a different port etc.
couldn't even find entries in the logfiles for failed attempts, so I assume the attacker didn't even go through the effort to scan the subnets and instead only tried to get in directly and be done with it.

Dewlance

Hope template of Virtualizor does not use same method.

vyas

Rookie question: how do I find the Debian user? Will
ps aux reveal that?

TheDP

@vyas said:
Rookie question: how do I find the Debian user? Will
ps aux reveal that?

finger debianuser if you have it installed or grep debianuser /etc/passwd

MichaelCee

I just wanted the I'm on a horse. I didn't mean to facebook meme.

hosterlabs

@sahjanivishal said:

@kuduku said:
@hosterlabs is affected . Found debianuser

I also have a @hosterlabs IPv6-only VPS with Debian 10, couldn't find the 'debianuser'. It maybe because I had to get the OS installed from the backend and it might have been installed with an ISO.

Because we use SolusIO for IPv6 only (mainly) So that is another template and another management system

alwyzon

@vyas said:
Rookie question: how do I find the Debian user?

Either look for debianuser in /etc/passwd as mentioned before or maybe an even better, more general solution, use:

grep -v -E '/usr/sbin/nologin|/bin/false' /etc/passwd

... to show all users with login permissions and see if you spot any suspicious users you didn't expect on your server.

TheDP

https://support.solus.io/hc/en-us/articles/360019368659 (Provided by Emil from HostHatch)