Les faits

Une faille critique a été publiée le 17 décembre dernier sur le site de Citrix au travers de l’article CTX267027. Avec un score de 9.8 sur 10, la faille est à prendre au sérieux et Citrix propose depuis cette date une mitigation CTX267679 pour pallier à cette faille le temps que Citrix sorte les builds avec le correctif.

La CVE-2019-19781 impacte l’ensemble des produits Citrix NetScaler et Citrix ADC, à savoir :

• Citrix ADC et Citrix Gateway 13.0 tous builds confondus
• Citrix ADC et NetScaler Gateway 12.1 tous builds confondus
• Citrix ADC et NetScaler Gateway 12.0 tous builds confondus
• Citrix ADC et NetScaler Gateway 11.1 tous builds confondus
• Citrix NetScaler ADC et NetScaler Gateway 10.5 tous builds confondus

La faille de sécurité serait présente depuis 2014.

Vendredi 10 janvier, le groupe de chercheurs en sécurité indien, Project Zero India a publié sur Github un premier exploit permettant de tester la vulnérabilité d’un NetScaler. Le jour même TrustedSec à publié un exploit complet comprenant la mise en place d’un remote shell sur un Citrix ADC / Citrix NetScaler.
À la suite de ces publications, plusieurs exploit malicieux sont rapidement apparus et les NetScaler n’ayant pas la mitigation sont attaqués.

L’exploit n’était pas censé être publié aussi tôt, mais la mitigation proposée par Citrix a permis à ces équipes de trouver l’exploit facilement et d’en publier les détails.

Le 11 janvier, Citrix a publié les dates de sortie des prochains builds contenant le patch.

La faille de sécurité concerne :

• la NSIP (interface d’administration)
• la SNIP, si l’interface de management est active sur cette IP
• Toutes les VIP de Load Balancing, Content Switching, GSLB utilisant une authentification AAA NetScaler
• Tous les vServer AAA NetScaler
• Toutes les VIP Citrix Gateway / NetScaler Gateway

Un simple load balancing ou content switching n’utilisant pas le AAA de Citrix ADC / NetScaler n’est pas attaquable.

Quels risques ?

Si vous avez appliqué la mitigation proposée par Citrix avant le 8 janvier, il ne vous reste plus qu’à attendre la sortie des builds patchés pour mettre à jour vos NetScaler.

Vous n’avez pas appliqué la mitigation ? Appliquez-la au plus vite et commencez à investiguer, votre NetScaler a très certainement été attaqué.

Ce que peut faire un attaquant sur un Citrix ADC / NetScaler non protégé :

• Récupérer le ns.conf, la configuration du NetScaler.
• Récupérer les fichiers de licences du NetScaler.
• Récupérer les certificats.
• Injecter des binaires et les exécuter.
• Modifier des fichiers système de votre Citrix ADC / NetScaler.
• Exécution de commandes.
• Attaquer d’autres systèmes depuis votre NetScaler.
• Attaquer vos systèmes depuis votre NetScaler grâce aux login & mot de passe récupérés sur le NetScaler.

[fa icon=fa-exclamation-triangle] Le risque est réel et sérieux.

[fa icon=fa-book-open] Des cas d’attaques sur la partition de reset de NetScaler MPX ont été évoqués

Comment me protéger ?

Effectuer la mitigation depuis une connexion SSH. Appliquer les recommandations suivantes en fonction de votre NetScaler (qu’il soit déployé en HA, en Cluster ou seul/standalone).

Citrix NetScaler / ADC en HA

Sur le primaire (NSIP)

enable ns feature responder
add responder action respondwith403 respondwith "\"HTTP/1.1 403 Forbidden\r\n\r\n\""
add responder policy ctx267027 "HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/vpns/\") && (!CLIENT.SSLVPN.IS_SSLVPN || HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/../\"))" respondwith403
bind responder global ctx267027 1 END -type REQ_OVERRIDE
save config 
shell nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0
shell "echo 'nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0' >> /nsconfig/rc.netscaler"
reboot

Sur le secondaire (NSIP)

Lorsque le primaire à fini de redémarrer, effectuer les commandes suivantes sur le secondaire

shell nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0
shell "echo 'nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0' >> /nsconfig/rc.netscaler"
reboot

Citrix NetScaler / ADC en standalone

enable ns feature responder
add responder action respondwith403 respondwith "\"HTTP/1.1 403 Forbidden\r\n\r\n\""
add responder policy ctx267027 "HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/vpns/\") && (!CLIENT.SSLVPN.IS_SSLVPN || HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/../\"))" respondwith403
bind responder global ctx267027 1 END -type REQ_OVERRIDE
save config 
shell nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0
shell "echo 'nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0' >> /nsconfig/rc.netscaler"
reboot

Citrix NetScaler / ADC en cluster

Sur le CLIP

enable ns feature responder
add responder action respondwith403 respondwith "\"HTTP/1.1 403 Forbidden\r\n\r\n\""
add responder policy ctx267027 "HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/vpns/\") && (!CLIENT.SSLVPN.IS_SSLVPN || HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/../\"))" respondwith403
bind responder global ctx267027 1 END -type REQ_OVERRIDE
save config 
shell nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0
shell "echo 'nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0' >> /nsconfig/rc.netscaler"
reboot

Sur chacun des nœuds du cluster après redémarrage du CLIP

shell nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0
shell "echo 'nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0' >> /nsconfig/rc.netscaler"
reboot

Le rendu

Comment ça marche ?

La faille se base sur le serveur apache intégré au NetScaler. Celui-ci est utilisé pour le management graphique de votre NetScaler mais aussi pour authentifier des utilisateurs via la fonctionnalité AAA ainsi que pour la partie Citrix Gateway / NetScaler Gateway.

Vérifier si un NetScaler est vulnérable

Si vous n’avez pas implémenté la mitigation, votre NetScaler est forcément vulnérable. Si vous avez appliqué la mitigation, vous pouvez rapidement tester son bon fonctionnement en effectuant une requête http sur la NSIP / Gateway ICA / AAA vServer.

Ais-je été attaqué ?

Pour vérifier si vous avez attaqué, il faut aller chercher les indices en SSH sur votre Citrix ADC / NetScaler. L’opération sera à faire sur votre / vos autre(s) Citrix ADC / NetScaler si vous êtes en HA ou Cluster. Il est important de comprendre que les étapes suivantes vous aideront à vérifier si vous avez été attaqué, cependant, un hacker peut modifier ou supprimer des fichiers et donc masquer son attaque.
Les exploits évoluent d’heure en heure, il devient difficile de tous les lister.

1. Avant d’entamer les recherches

Avant de commencer toute action, générer un support bundle sur le NetScaler via la commande show techsupport.

Si votre NetScaler est sauvegardé via un outil de sauvegarde, conservez la sauvegarde du jour ainsi qu’une sauvegarde j-3 jours et une sauvegarde avant le 8 jour.

2. Vérifier les logs

httpaccess.log

Le NetScaler ne conserve pas sur le long terme les logs mais il est tout de même possible de vérifier si des tentatives ont été effectué les derniers jours (dépend du traffic sur le NetScaler).
Pour cela en SSH sur le netscaler, taper la commande shell pour accéder à la couche FreeBSD puis exécuter la commande suivante cd /var/log; ls -alhtr httpaccess*; gzip -d httpaccess.log.*; grep -i "/vpn/../vpns/" httpaccess.log*; ls -alhtr httpaccess*

Dans cette exemple, on constate bien des attaques sur ce NetScaler. Les résultats doivent être pondérés par rapport aux date des fichiers httpaccess.log. Dans cet exemple, les fichiers permettent de remonter au 10 Janvier.

Garder à l’esprit qu’il est aussi possible pour un attaquant de supprimer / modifier ces fichiers.

bash.log

Ce log contient l’historique des commandes exécutées sur le NetScaler via le prompt zsh du FreeBSD.

Exécuter la commande suivante :

cd /var/log; ls -alhtr bash*; gzip -d bash.log.*; grep -i "/vpn/../vpns/" bash.log*; ls -alhtr bash*

Cet exemple montre des commandes exécuté sur le shell par l’utilisateur nobody (copie de configuration NetScaler et suppression de payload xml)

3. Vérifier la présence des fichiers d’exploit

En SSH sur le NetScaler, taper la commande shell pour accéder au sous système FreeBSD.

Les deux répertoires concernés sont les suivant :

• /netscaler/portal/templates/

• /var/tmp/netscaler/portal/templates

Le premier dossier accueil le payload de l’exploit, au format XML. Il est important de vérifier la date des fichiers. Ce dossier ne doit pas contenir de fichiers récents.

Dans cet exemple, la commande ls -alhtr /netscaler/portal/templates/ montre la présence de plusieurs fichier .xml datant d’après le 11 Janvier 2020. C’est par ce dossier que l’attaque est possible. Les fichiers XML doivent être supprimé.

Si le payload a été exécuté, on retrouvera le fichier de compilation .ttc2 dans le dossier /var/tmp/netscaler/portal/templates/ avec la commande ls -alhtr /var/tmp/netscaler/portal/templates/.

Garder à l’esprit qu’il est aussi possible pour un attaquant de supprimer ces fichiers. L’exemple ci-dessus le montre, il n’y a plus qu’un seul fichier ttc2 alors que nous avons plusieurs fichiers XML.

Il faut supprimer les fichier .ttc2.

4. Vérifier les process & tâches cron

Vérifier les process lancés par l’utilisateur nobody. L’attaquant arrive la première fois sur le NetScaler via cet utilisateur. Seul httpd devrait être exécuté. Lancer la commande ps -fp $(pgrep -u nobody)

Il est possible que l’attaquant est effectué une élévation de privilège en root. Le problème se pose alors car il devient difficile de lister & vérifier les process exécuté par root.

Terminer les processus qui ne sont pas /bin/httpd via la commande kill -9

Pour assurer la persistence des binaires, des tâches cron peuvent avoir été créées. Pour le vérifier, exécuter la commande contrab -u nobody -l

Si tes tâches cron existent, les supprimer via la commande contrab -u nobody -e puis supprimer les ligne en tapant 2 fois sur la lettre d puis taper les touches “Echap” :wq puis entrée (éditeur vi)

Exécuter de nouveau la commandecontrab -u nobody -l. La commande ne doit rien renvoyer

J’ai été attaqué, je fais quoi ?

[fa icon=fa-exclamation-triangle] Citrix n’a pour le moment pas communiqué officiellement pour les clients ayant été attaqués. Etant donné qu’il est difficile de savoir ce qui a pu exactement être fait par l’attaquant, la plus grande prudence doit être appliquée.

[fa icon=fa-exclamation-triangle] En conséquence, si un NetScaler a été attaqué, il est conseillé de le reconstruire de zéro en réimportant sa configuration (cas d’un VPX, BLX, CPX) ou d’effectuer une demande de RMA auprès de Citrix (cas d’un MPX). L’action doit être faite dans les plus brefs délais.

Regénérer l’ensemble des certificats présent sur le NetScaler sans délais et utiliser une nouvelle passphrase unique pour chacun d’entre eux

Changer les mots de passe sans délais :

• Du compte nsroot
• Du rpc (pour le HA)
• Des autres comptes administrateur du NetScaler
• Des comptes locaux du NetScaler (même des comptes de test)
• Des comptes de service (LDAP entre autre)

Tout mot de passe contenu dans le ns.conf doit être modifié et ne doit plus être utilisé sur votre infrastructure.

1. J’ai des Citrix ADC / Netscaler VPX sauvegardés

Vous avez une sauvegarde datant d’avant le 8 Janvier, vous pouvez lancer une restauration de vos NetScaler avant cette date.

[fa icon=fa-exclamation-triangle] Attention, en cas de restauration de votre VPX, assurez vous qu’il ne sera pas accéssible depuis Internet au démarrage. Les réseaux de bots sont très actif et il suffit de quelques minutes / secondes pour être de nouveau attaqué.

Lorsque la restauration est effectuée, démarrer le Citrix ADC / NetScaler sans qu’il ne soit accéssible depuis Internet et réappliquer la mitigation proposé par Citrix. Valider que le Citrix ADC / NetScaler n’est plus vulnérable avant de lui donner de nouveau un accès depuis Internet.

Effectuer cette manipulation pour chaque Citrix ADC / NetScaler VPX que vous possédez

2. J’ai des Citrix ADC NetScaler VPX non sauvegardés

Il est nécessaire de reconstruire de nouvelles machines.

Que la configuration soit en standalone ou en HA, une coupure de service sera nécessaire (15 minutes à 1 heure selon l’aisance).

Faire un backup de configuration de votre NetScaler

[fa icon=fa-book-open] Vous êtes en HA ? Vous devez réaliser l’étape sur votre VPX primaire et votre secondaire

Pour effectuer un backup du NetScaler, se connecter en SSH puis exécuter la commande create system backup -level full

Pour récupérer la sauvegarde, utiliser un outil comme WinSCP et récupérez le fichier dans le dossier /var/tmp/support/

[fa icon=fa-exclamation-triangle] Attention, le backup de configuration ne sauvegarde pas les thèmes personnalisés. Pour les extraire, il faut pour cela suivre la KB suivante https://support.citrix.com/article/CTX209526

Récupération des informations du NetScaler

[fa icon=fa-book-open] Vous êtes en HA ? Vous devez réaliser l’étape sur votre VPX primaire et votre secondaire

Récupérez la version de votre Citrix ADC / NetScaler et son Host ID. Pour cela, connectez vous en SSH sur la NSIP de chacun de vos Citrix ADC / NetScaler et renseigner les commandes show ns version et show ns hardware

Dans cet exemple, le build concerné est 12.1 build 49.3nc. Conservez ces informations, le host id sera nécessaire plus tard.

Récupération du build

Rendez vous sur le site de Citrix via https://www.citrix.com/downloads. Un compte client ou partenaire est nécessaire pour télécharger le build Citrix ADC / NetScaler.

Sélectionner le build correspondant à votre NetScaler, ici NetScaler ADC Release 12.1 puis sélectionnez Citrix ADC VPX Release 12.1

Sélectionnez l’hyperviseur sur lequel se trouve votre / vos Citrix ADC actuellement puis cliquer sur Download File

Déploiement du VPX

[fa icon=fa-book-open] Vous êtes en HA ? Vous devez importer 2 Citrix ADC / NetScaler sur votre hyperviseur. L’archive peut être utilisé pour importer les deux VPX.

Faire correspondre l’adresse MAC de votre nouveau primaire avec le host ID du primaire précédemment récupéré.

Faire correspondre l’adresse MAC de votre nouveau secondaire avec le host ID du secondaire précédemment récupéré.

Importer le backup de l’ancien NetScaler primaire sur le nouveau primaire et faire de même pour le secondaire

Lorsque le téléchargement est terminé, dézipper l’archive et importez votre NetScaler sur votre hyperviseur en suivant la procédure proposée par Citrix sur le eDocs.

[fa icon=fa-exclamation-triangle] Ne démarrez pas tout de suite le Citrix ADC / NetScaler, il est nécessaire de le modifier avant le premier démarrage.

Lorsque l’import est terminé, éditer le VPX et modifiez l’adresse mac de sa carte réseau (ou de la première carte réseau s’il y a plus d’une carte). Renseignez une adresse MAC manuelle. L’adresse MAC manuelle doit correspondre au Host ID précédemment récupérer. Selon l’hyperviseur, il peut être nécessaire de rajouter un séparateur tous les deux octets. Exemple, le host ID de notre exemple est 005056dead09, l’adresse mac peut être 005056dead09, 00-50-56-de-ad-09 ou 00:50:56🇩🇪ad:09.

Reprendre la configuration réseau de la machine Citrix ADC / Citrix NetScaler initiale et réalisez la même configuration sur le nouveau NetScaler, à savoir, changer le réseau de la première carte réseau et rajouter d’autres cartes réseau si nécessaire.

Lorsque ces modifications sont faite, éteignez vos anciens Citrix ADC / Citrix NetScaler VPX. Cela évitera des conflits d’adresse MAC sur votre réseau.

[fa icon=fa-exclamation-triangle] Arrivé a cette étape, avant de démarrer le nouveau NetScaler, il est impératif de s’assurer que l’accès depuis Internet vers les NetScaler est temporairement coupé. Cela est important car lorsque le nouveau Citrix ADC / NetScaler restaurera sa configuration, il faudra valider que la mitigation est bien en place ! C’est seulement après cette validation que l’accès depuis Internet sur le NetScaler pourra être rétabli.

Au premier démarrage de la machine, un wizard demande d’effectuer une configuration de base du NetScaler pour qu’il soit accéssible sur le réseau, à savoir : l’adresse IP, le masque de sous-réseau et la passerelle.

Renseigner une adresse IP temporaire pour le NetScaler sur le réseau sur lequel il se trouve le masque de sous-réseau correspondant & la gateway

Valider la configuration en sélectionnant le menu 4. Le NetScaler redémarre. Après le redémarrage, se connecter de nouveau en SSH sur le NetScaler ainsi qu’avec un utilitaire WinSCP.

Avec l’utilitaire type WinSCP, importer le backup de l’ancien NetScaler sur le nouveau dans le dossier /var/ns_sys_backup. Pour cet exemple, nous avons renommé le fichier de backup en monbackup.tgz

Revenir sur la session SSH et renseigner les commandes add system backup monbackup.tgz puis restore system backup monbackup.tgz

Redémarrez le NetScaler

[fa icon=fa-exclamation-triangle] Ne sauvegardez pas la configuration du NetScaler lorsque vous effectuez la restauration du backup !

Post restauration

1. Appliquer de nouveau la mitigation sur votre Citrix ADC / Citrix Netscaler en fonction de votre mode de déploiement (HA / Standalone).

2. Valider que la mitigation fonctionne correctement

3. Réactiver l’accès depuis Internet a votre NetScaler

Le Citrix ADC / NetScaler est de nouveau opérationnel.

2. J’ai des Citrix ADC / NetScaler MPX

Vous devez effectuer une demande de RMA auprès du support Citrix pour changer votre disque dur.

Et ensuite ?

Comme dis plus haut, Citrix à publiée le 11 Janvier les dates de sorti des prochains builds patchés

La mitigation en place proposée par Citrix est à considérer comme temporaire. La fonctionnalité de responder n’étant pas considéré par Citrix comme une fonctionnalitée de sécurité.

Il est donc impératif de mettre à jour vos Citrix ADC / NetScaler dans les plus bref délais lorsque les build patché seront sorti.

Sources utilisées pour cet article

https://www.mdsec.co.uk/2020/01/deep-dive-to-citrix-adc-remote-code-execution-cve-2019-19781/

https://www.zdnet.de/88375177/schwere-sicherheitsluecke-in-citrix-produkten/