ransomware via Virtualizor exploit ?

Comments

• 3K33 Member, Host Rep

  February 22

  @CloudHopper said:

  @3K33 said:

  @MannDude said:

  @default said:
  Tagging administrators: @trewq / @jbiloh / @FAT32

  Please introduce in LowEndTalk selling rules a recommendation for providers to not use Virtualizor. I understand the fact that community lleadership needs money from provider tag, but we also must think about the buyers. If Virtualizor is suspect of having issues, we should not necessarily block it or deny it from community, but at least an abstract recommendation towards providers should be made within our selling rules to not focus cloud infrastructures on it. If a provider insists on choosing Virtualizor, let it be so, but this community needs to care about its members using a small recommendation at least.

  Virtualizor had issues, and may still have, in relation to their own internal communication systems. The Tawk live chat, their helpdesk. It still seems that the major security flaw was that they (Virtualizor) had bad internal actors who copied details and used them to gain access on systems that were not updated after giving access to support staff.

  I don't think anyone who was hacked answered the question, "The hypervisor(s) that were impacted, did you give Virtualizor support root access to these systems in the past?" and "If so, did you rotate credentials afterwards?" It seems odd that of the providers hit, only one or two or three hypervisors were impacted instead of all of them. That makes me think it was just whatever ones that may have previously had credentials shared in a ticket or live chat.

  At least one of the providers admitted to having not using any sort of 2FA or admin IP restrictions.

  It's still not perfectly clear if these new cases are really virtualizor's fault or just someone using the old details that never got updated and were leaked in the past. From both sides, everyone wants to save face and say it's not really their fault, which might be partially true for both sides as well.

  I'm also certain nothing was hacked, but their lowly paid support agents try to earn extra bucks. But both are possible.

  Both of those scenarios are terrible for their customers though...

  Sure, but everything will be hacked sooner or later. Unfortunetely, that's the risk of running anything online. You can take precautions but nothing is ever perfect.
• ralf Member

  February 22 edited February 22

  @CloudHopper said:

  @3K33 said:

  @MannDude said:

  @default said:
  Tagging administrators: @trewq / @jbiloh / @FAT32

  Please introduce in LowEndTalk selling rules a recommendation for providers to not use Virtualizor. I understand the fact that community lleadership needs money from provider tag, but we also must think about the buyers. If Virtualizor is suspect of having issues, we should not necessarily block it or deny it from community, but at least an abstract recommendation towards providers should be made within our selling rules to not focus cloud infrastructures on it. If a provider insists on choosing Virtualizor, let it be so, but this community needs to care about its members using a small recommendation at least.

  Virtualizor had issues, and may still have, in relation to their own internal communication systems. The Tawk live chat, their helpdesk. It still seems that the major security flaw was that they (Virtualizor) had bad internal actors who copied details and used them to gain access on systems that were not updated after giving access to support staff.

  I don't think anyone who was hacked answered the question, "The hypervisor(s) that were impacted, did you give Virtualizor support root access to these systems in the past?" and "If so, did you rotate credentials afterwards?" It seems odd that of the providers hit, only one or two or three hypervisors were impacted instead of all of them. That makes me think it was just whatever ones that may have previously had credentials shared in a ticket or live chat.

  At least one of the providers admitted to having not using any sort of 2FA or admin IP restrictions.

  It's still not perfectly clear if these new cases are really virtualizor's fault or just someone using the old details that never got updated and were leaked in the past. From both sides, everyone wants to save face and say it's not really their fault, which might be partially true for both sides as well.

  I'm also certain nothing was hacked, but their lowly paid support agents try to earn extra bucks. But both are possible.

  Both of those scenarios are terrible for their customers though...

  I'd say having corrupt support agents is actually by far the worse situation, as there's nothing you can technically do to prevent them exploiting the system again if they need to have root access creds to the customer systems in order to provide support.

  But then, the fact they require that level of access to customer systems in the first place is the biggest WTF.

  Thanked by 1tentor
• 3K33 Member, Host Rep

  February 22 edited February 22

  @ralf said:

  @CloudHopper said:

  @3K33 said:

  @MannDude said:

  @default said:
  Tagging administrators: @trewq / @jbiloh / @FAT32

  Please introduce in LowEndTalk selling rules a recommendation for providers to not use Virtualizor. I understand the fact that community lleadership needs money from provider tag, but we also must think about the buyers. If Virtualizor is suspect of having issues, we should not necessarily block it or deny it from community, but at least an abstract recommendation towards providers should be made within our selling rules to not focus cloud infrastructures on it. If a provider insists on choosing Virtualizor, let it be so, but this community needs to care about its members using a small recommendation at least.

  Virtualizor had issues, and may still have, in relation to their own internal communication systems. The Tawk live chat, their helpdesk. It still seems that the major security flaw was that they (Virtualizor) had bad internal actors who copied details and used them to gain access on systems that were not updated after giving access to support staff.

  I don't think anyone who was hacked answered the question, "The hypervisor(s) that were impacted, did you give Virtualizor support root access to these systems in the past?" and "If so, did you rotate credentials afterwards?" It seems odd that of the providers hit, only one or two or three hypervisors were impacted instead of all of them. That makes me think it was just whatever ones that may have previously had credentials shared in a ticket or live chat.

  At least one of the providers admitted to having not using any sort of 2FA or admin IP restrictions.

  It's still not perfectly clear if these new cases are really virtualizor's fault or just someone using the old details that never got updated and were leaked in the past. From both sides, everyone wants to save face and say it's not really their fault, which might be partially true for both sides as well.

  I'm also certain nothing was hacked, but their lowly paid support agents try to earn extra bucks. But both are possible.

  Both of those scenarios are terrible for their customers though...

  I'd say having corrupt support agents is actually by far the worse situation, as there's nothing you can technically do to provide them exploiting the system if they need root access to your system to provide support.

  But then, the fact they require that level of access to customer systems in the first place is the biggest WTF.

  They changed their policies, if there is anything looking like IP, password whatever supplied in normal message, their system changes it to [REDACTED]. They have also stopped asking for credentials and work through remote connection tools like Anydesk, but they also started giving debugging guides in tickets if you don't feel comfortable in doing this.

  So I can guess that they started taking even more complex precautionary measures and lowering any risk to be blamed for future hacks.

  Thanked by 3oloke ralf tentor
• CloudHopper Member

  February 22

  @3K33 said:

  @CloudHopper said:

  @3K33 said:

  @MannDude said:

  @default said:
  Tagging administrators: @trewq / @jbiloh / @FAT32

  Please introduce in LowEndTalk selling rules a recommendation for providers to not use Virtualizor. I understand the fact that community lleadership needs money from provider tag, but we also must think about the buyers. If Virtualizor is suspect of having issues, we should not necessarily block it or deny it from community, but at least an abstract recommendation towards providers should be made within our selling rules to not focus cloud infrastructures on it. If a provider insists on choosing Virtualizor, let it be so, but this community needs to care about its members using a small recommendation at least.

  Virtualizor had issues, and may still have, in relation to their own internal communication systems. The Tawk live chat, their helpdesk. It still seems that the major security flaw was that they (Virtualizor) had bad internal actors who copied details and used them to gain access on systems that were not updated after giving access to support staff.

  I don't think anyone who was hacked answered the question, "The hypervisor(s) that were impacted, did you give Virtualizor support root access to these systems in the past?" and "If so, did you rotate credentials afterwards?" It seems odd that of the providers hit, only one or two or three hypervisors were impacted instead of all of them. That makes me think it was just whatever ones that may have previously had credentials shared in a ticket or live chat.

  At least one of the providers admitted to having not using any sort of 2FA or admin IP restrictions.

  It's still not perfectly clear if these new cases are really virtualizor's fault or just someone using the old details that never got updated and were leaked in the past. From both sides, everyone wants to save face and say it's not really their fault, which might be partially true for both sides as well.

  I'm also certain nothing was hacked, but their lowly paid support agents try to earn extra bucks. But both are possible.

  Both of those scenarios are terrible for their customers though...

  Sure, but everything will be hacked sooner or later. Unfortunetely, that's the risk of running anything online. You can take precautions but nothing is ever perfect.

  Everything gets hacked and nothing is ever perfect, but taking steps to prevent it is the least we can do.

  And usually the best way to avoid becoming a victim is just to be less vulnerable and harder to hack than similar targets to yourself.

  In the case of LET hosts, nearly all of the recent hacking victims have been running Virtualizor because it's making them a softer target.

  Thanked by 13K33
• SpaceCode Member

  February 22

  @xvps said:

  @SpaceCode said:
  It's been a while since everything has happened. Did virtualizor patch all these vulnerabilities since in their panel aswell and the whmcs addon?

  What vulnerabilities?

  The hacker found a vulnerability in Virtualizor’s own support system, not in the panel or the WHMCS add-on the providers are using.

  Only providers that had sent root passwords and had not rotated them later were affected.

  See: https://www.virtualizor.com/blog/security-update-transparency-regarding-a-recent-support-ticket-incident/

  Have you rotated your passwords?

  I personally don’t use virtualizor but I don’t know many other alternatives or using proxmox like convoy panel. Virtualizor had an major security vulnerability in the whmcs module. I personally don’t trust virtualizor anymore after everything that happened and not sure how many flaws are coming next. Does anyone have maybe alternative software or maybe something for proxmox so it’s easy to use between whmcs. Cheers
• forest Member

  February 23

  @3K33 said: Sure, but everything will be hacked sooner or later. Unfortunetely, that's the risk of running anything online. You can take precautions but nothing is ever perfect.

  That kind of security fatalism is what keeps me employed.

  Thanked by 13K33