Mise à jour 22-01-2020

Il existe désormais un outil de FireEye qui aidera à analyser ces éléments ci-dessous. La clé est d'avoir suffisamment de journaux pour remonter jusqu'au 09-01-2020 afin d'avoir une chance de voir ce qui a été fait au-delà de l'exploitation. S'il trouve des fichiers de charge utile .XML, vous devez utiliser les informations ci-dessous pour décider des mesures à prendre. https://www.fireeye.com/blog/products-and-services/2020/01/fireeye-and-citrix-tool-scans-for-iocs-related-to-vulnerability.html

Téléchargement de l'outil

https://github.com/citrix/ioc-scanner-CVE-2019-19781 https://github.com/fireeye/ioc-scanner-CVE-2019-19781/

Détection de l'exploitation

Il n'existe pas actuellement de moyen simple de prouver ce que quelqu'un a fait. Avec 4 exploits publics, chacun laisse un artefact/signature différent, ce qui est utile pour la détection mais n'est pas fiable à 100 %. Il est important de se rappeler que ce sont les exploits publics qui étaient privés jusqu'au 10, et cela ne signifie pas non plus qu'il n'y en a pas d'autres dans la nature que des gens ne partagent pas pour leur propre profit. Les exploits sont modifiables dans la plupart des cas, où quelqu'un peut changer le nom du fichier qui sera déposé, le nom du compte utilisateur, le nom du processus, le chemin de la requête et bien d'autres options, ce qui signifie que les possibilités augmentent exponentiellement pour qu'un système ait été exploité. Il y a aussi des attaquants avancés et des attaquants basiques ; l'un nettoiera après lui et trouvera des moyens très astucieux de disparaître dans le système pour échapper à la détection.

Si vous utilisez Nessus, vous pouvez utiliser ce fichier .YAR ci-dessous pour effectuer un scan privilégié à la recherche des méthodes de détection courantes. https://github.com/Neo23x0/signature-base/blob/master/yara/exploit_shitrix.yar

Audit d'exploitation

Excellents liens à propos de ce processus d'audit. https://nerdscaler.com/2020/01/13/citrix-adc-cve-2019-19781-exploited-what-now/amp/ http://deyda.net/index.php/en/2020/01/15/checklist-for-citrix-adc-cve-2019-19781/

Avertissement : comme indiqué précédemment, cela ne détectera pas tous les exploits, mais cela peut aider à détecter certaines anomalies si l'attaquant n'a pas modifié les exploits publics et/ou n'a pas nettoyé après lui. La plupart des attaquants utiliseront l'exploit par défaut, et voici quelques-uns des artefacts documentés qui pourraient être laissés. Cette liste de commandes a été tirée de nombreuses sources et sera très dynamique à mesure que d'autres variantes, solutions de contournement et nouveaux développements apparaîtront. On peut compter sur un changement constant à mesure que d'autres infections se produisent et que des analyses forensiques plus poussées sont réalisées avec un échantillon plus large.

Examinez d'abord ce que vous n'avez pas fait. Si vous n'avez pas l'habitude de faire beaucoup de choses sur votre ADC, ceux-ci devraient être très silencieux. De plus, il peut y avoir des entrées datant de semaines, mois ou années de votre dernière connexion. Des requêtes plus précises se trouvent juste en dessous. Comprenez aussi que c'est un jeu du chat et de la souris, même dans ce blog. Alors que nous divulguons ce que nous avons vu et comment repérer les attaquants, ils utilisent ces informations contre nous en changeant leurs tactiques pour éviter la détection.

Liste rapide de vérification d'exploitation v1

• 1. Vérifiez votre licence. J'ai entendu parler de certains qui ont redémarré leurs appareils et avaient en fait une licence expirée.
• 2. Obtenez un fichier de support, c'est-à-dire une sauvegarde système : System -> Diagnostics -> Get Support File et enregistrez ce fichier.
• 3. Toutes les commandes ci-dessous sont en NSCLI et si vous vous connectez en SSH à la boîte et utilisez Shell, vous pouvez supprimer le préfixe Shell.
• 4. Vérifiez la date de la boîte pour aider à corréler les résultats des journaux
  • a. shell date
• 5. Vérifiez la date de modification de votre configuration
  • a. Shell ls -l /netscaler/ | grep netscaler
  • b. Shell ls -l /nsconfig | grep netscaler
    • i. Quelle est la date de votre netscaler.conf ?
    • ii. Cela vous semble-t-il correct ? Recherchez des liens de fichiers vers d'autres endroits.
• 6. Vérifiez le fichier des mots de passe des comptes locaux
  • a. Shell ls -lh /etc/passwd
    • i. Vérifiez quand le fichier a été modifié. Si c'est après l'exploit et que ce n'était pas vous, vous devez changer ce mot de passe dès que possible.
    • ii. Je recommande de changer le mot de passe de nsroot ou de tout compte local si des exploits sont détectés. Dans de nombreux cas.
  • b. Shell cat /etc/passwd
    • i. Regardez quels comptes sont présents.
    • ii. Root, nsroot, daemon, operator, bin, nobody, sshd, nsmonitor sont les comptes par défaut.
• 7. Vérifiez vos journaux
  • a. shell ls -lh /var/logfile
    • i. Les fichiers sont-ils présents ? Sont-ils vraiment petits ?
    • ii. https://support.citrix.com/article/CTX121898
• 8. Vérification des fichiers malveillants
  • a. Si l'un de ces fichiers a une longueur autre que 8-9 caractères et un nom aléatoire, c'est le signe d'un attaquant plus avancé qui a modifié l'exploit standard. Si vous voyez cela, vous devez ajuster votre remédiation en conséquence. Pwnpzi1337.xml est le nom de fichier pour l'exploit Project India.
  • b. shell ls /netscaler/portal/templates/*.xml
    • i. Il ne devrait y avoir aucun fichier XML ici.
    • ii. Si infecté, regardez les dates des fichiers ici.

Si exploité

Ce que vous devez faire variera toujours en fonction de votre paysage de menace. Voici quelques réflexions que j'ai partagées avec des clients qui ont trouvé des preuves d'un exploit exécuté.

Quels organismes de conformité couvrent votre entreprise ? Finances/Banque, SOX, PCI, HIPAA, lois étatiques/locales et gouvernementales.

Si vous êtes sous l'un de ces cadres, vous devez suivre ces procédures pour ces organismes de conformité. Il y a aussi des considérations éthiques basées sur les certifications et groupes professionnels dont vous faites partie qui ont des dispositions pour la réponse aux incidents et la divulgation.

Voici les liens vers ces deux guides bien connus de processus de réponse aux incidents https://security.berkeley.edu/incident-response-planning-guideline https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

Une chose que nous savons jusqu'à présent est qu'autour du 10-01-2020, le premier exploit public a été publié et il y a des rapports d'infections le 9, car c'est juste au moment de sa sortie. Dans la plupart des cas, le risque est beaucoup plus faible si vous avez corrigé votre système avant 2020 par rapport à plus tard ce mois-ci.

Risque estimé de la menace CVE-2019-19781

17 décembre - 31 décembre : Risque le plus faible d'exploitation 1er - 8 janvier : Risque plus faible d'exploitation 9 - 13 janvier : Risque plus élevé d'exploitation 14 janvier - Présent : Risque le plus élevé d'exploitation

Cela devrait entrer dans votre processus pour vos prochaines étapes.

J'ai trouvé des traces d'une exploitation, et maintenant ? Cela dépend toujours ; une chose que la plupart des déploiements Citrix ADC ne configurent pas est une bonne journalisation SNMP et SYSLOG, et ils peuvent ne pas avoir un bon moyen de rechercher, filtrer ou alerter s'il y a des artefacts. Si vous avez une journalisation absolue et que vous êtes confiant qu'ils n'ont rien fait, alors vous pourrez peut-être passer à autre chose. Ensuite, si vous avez trouvé quelque chose et que vous avez réussi à supprimer leur accès distant en toute confiance, vous pourriez aussi passer à autre chose.

Mais la plupart trouveront des traces et ne pourront peut-être pas relier les points sur ce qui a été fait et où ils ont pu aller, et il pourrait être plus facile après détection de simplement réinitialiser les appareils.

Mes prochains conseils changeront au cours des 2 prochaines semaines.

Exemples de parcours de réponse aux incidents

Il n'y a pas de réponse parfaite et correcte que je puisse donner qui conviendra à la situation de tout le monde ; ce sont mes réflexions actuelles au 19-01-2020 et elles pourraient changer après cela à mesure que j'en apprendrai plus sur les prochaines étapes et au fur et à mesure que des choses seront publiées du côté défense ou attaque liées à cette vulnérabilité. Il n'y a pas de bonne réponse ; la sécurité IT est un domaine, comme la plupart, gouverné par "ça dépend". Je recommande fortement que si vous trouvez autre chose que ces fichiers uniquement dans ces 3 répertoires, je considérerais la boîte compromise et suivrais le chemin le plus prudent. Dans certains de ces cas, je suggère de prendre le chemin le plus prudent, surtout lorsqu'il n'y a pas de journalisation pour confirmer ce qu'ils ont fait ou non. Vous devez travailler avec votre équipe pour décider de la meilleure action en fonction de votre situation, car c'est un sport d'équipe. Il peut toujours y avoir une meilleure façon de réparer ce genre de choses, mais en fonction des preuves que vous avez sur l'appareil et autour (cibles de niveau 1), vous pouvez être correct en réduisant votre risque et en partant de là.

• Atténuer : C'est par là que vous devriez commencer, quoi qu'il arrive. Avec le nouveau firmware ou la politique de réponse.
• Exploits détectés lors de votre audit. - Démarrez votre processus de réponse aux incidents.
• Avec une bonne journalisation de l'appareil
  • Signes d'attaques avancées ou de persistance
    • Construire un nouveau et migrer
  • Aucun signe d'attaques avancées ou de persistance
    • Remédier et continuer à faire fonctionner
• Sans journalisation de l'appareil
  • Signes d'attaques avancées ou de persistance
    • Construire un nouveau et migrer
    • Réinitialisation d'usine
  • Aucun signe d'attaques avancées ou de persistance
    • Construire un nouveau et migrer
    • Réinitialisation d'usine
• Avec une bonne journalisation des cibles de niveau 1
  • Signes d'attaques avancées ou de persistance
    • Construire un nouveau et migrer
    • Réinitialisation d'usine
  • Aucun signe d'attaques avancées ou de persistance
    • Remédier et continuer à faire fonctionner
• Pas de journalisation des cibles de niveau 1
  • Signes d'attaques avancées ou de persistance
    • Construire un nouveau et migrer
    • Réinitialisation d'usine
  • Aucun signe d'attaques avancées ou de persistance
    • Construire un nouveau et migrer
    • Réinitialisation d'usine

Définition et réflexions sur les réponses

• Construire un nouveau et migrer – Démarrez votre processus de réponse aux incidents puis vous pouvez commencer ce processus https://docs.citrix.com/en-us/citrix-hardware-platforms/mpx/migrating-configuration-of-existing-appliance-to-another-appliance.html. C'est relativement facile pour les clients VPX et SDX en raison de la nature virtuelle et de la flexibilité de la plateforme de configuration. Les migrations MPX sont une autre histoire à cause de la façon dont la réinitialisation d'usine fonctionne et de la maintenance de l'image de base ; il pourrait y avoir un risque très faible si c'était un attaquant avancé capable de persister via une mise à niveau du firmware et/ou une réinitialisation d'usine. La probabilité peut être faible, mais c'est toujours possible (comme tout dans le monde cyber).
• Réinitialisation d'usine – Démarrez votre processus de réponse aux incidents et supprimez les fichiers .xml et tout autre élément détecté, puis redémarrez et vérifiez à nouveau la persistance. Ensuite, commencez le processus pour effectuer la réinitialisation d'usine. Il existe des scripts disponibles auprès de Citrix qui guideront le processus. Cela effacera le système jusqu'au niveau le plus bas avant de recharger le système d'exploitation, mais tout le monde fera confiance à cette méthode jusqu'à présent en fonction de leur paysage de menace et voudra peut-être plus.
  • La méthode la plus drastique serait de retourner les appareils (RMA) pour faire recharger les disques, ce qui peut être une bonne ou une mauvaise idée selon votre cycle de vie, plateforme et plan de redondance aussi. Je suggérerais cela seulement si vous avez vu des techniques avancées utilisées et confirmé un mouvement latéral basé sur leurs techniques pour éventuellement emprunter cette voie. Je sais que Citrix travaille sur des options "et si" et
• Remédier – Démarrez le processus de réponse aux incidents et supprimez les fichiers .xml et tout autre élément détecté, puis redémarrez et vérifiez à nouveau la persistance. Si vous avez de bons journaux, vous saurez si quelque chose a été fait ; sinon, je regarderais votre paysage de menace et si vous avez une journalisation sur les cibles de niveau 1 ou autre chose pour savoir si vous devez envisager une réinitialisation d'usine et/ou une construction neuve et migration.

Niveaux de journalisation

• Bonne journalisation locale
  • Vous êtes dans la meilleure position pour voir ce qui s'est passé localement et savoir s'il y a eu des tentatives de mouvement latéral ou si l'exploit a simplement été exécuté, comme pour la plupart.
• Bonne journalisation des cibles de niveau 1
  • Vous êtes dans la meilleure position pour voir si un mouvement latéral a eu lieu ou a même été tenté. Ce devraient être les premières choses qui pourraient être ciblées et si vous avez vu un mouvement latéral réussi, vous devriez être le plus inquiet et procéder avec plus de prudence dans votre chemin de remédiation. Sinon, vous pouvez alors réduire le risque de la menace et simplement suivre le chemin de remédiation.
• Pas de journalisation locale
  • Vous êtes dans la pire position pour voir ce qui s'est passé localement et savoir s'il y a eu des tentatives de mouvement latéral ou si l'exploit a simplement été exécuté. Vous devez procéder avec plus de prudence dans votre chemin de remédiation.
• Pas de journalisation des cibles de niveau 1
  • Vous êtes dans la pire position pour voir si un mouvement latéral a eu lieu ou a même été tenté. Ce devraient être les premières choses qui pourraient être ciblées et si vous avez vu un mouvement latéral réussi, vous devriez être le plus inquiet et procéder avec plus de prudence dans votre chemin de remédiation.

J'espère que les gens pourront supprimer l'infection et avoir une journalisation suffisamment bonne pour se sentir confiants qu'ils ne sont plus présents et pouvoir reprendre leurs activités normales sans certaines de ces étapes.

Autres bonnes étapes de suivi

Il y a deux choses principales sur lesquelles vous devez prendre une décision s'il y a des traces d'exploitation.

• 1. Changer le mot de passe NSROOT
  • a. Je recommande de le faire quoi que vous trouviez ou quels que soient vos journaux. C'est une occasion de mettre nsroot en rotation pour les changements de mot de passe. La gestion ADC devrait être liée à LDAP et NSROOT ne devrait être utilisé que pour les urgences.
• 2. Changer le compte de service LDAP (ou un autre service d'authentification)
  • a. Changez ce mot de passe et je recommande également de changer pour un autre compte si possible, afin d'avoir un SID différent aussi. Cela peut être un changement passif sans que personne ne le remarque si testé avant le déploiement.
• 3. Changer les clés SSL
  • a. Bonne journalisation
    • i. Peut-être que tout va bien si vous êtes sûr à 100 % que c'est bon.
    • ii. Une partie de moi veut quand même dire de tout renouveler, mais je sais combien de travail cela peut représenter dans une grande entreprise.
  • b. Pas de journalisation
    • i. Je pense que vous devez tout renouveler. Il y a une protection PEM et PFX, mais j'ai vu beaucoup d'endroits qui utilisent des mots de passe très simples pour ceux-ci et qui pourraient être forcés hors ligne. Puisque nous ne savons pas, nous devons protéger l'entreprise.

Réflexions sur les mots de passe

Je recommande de changer vos mots de passe pour tous vos comptes locaux sur la boîte s'il y a le moindre soupçon d'un exploit réussi. Allez-y et changez-les, car dans de nombreux déploiements, ils n'ont peut-être jamais été changés après le déploiement initial il y a 4 à 7 ans. Si vous voyez des signes d'accès en ligne de commande et/ou de falsification, vous pouvez probablement considérer que l'attaquant a pu casser le mot de passe. Sur les firmwares Pre 11.0, c'était AES256 et dans les versions ultérieures, c'est AES512, qui peut aussi être vulnérable au cassage. Assurez-vous qu'il est lié à LDAP de manière sécurisée et que vous avez des alertes configurées pour les connexions NSROOT.

Réflexions sur LDAP

Si vous avez vu des niveaux d'exploitation, je recommande également de changer tout compte de service défini dans la configuration Citrix ADC. Le plus courant est le compte de liaison LDAP/Kerberos. Quelqu'un qui parvient à exécuter un exploit sur un Citrix ADC ne signifie pas qu'il est administrateur de domaine, mais cela peut ne pas prendre longtemps selon vos contrôles et votre journalisation. C'est un changement très simple qui, s'il est testé, peut être transparent pour les utilisateurs.

Réflexions sur les certificats

En fonction de ce que vous avez trouvé lors de votre audit, cela vous aidera à déterminer cela aussi. Si vous aviez une bonne journalisation et que vous pouvez voir des demandes d'accès à ce fichier, vous devez renouveler. Si vous n'avez pas de bonne journalisation, vous devez aussi renouveler. Si vous avez un certificat wildcard, c'est aussi un autre gros problème, et plus il y a de sites auxquels il est lié, plus votre risque et votre exposition sont grands. La pire chose qui puisse arriver est que vous présumiez que tout va bien et que quelqu'un monte un site de phishing avec votre certificat, et toute votre formation n'empêchera pas les clics. Cela peut entraîner des problèmes bien plus graves si quelqu'un a accès à vos certificats, et je suggère de procéder avec prudence et de faire un renouvellement. Cela pourrait être un bon moment en fonction de la date d'expiration du certificat actuel. J'ai vu certains changer de registre de certificats dans ce processus juste pour changer les choses, mais ils avaient des journaux montrant que le fichier avait été consulté et téléchargé, ainsi que d'autres techniques avancées détectées.

Crédits ###Enfin et surtout, quelques remerciements pour certaines des personnes qui travaillent sur ce problème depuis son apparition. Il y a tellement d'autres personnes qui ne sont pas sur cette liste parce qu'elles sont dans l'ombre et que je n'ai pas vues.

• Citrix Team – Travaille à diffuser l'information ainsi qu'à travailler sur ces nouveaux firmwares. Ils doivent travailler sur 5 correctifs à la fois en raison des différences entre les familles de code, ce qui rend la tâche d'autant plus difficile.
• Daniel Weppeler @_DanielWe – Politique de journalisation Responder pour détecter les sondes\attaques
• Florian Roth @cyb3rops – Fichier Nessus YAR pour la détection d'exploitation
• CTP Anton van Pelt @AntonvanPelt & CTA Mads Petersen @mbp_netscaler & Jan Tytgat @jantytgat – Travail constant avec les équipes CTP\CTA et Citrix pour avancer sur de nombreux fronts.
• KevTheHermit @KevTheHermit – Divulgation de la vulnérabilité du mot de passe d'instance AWS en plus de la CVE
• Bad Packets Report @bad_packets – Toute l'équipe Bad Packets https://badpackets.net
• Kevin Beaumont @GossiTheDog – Énormément de promotion des problèmes observés, ainsi que quelques détails sur son honeypot et ce qu'il a vu.
• Mpgn @mpgn_x64 – Détails sur l'exploit et les variations des exploits
• Nick Carr @ItsReallyNick – Détails sur l'exploit et conseils de réponse aux incidents
• Digi Cat u/digicat – Utilisateur Reddit, Superbe blog d'actualités en continu
• Ben Sadeghipour @NahamSec – Vidéo YouTube DFIR et autres contributions
• SANs Team – Articles et vidéos DFIR et d'analyse approfondie
• Craig Dods @0xCraig – Implications et recherche sur les mots de passe
• Manuel Kolloff @manuelkolloff – Procédures pas à pas d'exploitation post-exploit
• Équipes FireEye et Mandiant – Merci à Rick Cole pour avoir créé notre première couverture de détection et à l'équipe des intervenants en réponse aux incidents de Mandiant pour leurs contributions à ce blog—notamment Austin Baker, Brandan Schondorfer et John Prieto—ainsi qu'à tous les consultants qui répondent ou sécurisent les environnements de leurs clients face à cette vulnérabilité. Merci également à Nicholas Luedtke de notre équipe d'intelligence sur les vulnérabilités pour son aide dans l'affinement de la chronologie de divulgation et d'outillage de ce blog.