Vulnerability in SolusVM Debian 10 template - "debianuser" backdoor/default user
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.
Comments
So far we got: Racknerd, Virmach, HostHatch and GreenCloudVPS.
Free NAT KVM | Free NAT LXC | Bobr
ITS WEDNESDAY MY DUDES
@AnthonySmith
“Technology is best when it brings people together.” – Matt Mullenweg
I did not found it on InceptionHosting or AlphaVPS.
Free NAT KVM | Free NAT LXC | Bobr
ITS WEDNESDAY MY DUDES
Only mentioned Ant since he created one, wouldn’t surprise me if Solus then used that copy.
“Technology is best when it brings people together.” – Matt Mullenweg
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
Yeah I did not like the solus tdn template because it uses ext3 I only made some of the single partition templates.
https://inceptionhosting.com
Please do not use the PM system here for Inception Hosting support issues.
Thanks for update.
Hope there are list provider who affected.
Centos stream ftw
I bench YABS 24/7/365 unless it's a leap year.
tagging @gleert here as well. while naranjatech uses virtualizor I found an
ubuntuuser 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.
@hosterlabs is affected . Found debianuser
A complete reinstall of the VM is the only option? Wow, okay... I'm not using Debian 10 anyway, but still.
LinuxFreek.com
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
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!
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...
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
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.
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).
yess good. installed OS from backend ISO.
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.
Free NAT KVM | Free NAT LXC | Bobr
ITS WEDNESDAY MY DUDES
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.
Hope template of Virtualizor does not use same method.
Dewlance - Affordable Shared/Reseller/Master Reseller Hosting
WHMCS Addon - DemoTiger Video KB - Tutorial Videos for Hosting Providers.
Rookie question: how do I find the Debian user? Will
ps aux reveal that?
blog | exploring visually |
finger debianuserif you have it installed orgrep debianuser /etc/passwdI just wanted the I'm on a horse. I didn't mean to facebook meme.
Michael from DragonWebHost & OnePoundEmail
Because we use SolusIO for IPv6 only (mainly) So that is another template and another management system
Either look for
debianuserin/etc/passwdas mentioned before or maybe an even better, more general solution, use:... to show all users with login permissions and see if you spot any suspicious users you didn't expect on your server.
Alwyzon - Virtual Servers in Austria starting at 4,49 €/month (excl. VAT)
https://support.solus.io/hc/en-us/articles/360019368659 (Provided by Emil from HostHatch)