Résumé

  • L'article de base de connaissances d'Ivanti reconnaît que son Integrity Checker Tool n'est qu'un instantané de l'état courant et qu'il ne peut pas nécessairement détecter l'activité d'un attaquant si celui-ci a remis l'appareil dans un état propre ; l'éditeur recommande une réinitialisation d'usine avant d'appliquer le correctif.
  • L'avis conjoint AA24-060B va plus loin : les attaquants peuvent tromper l'outil interne comme l'outil externe, et les recherches en laboratoire de la CISA ont conclu qu'une persistance au niveau racine restait possible malgré les réinitialisations d'usine.

La première concession se présente comme une escalade à l'intérieur du propre mode d'emploi de l'éditeur. « We have seen evidence of threat actors attempting to manipulate Ivanti's internal integrity checker (ICT). Out of an abundance of caution, we are recommending that all customers run the external ICT. » Ivanti prévient donc ses clients que le vérificateur embarqué dans l'appareil est devenu une cible, et qu'un second vérificateur, externe celui-là, constitue désormais l'instrument le plus sûr (article de base de connaissances Ivanti).

La deuxième concession est plus tranchante, parce qu'elle décrit ce que l'instrument ne sait pas faire, et non ce qu'un adversaire pourrait lui faire. « The ICT is a snapshot of the current state of the appliance and cannot necessarily detect threat actor activity if they have returned the appliance to a clean state. » Un instantané du présent ne peut pas témoigner d'un passé qui a été rangé. Quiconque a lu un résultat de scan comme un propos sur l'histoire de la machine, et non sur l'instant du scan, a mal lu l'outil ; l'éditeur le dit en termes simples.

La troisième aurait dû clore un débat d'achat. « Ivanti recommends as a best practice that all customers with a hardware appliance factory reset their appliance before applying the patch to prevent the threat actor from gaining upgrade persistence in your environment. » Un fournisseur ne demande pas à ses clients d'effacer un appareil avant de le corriger s'il croit qu'un correctif et un contrôle suffisent. La réinitialisation avant correctif, c'est ce que l'on prescrit quand on soupçonne que la machine a été modifiée à un niveau que le contrôle ne voit pas.

L'avis conjoint dit la même chose depuis l'autre côté de la table, et le dit plus durement. « Of particular concern, the authoring organizations and industry partners have determined that cyber threat actors are able to deceive Ivanti's internal and external Integrity Checker Tool (ICT), resulting in a failure to detect compromise. » Notez la portée : interne et externe. La mise à niveau que l'éditeur proposait dans son propre article se trouve à l'intérieur de la phrase que les organisations signataires consacrent à la tromperie (avis conjoint de cybersécurité AA24-060B).

Puis vient le constat qui ferme la boucle. « In addition, CISA has conducted independent research in a lab environment validating that the Ivanti ICT is not sufficient to detect compromise and that a cyber threat actor may be able to gain root-level persistence despite issuing factory resets. » Le même avis porte les deux moitiés de la contradiction : une bonne pratique éditeur bâtie sur la réinitialisation d'usine, et des recherches en laboratoire d'agence qui rapportent qu'une persistance au niveau racine peut y survivre.

Il ne s'agit pas d'un différend entre un critique et une entreprise. C'est un désaccord entre deux parties qui voulaient que la même remédiation fonctionne. Ivanti avait intérêt à garder ses clients sur ses passerelles et à les faire corriger sans exiger la reconstruction de chaque appareil. Les organisations signataires avaient intérêt à arrêter une campagne d'intrusion. Elles se sont rejointes sur le même aveu — un résultat négatif d'un outillage embarqué ne prouve pas qu'un appareil est sain — puis séparées sur la durabilité de la réinitialisation que l'éditeur recommande.

C'est cette divergence qui est utilisable. Une réinitialisation d'usine est l'affirmation que l'état de la machine a été remplacé. Des recherches en laboratoire qui trouvent une persistance malgré les réinitialisations contestent directement cette affirmation, et cela ne suppose aucune malhonnêteté du fournisseur : il suffit que la réinitialisation n'atteigne pas la couche où se tient l'attaquant. Un client qui traite la réinitialisation avant correctif comme la fin de l'histoire hérite d'une hypothèse qu'une agence cosignataire a publiquement refusé de partager.

Les instruments datés plantent le décor de cette hypothèse. La directive d'urgence 24-01, intitulée « Mitigate Ivanti Connect Secure and Ivanti Policy Secure Vulnerabilities », a été émise le vendredi 19 janvier 2024, selon l'archive FedRAMP de l'annonce de la directive tenue par la General Services Administration ; cette page d'archive affiche un titre daté du 18 janvier 2024 alors que son corps indique le 19 janvier 2024, et ce briefing retient la mention du corps (archive FedRAMP, ED 24-01). La Supplemental Direction v1 a suivi le mercredi 31 janvier 2024, et la même archive précise que cette direction supplémentaire a remplacé l'action requise numéro 4 de la directive (archive FedRAMP, Supplemental Direction v1).

L'action requise numéro 4 a donc été remplacée douze jours après l'émission de la directive. La directive et la direction supplémentaire sont publiées par la CISA à leurs adresses propres (ED 24-01, Supplemental Direction v1), mais leur texte opératoire n'était pas lisible dans les sources consultées pour ce briefing : les deux pages de la CISA ont renvoyé des erreurs d'accès à la récupération utilisée ici. Cet article n'affirme donc rien sur ce que ces instruments ordonnaient, ni sur la nature de l'action remplacée au-delà de la mention de l'archive selon laquelle la quatrième a été supprimée. Ce qu'il affirme, c'est que la substitution a eu lieu, et que les deux documents de première main cités plus haut expliquent mieux que n'importe quel résumé de directive pourquoi une étape de vérification peut manquer son but.

Pour un conseil d'administration ou une équipe achats, la conséquence opérationnelle est étroite et elle survit au texte illisible. N'exigez pas qu'un scan de fournisseur soit juste ; l'éditeur vous a déjà dit ce qu'il ne voit pas. Exigez que l'affirmation d'état sain ne repose pas uniquement sur l'instrument contesté, et exigez que les affirmations de remédiation nomment ce qui a été reconstruit ou réinstallé plutôt que ce qui a été scanné. Un appareil reconstruit a un état que quelqu'un peut décrire. Un appareil scanné a un résultat qu'on a demandé à un environnement compromis de produire.

Ce que ce briefing n'établit pas est tout aussi précis. Rien ici ne rapporte combien d'appareils ont été compromis, combien de scans ont produit des faux négatifs, ni ce qu'une agence nommée a fait après le 31 janvier 2024. L'avis conjoint est cité par son identifiant parce que la lecture conservée n'en contenait pas de date de publication verbatim, et l'article de l'éditeur n'est pas daté parce qu'il porte des identifiants de version qui changent et qu'aucune date de publication ou de révision n'est affirmée ici.

Ce sont des lacunes de ce dossier, non la preuve que les faits sous-jacents manquent ailleurs.

Reste une phrase qu'un fournisseur a écrite sur son propre outil, un paragraphe que deux gouvernements et leurs partenaires ont écrit sur le même outil, et une étape de remédiation que l'un qualifie de bonne pratique et que l'autre dit surmontable. Lus ensemble, ils tranchent la seule question qui compte à la signature du contrat : à qui appartient la preuve. La réponse ne peut pas être l'appareil lui-même.