Les clients de Kiteworks ont été invités à mettre leurs systèmes de production hors ligne pendant le week-end. Au cours de cet arrêt, l’entreprise a découvert et corrigé une vulnérabilité critique.
L’entreprise a déclaré le 28 septembre que son enquête menée pendant l’arrêt avait révélé une vulnérabilité critique jusque-là inconnue. L’entreprise affirme que la fonctionnalité concernée est activée chez moins de 1 % des clients, qu’elle n’a aucune indication d’une exploitation de la vulnérabilité et que les clients peuvent rétablir leurs opérations normales.
Pour les équipes de sécurité, cet épisode soulève une question très concrète : à quelle vitesse peuvent-elles réagir à une alerte crédible lorsque la mise hors ligne d’une plateforme de données sensibles perturbe les processus métier ?
Que s’est-il passé pendant l’arrêt ?
Le 25 septembre, Kiteworks a conseillé aux clients de mettre leurs systèmes à l’arrêt pendant une fenêtre de neuf heures après avoir reçu des informations selon lesquelles un acteur malveillant pourrait cibler certaines installations. Les clients qui gèrent des systèmes sur site ou dans AWS ou Azure ont été invités à effectuer eux-mêmes l’arrêt ; Kiteworks a mis hors service les environnements qu’elle héberge. L’avis était préventif et l’entreprise avait alors déclaré n’avoir aucune indication d’une compromission.
Pendant l’arrêt, Kiteworks a identifié la faille critique, développé et déployé un correctif, puis ajouté une couche de protection supplémentaire dans tous les environnements. Dans sa déclaration du 28 septembre, l’entreprise n’a pas décrit publiquement les mécanismes de la vulnérabilité. Par ailleurs, les nouvelles consignes de redémarrage de Kiteworks demandent aux clients qui utilisent Advanced Forms en auto-hébergement de contacter le support pour obtenir de l’aide.
Kiteworks a levé sa recommandation d’arrêt le 27 septembre. L’entreprise a indiqué que la surveillance continue n’avait détecté aucune activité anormale pendant la période de menace et qu’elle n’avait aucune indication d’exploitation ou de compromission. Selon l’entreprise, tous les systèmes clients hébergés par Kiteworks ont été remis en ligne.
Pourquoi cette alerte est importante pour les défenseurs
Les systèmes de partage et de transfert de fichiers peuvent se trouver au plus près de données d’entreprise sensibles. Une analyse antérieure d’une vulnérabilité de MOVEit Transfer montre pourquoi les failles de ces plateformes exigent une attention rapide. Dans le cas de Kiteworks, une alerte crédible a entraîné un arrêt, et l’enquête a révélé une faille critique alors que les systèmes étaient hors ligne.
« Cet incident montre également pourquoi les renseignements sur les menaces doivent être opérationnels. Des renseignements qui restent dans un rapport ou un tableau de bord ne protègent rien », a déclaré Phil Wylie, consultant senior et évangéliste chez Suzu Labs.
La mise en pratique de ces renseignements nécessite un plan d’intervention : qui peut approuver un arrêt d’urgence, quels systèmes dépendent du service, comment les clients et le personnel seront informés, et de quelles preuves les équipes ont besoin avant de rétablir l’accès. Des questions similaires se posent lorsque les équipes doivent hiérarchiser une faille GitLab activement exploitée ou enquêter sur l’exploitation d’une vulnérabilité de transfert de fichiers.
Ce que les clients de Kiteworks doivent faire maintenant
Les administrateurs peuvent remettre les systèmes en ligne conformément aux nouvelles consignes de Kiteworks. Les équipes qui utilisent Advanced Forms en auto-hébergement doivent contacter le support de Kiteworks, comme l’entreprise le demande expressément. Elles doivent confirmer auprès de Kiteworks que leur déploiement dispose du correctif requis, examiner leurs propres systèmes de surveillance à la recherche d’une activité inhabituelle et documenter l’impact de l’arrêt sur les transferts critiques.
Kiteworks affirme n’avoir aucune indication d’exploitation ou de compromission. Les clients doivent néanmoins vérifier leurs propres configurations et l’état de leur reprise, en particulier s’ils utilisent Advanced Forms.
En savoir plus : l’ avertissement concernant ShareFile Storage Zone Controller offre un autre exemple des décisions auxquelles les équipes de sécurité sont confrontées lorsqu’un fournisseur de partage de fichiers recommande de mettre les systèmes hors ligne face à une menace crédible.