Vulnerability in SolusVM Debian 10 template – “debianuser” backdoor/default user , SolusVM Debian 10 テンプレートに脆弱性
Vulnerability in SolusVM Debian 10 template - "debianuser" backdoor/default user
@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.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. https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54
- Ensure the key is in ~/.ssh/authorized_keys
- Disable PasswordAuthentication in /etc/ssh/sshd_config and 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
SolusVM Debian 10 テンプレートに脆弱性 - "debianuser" バックドア/デフォルトユーザ
@redgreenblue さんが言っていました。
Hosthatch が提供する Debian イメージを使って Hosthatch を実行している VM をお持ちの方は、今すぐ VM をチェックしてください。十分な確率で、あなたの VM は debianuser というユーザを経由して危険にさらされている可能性があります。複数の場所にある Hosthatch の VM がこの方法で侵害されていることが確認されています。
プロバイダからメールで
私たちは Debian 10 のテンプレートにセキュリティ上の脆弱性を検出しましたが、私たちの記録によると、このテンプレートを使用して VM をインストールしたことが判明しています。その後、Debian 10 以外のテンプレートに VM を再インストールしたり、ISO を使って VM を再インストールしたりした場合は、このメールを無視して構いません。
どうしてこのようなことが起こるのでしょうか?
私たちはバックエンド仮想化プラットフォームとして SolusVM を使用していますが、これは Plesk が運営する大手プロバイダです。その公式テンプレートを使用しています。残念ながら、この特定のテンプレートに問題があり、このセキュリティ脆弱性が発生しました。彼らは状況を把握しています。
どのように修正されましたか？
SolusVMの協力を得てテンプレートをパッチし、他のテンプレートが影響を受けていないことを確認するためにも協力してくれました。
私はまた、2020年10月からのこの中国のブログ記事を見つけました。ここでは誰かのGreenCloudVPS VPSが、私が同じdebianuserアカウントであると推測しているものを介して侵害され、他の暗号化されたもの(xmrig)も実行していました: https://aoyouer.com/posts/server-hacked-record.html したがって、これは少なくとも4ヶ月間(おそらくそれ以上)野生の状態にあり、おそらく他の多くのプロバイダにも影響を与えているでしょう。
debianuser ユーザがいるかどうか、サーバをチェックしてください。もしそうであれば、全体を消去してバックアップから復元するのが一番いいでしょう。
パスワード認証が無効になっている場合は、秘密鍵を持っていないと SSH にアクセスできないので、大丈夫でしょう。システム上に debianuser ユーザが存在する場合は、削除することをお勧めします。
もしまだ SSH にパスワード認証を使っているのであれば、強くお勧めします。
- SSH 鍵を生成する。認証に SSH 鍵を使う GitHub のようなサービスを使っていれば、すでに鍵を持っているかもしれません。もしまだ持っていないのであれば、Ed25519 鍵が良いでしょう。 https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54
- 鍵が ~/.ssh/authorized_keys にあることを確認します。
- etc/ssh/sshd_config で PasswordAuthentication を無効にして SSH を再起動する (service ssh restart)
- アクティブな SSH セッションを終了する前に、まだログインできることをダブルチェックしてください (新しいセッションを開いてテストしてください)。
