Kiteworks recommande la mise hors ligne de ses serveurs pendant six heures après l’alerte sur une possible attaque imminente

Les renseignements transmis par les autorités déclenchent une mesure défensive inhabituelle

Kiteworks a conseillé à ses clients du monde entier de déconnecter ses serveurs pendant six heures le samedi 26 septembre, après que les autorités ont averti qu’un attaquant pourrait se préparer à cibler certains environnements clients.

Le directeur de la sécurité des systèmes d’information, Frank Balonis, aurait transmis cette consigne par e-mail, en faisant état de renseignements crédibles communiqués par les forces de l’ordre. Kiteworks a ensuite confirmé avoir reçu l’alerte des autorités fédérales du renseignement et indiqué qu’elle examinait ces informations avec ses partenaires des forces de l’ordre.

L’entreprise a présenté cet arrêt comme une mesure préventive. Elle n’a identifié aucun client dont les systèmes auraient été compromis et, à ce stade, aucune intrusion n’est confirmée.

Les horaires de cette interruption recommandée varient selon les régions et couvrent plusieurs fuseaux horaires, de l’heure normale de l’Est australien à l’heure avancée du Pacifique. Les clients ont été invités à mettre leurs systèmes hors ligne avant le début de la plage horaire qui leur est attribuée, et non à attendre qu’elle commence.

En Europe centrale, l’arrêt est prévu de 4 h à 10 h le samedi 26 septembre. À New York, il commence à 22 h le vendredi et se termine à 4 h le samedi.

Kiteworks recommande de déconnecter les serveurs même s’ils ne sont pas directement accessibles depuis l’Internet public. Cela laisse penser que la précaution ne vise pas uniquement à bloquer les attaques entrantes les plus directes contre des services exposés.

Une possible faille zero-day qui reste à confirmer

Selon certaines informations, le support de Kiteworks aurait présenté cette mesure comme une protection contre de potentielles attaques zero-day. Toutefois, les communications disponibles aux clients et la réponse publique de l’entreprise ne confirment pas que des chercheurs ont découvert une vulnérabilité logicielle inconnue.

Aucun identifiant CVE n’a été communiqué. Aucun avis technique ne décrit non plus un composant concerné, une méthode d’exploitation, les conditions préalables à une attaque ou un niveau de gravité.

On ignore donc si les renseignements portent sur une faille Kiteworks jusque-là non divulguée, des identifiants volés, un chemin d’attaque passant par un autre système ou une autre menace opérationnelle. Rien ne confirme non plus qu’un code d’exploitation existe ou que la faille a déjà été exploitée.

Cette distinction est importante. Une vulnérabilité zero-day désigne généralement une faille que les défenseurs ne peuvent pas encore corriger complètement alors que des attaquants sont en mesure de l’exploiter. Dans le cas présent, le terme « zero-day » renvoie à une possibilité évoquée, et non à une conclusion technique établie.

Aucune entrée de l’inventaire Known Exploited Vulnerabilities de la CISA n’a par ailleurs été signalée en lien avec l’alerte. En l’absence d’identifiant de vulnérabilité ou de confirmation d’une exploitation, aucune date d’ajout à l’inventaire KEV ni aucune échéance fédérale de correction ne sont à mentionner.

La version 9.5.1 corrige les vulnérabilités connues, mais les systèmes exposés ne sont pas précisés

Kiteworks affirme que la version 9.5.1 corrige toutes les vulnérabilités dont l’entreprise a actuellement connaissance et recommande à ses clients d’utiliser la dernière version.

Cette déclaration ne permet pas d’établir que la version 9.5.1 protège contre la menace à l’origine de la demande de mise hors ligne. Si les renseignements concernent une vulnérabilité inconnue, la version ne contient peut-être pas de correctif correspondant. Kiteworks n’a pas affirmé le contraire.

L’entreprise n’a pas non plus précisé quelles anciennes versions pourraient être exposées. Aucune édition du produit, aucun composant serveur, aucune configuration ni aucun modèle de déploiement n’ont été désignés comme cible potentielle.

Les administrateurs ne peuvent donc pas limiter l’alerte à une liste publiée de versions vulnérables. Le plus prudent est de considérer que les clients qui exploitent des serveurs Kiteworks doivent appliquer la consigne de mise hors ligne pendant six heures, selon le fuseau horaire qui leur est attribué, y compris pour les systèmes sans exposition directe à Internet.

Aucune autre mesure n’a été annoncée que la mise hors ligne temporaire des serveurs et la mise à niveau vers la version 9.5.1. Kiteworks n’a publié aucun indicateur de compromission, nom de fichier suspect, adresse réseau, motif dans les journaux ou règle de détection en lien avec l’alerte.

Les systèmes de transfert de fichiers sensibles constituent des cibles de choix

Kiteworks fournit des technologies sécurisées de transfert de fichiers et de communication à des organismes gouvernementaux, des institutions financières et d’autres entreprises. Ces systèmes peuvent traiter ou stocker des documents confidentiels, ce qui en fait des cibles intéressantes pour les attaquants à la recherche de données à utiliser à des fins d’extorsion.

Une compromission réussie pourrait exposer des fichiers, des informations de compte, des données de configuration système ou des communications gérées par un déploiement concerné. L’impact réel reste inconnu, car aucune intrusion n’a été confirmée et aucune technique d’attaque n’a été divulguée.

Une mise hors ligne temporaire a également un coût opérationnel. Les organisations pourraient perdre l’accès aux transferts de fichiers et aux communications associées pendant six heures, tandis que les administrateurs devraient coordonner la déconnexion des systèmes et leur remise en service.

La recommandation montre néanmoins que Kiteworks juge une interruption planifiée moins risquée que de laisser les systèmes disponibles pendant la période où l’attaque pourrait survenir. Le fait de conseiller aussi la déconnexion des serveurs qui ne sont pas exposés à Internet élargit les conséquences opérationnelles, notamment dans les environnements où Kiteworks est intégré à des services internes.

Les organisations ne devraient pas considérer l’absence d’exposition publique comme une preuve de sécurité. Des accès internes, des systèmes d’administration à distance, des applications connectées ou des comptes compromis peuvent parfois permettre d’atteindre des systèmes qui ne sont pas directement accessibles depuis Internet. Kiteworks n’a pas confirmé que l’un de ces mécanismes était en cause dans cette affaire.

Aucun acteur de la menace n’a été désigné

Kiteworks n’a pas nommé l’attaquant présumé. Aucune agence gouvernementale n’a publiquement attribué l’opération potentielle à un acteur, et aucun élément rendu public ne la relie à un groupe criminel ou commandité par un État en particulier.

Le gang d’extorsion Clop n’a pas été désigné comme responsable de cette alerte. Son nom n’est pertinent qu’à titre de contexte historique : il a mené des campagnes de vol de données visant des plateformes de transfert utilisées par les entreprises, notamment Accellion FTA, GoAnywhere MFT, SolarWinds Serv-U FTP, Cleo et MOVEit Transfer.

Le département d’État américain offre jusqu’à 10 millions de dollars pour toute information permettant d’établir un lien entre les activités malveillantes de Clop et un gouvernement étranger. Cette situation passée ne doit pas être interprétée comme une attribution dans le cas de Kiteworks.

Tant que Kiteworks ou les autorités n’auront pas publié d’éléments techniques, attribuer l’alerte à Clop — ou à tout autre acteur — relèverait de la spéculation.

Que doivent faire les administrateurs de Kiteworks ?

Les clients doivent respecter la plage horaire attribuée à leur région et déconnecter leurs serveurs avant son début. La consigne s’applique même si leur déploiement n’est pas directement accessible depuis Internet.

Les administrateurs doivent également vérifier que leurs systèmes exécutent Kiteworks 9.5.1, version que l’entreprise présente comme corrigeant toutes les vulnérabilités actuellement connues. Les organisations qui utilisent une version antérieure devraient donner la priorité à la mise à niveau, tout en gardant à l’esprit qu’aucune version n’a été explicitement déclarée vulnérable à l’attaque présumée.

Aucun indicateur n’ayant été publié, les équipes de défense ne disposent pas encore d’une liste de vérifications adaptée à cette menace. Elles peuvent néanmoins conserver les journaux pertinents des serveurs, des authentifications, des activités d’administration et du réseau, afin de pouvoir les examiner si Kiteworks communique par la suite des indicateurs ou d’autres conclusions techniques.

Les équipes devraient consigner les heures d’arrêt et de redémarrage, vérifier l’intégrité des services une fois les systèmes remis en ligne et surveiller toute modification administrative ou activité d’authentification inhabituelle. Il s’agit de mesures défensives générales, et non d’indications qu’une compromission a eu lieu.

Pour l’instant, les faits établis restent limités : les autorités ont averti Kiteworks d’une menace potentiellement imminente visant certains systèmes clients, l’entreprise a recommandé une mise hors ligne coordonnée de six heures, et aucune attaque réussie ni vulnérabilité zero-day n’a été confirmée.