Kaseya réinitialise le calendrier de restauration, mais propose des instructions de préparation de pré-patch

  • FrançaisFrançais



  • Kaseya publie des instructions de pré-patch pour préparer les clients sur site à y accéder une fois qu’un correctif est publié à la suite d’une attaque de ransomware généralisée. (par torkildr est sous licence CC BY-SA 2.0)

    Bien que Kaseya n’ait pas été en mesure de relancer le produit de gestion à distance VSA en tant que service ou de fournir un correctif pour ses clients VSA sur site mercredi, la société a publié des instructions de pré-patch pour préparer les clients sur site à la prochaine mise à jour. .

    « Nous sommes en train de réinitialiser les délais de déploiement VSA SaaS et VSA sur site. Nous nous excusons pour le retard et les changements apportés aux plans alors que nous traversons cette situation fluide », a écrit Kasaya dans plusieurs articles distincts tout au long de la journée.

    Kaseya s’est occupé de la restauration du service après une vague d’installations de logiciels de rançon REvil dans son produit VSA sur site vendredi. Les serveurs SaaS ont été fermés par mesure de précaution.

    Kaseya a suggéré tout au long de la semaine que les serveurs SaaS pourraient être de nouveau en ligne dès le mardi 6 juillet et qu’un correctif aurait pu être publié mercredi soir. Aucun délai n’a été respecté.

    Il y avait des indices que le SaaS a presque été restauré mercredi matin. Tôt le matin, la Cybersecurity and Infrastructure Security Agency (CISA) a publié des conseils pour les clients retournant à VSA SaaS, écrits comme si le service avait été restauré, avec des liens vers les conseils de Kaseya qui n’ont jamais été publiés. CISA a rapidement supprimé le message.

    Mais Kaseya a pu publier des instructions pour que les clients sur site se préparent à la mise à jour.

    Ces instructions incluent l’isolement du serveur et la recherche d’indicateurs de compromission pour permettre aux serveurs de se reconnecter en toute sécurité à Internet. À partir de là, ces systèmes doivent mettre à jour Windows et SQL Server. Ensuite, les clients VSA doivent restreindre l’accès à un réseau local ou à un VPN d’entreprise. VSA dit ensuite d’installer l’agent FireEye, pour lequel Kaseya fournit une licence gratuite, et d’annuler toutes les instructions en attente qui se sont accumulées depuis l’arrêt.

    Mercredi également, DIVD a fourni des preuves supplémentaires pour étayer son affirmation selon laquelle elle avait divulgué les bogues VSA à Kaseya, révélant qu’elle avait contacté la société pour la première fois en avril. Le billet de blog répertorie sept CVE distincts, dont quatre avaient déjà été corrigés. Les trois qui n’avaient pas été corrigés sont une fuite d’informations d’identification et une faille de logique métier (CVE-2021-30116), une vulnérabilité de script inter-sites (CVE-2021-30119) et une vulnérabilité d’identification à deux facteurs (CVE-2021-30120) . Alors que DIVD était vague dans sa description des vulnérabilités, citant le désir de ne pas causer plus de dégâts, une vulnérabilité non corrigée peut être au moins théoriquement similaire à une faille d’authentification décrite par les chercheurs au début de l’attaque par ransomware.

    De plus, il convient de noter que l’une des vulnérabilités déjà corrigées de DIVD était une faille SQL. Bien que cela ait peut-être été corrigé, les chercheurs de Huntress ont déclaré que l’une “d’une quantité importante de vulnérabilités potentielles d’injection SQL, qui offriraient un vecteur d’attaque pour l’exécution de code et la capacité de compromettre le serveur VSA” pourrait avoir été exploitée dans l’attaque .

    Source

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *